A founder can spend four months negotiating a Series A, watch the deal nearly fall apart twice, and still publish an announcement that reads as if the whole thing happened over lunch: Acme raised $12 million. That past tense isn't modesty, and Abdullah Jamil's Nerdbot breakdown of why startup funding announcements are written in the past tense shows how much of it comes from securities rules and from the gap between investor interest, signed commitments, and cash that has actually arrived. Developers should take notes. We switch tenses all day across commits, changelogs, docs, and status pages, and we're far less careful about what each one promises.

A funding round is a distributed transaction

Picture a round as a write that spans a dozen independent services. Term sheets and verbal yeses are the prepare phase: every participant has signaled intent, nothing is durable, and anyone can still abort. The commit comes when documents are signed and money moves, and US securities law defines the first commit point with unusual precision. Under the SEC's rules for filing a Form D notice, the date of first sale is the day the first investor is "irrevocably contractually committed to invest," and the notice is due within 15 days of it. Filed notices are public, which is why some rounds turn up in EDGAR before the founders have posted a word.

While the round is open, a startup mostly has to keep quiet. The vast majority of Regulation D offerings rely on Rule 506(b), which generally rules out advertising an offering while it's live, and in the SEC's own statistics, 506(b) offerings outnumber the advertising-friendly 506(c) kind by roughly seven to one. Add the reputational damage of a deal that rolls back in public, and the outcome is predictable: the announcement waits for the commit, and the verb lands in the one tense nobody can roll back.

Developers publish dirty reads every week

Now open almost any repository. The README promises Windows support "soon," and git blame says that line is three years old. The API reference says an endpoint "will return" a cursor, so nobody can tell whether it does today. A launch post celebrates a feature that's still behind a flag for 5% of accounts. An incident update says "we're working on a fix" and then goes silent for two hours.

None of these are lies. They're uncommitted writes exposed to readers who can't see the transaction boundary, and those readers act on them anyway. They plan migrations around features that never merge, pick a competitor because "soon" sounded like "not this quarter," and reopen issues because nobody updated the thread. A funding announcement dodges all of that by publishing only state that's already durable.

Git solved half of this years ago

The guide for contributors to Git itself is surprisingly strict about grammar. It wants the problem described in the present tense, as the code behaves without your change, and the fix written in the imperative mood, "as if you are giving orders to the codebase." The Linux kernel liked that wording enough to borrow it for its own patch-submission guide in 2014.

The imperative fits because a commit is an instruction, not a report. It can be applied, reverted, rebased, or cherry-picked onto a branch where it hasn't happened yet, so its subject line should say what applying it does: "Add backoff to webhook retries," not "Added backoff."

A changelog sits on the other side of the timeline. People open it after the release has shipped, which is why the widely copied Keep a Changelog format files almost every entry under a past participle: Added, Changed, Deprecated, Removed, Fixed, plus a Security section. Same change, two tenses, both correct. The tense follows where the reader stands relative to the commit, the same logic that keeps a founder silent until the round has closed.

The future tense needs a mechanism

The future tense is where trust quietly leaks out of technical writing, and the most careful documentation teams treat it that way. Google's developer documentation style guide asks writers to describe general behavior in the present tense and to save "will" for things that genuinely happen later, such as a file that gets archived the next time a backup job runs. What it rules out is using the future tense to describe how a product will work after an upcoming release. A neighboring page in the same guide goes further and says not to pre-announce anything in documentation unless legal counsel has approved it.

Public companies live with a stricter version of the same rule. Sentences about the future in an earnings release travel with a "forward-looking statements" disclaimer, because the safe harbor in the Private Securities Litigation Reform Act of 1995 shields predictions that are labeled as forward-looking and accompanied by meaningful cautionary language. If a tense needs a legal warning label in finance, it deserves a second look in your docs.

Here's a workable test. A future-tense sentence is fine when it's backed by a mechanism (a cron job, a TTL, a scheduled migration), a date, or a named owner. "The cache will be rebuilt on the next deploy" describes a system. "Windows support will land soon" is a wish dressed up as a fact.

Your status page already knows the rules

For tense used as a precision instrument, read a well-run status page in the middle of an outage. Many of them follow the same lifecycle, from Investigating to Identified to Monitoring to Resolved, and the stock messages change grammar as certainty grows. "We are currently investigating this issue" is work in flight with no promises attached. "A fix has been implemented and we are monitoring the results" pairs a durable fact with ongoing observation. "This incident has been resolved" closes the transaction. Each update carries a timestamp, so readers always know how fresh a claim is.

The best teams end with a future-tense sentence that passes the mechanism test. OpenAI's status page, for example, has closed an incident by committing to publish a detailed root cause analysis within five business days: a promise with a deadline, which is the only kind worth making in public. Good postmortems keep the same shape, with a timeline in the past tense and action items written as future commitments, each with an owner and a ticket.

A tense map you can steal

  • Imperative for commit subjects, CLI help text, and tutorial steps: "Add a retry budget to the webhook sender."
  • Present simple for reference docs and the problem statement in a pull request: "The endpoint returns 429 after 100 requests per minute."
  • Present progressive for live status only, always with a timestamp: "14:05 UTC: We are investigating elevated 502s on checkout."
  • Past for changelogs, launch posts, postmortem timelines, and anything merged, measured, or signed: "Fixed a race in token refresh that logged users out."
  • Future only with a mechanism, a date, or an owner: "Existing sessions will expire at 00:00 UTC on December 1, when the old signing key is retired."

Run a promise audit before your next release

Finding your own dirty reads takes about a minute. From the root of a project, run:

grep -rniwE "will|soon|eventually|going to|planned" README.md docs/

Sort every hit into one of three buckets: a mechanism, a dated commitment, or a wish. Keep the first two. Rewrite each wish as a present-tense fact about what works today, or move it to an issue tracker where it gets an owner and a visible status.

To keep new ones out, put a prose linter in CI. Vale has a package that implements Google's style guide, and two of its rules do exactly this job: Google.Will flags "will," and Google.Timeless flags time-bound words like "soon," "currently," and "latest." You can switch on just those two without adopting the rest of the style:

StylesPath = styles MinAlertLevel = suggestion Packages = Google [*.md] Google.Will = YES Google.Timeless = YES

Run vale sync once to download the package, then vale README.md docs/ locally or as a pipeline step. Both rules report warnings or suggestions rather than errors, and that's the right level. Some uses of "will" are perfectly honest; the goal is to make every promise a decision instead of a habit.

Publish after the commit

Funding announcements are boring by design. They state what happened, who took part, and how much changed hands, and they wait until none of it can be undone. That restraint is why readers trust the number in the headline. Your changelog, your docs, and your status page can earn the same trust through the same discipline: commit first, publish second, and let the tense tell readers how solid the ground under each sentence really is.

So what's the oldest "coming soon" still sitting in one of your READMEs? Drop it in the comments, especially if it's older than the framework version you're running today.