What Is Engineering Velocity?

Engineering velocity is the rate at which a startup's engineering team produces software. More than a raw commit count, it combines how fast the team ships, how fast the team is growing, and how fast its codebase is expanding into new areas. It is the leading indicator most VCs never look at, and it has historically led fundraise announcements by 3 to 6 weeks.

The three components of engineering velocity

A complete picture of engineering velocity is built from three public signals, and each answers a different question:

• Commit velocity asks 'are they shipping?'. It measures how frequently the team pushes code, the raw pace of execution.
• Contributor growth asks 'are they scaling?'. It measures how many distinct developers are committing, a proxy for team expansion and hiring.
• Repository expansion asks 'are they expanding?'. It measures new public repositories and code growth, a proxy for exploration into new product areas.

Together they separate real momentum from activity theater. A team can have high commit velocity but a stagnant, one-founder contributor base, which is a concentration risk. A team can add contributors without shipping more, which is hiring without execution. Only when all three move together is the signal strong.

This three-part structure is not arbitrary; it maps to the three questions every investor has about an early team: can they build, are they scaling, and are they building toward something bigger?

Why engineering velocity is a leading indicator

Most investor data is lagging. Funding rounds, press coverage, and revenue reports all describe what already happened. Engineering velocity describes what is happening right now, in public, before anyone announces anything.

Teams accelerate before they raise because fundraising forces deadlines: the roadmap gets compressed, hiring decisions get made, and the codebase is pushed forward to support the pitch. That acceleration is visible in GitHub weeks before the round hits the press. This is the core insight behind GitDealFlow: 3 to 6 weeks of lead time, documented in a published methodology on SSRN.

The lead time is what makes the signal commercially valuable. A lagging indicator tells you who already raised, which is useless for access. A leading indicator tells you who is about to raise, which is exactly the window where a check or an introduction is worth the most.

Engineering velocity vs product velocity

These are related but not identical, and confusing them leads to bad decisions. Product velocity is about what ships to customers: features, releases, outcomes. Engineering velocity is about what the team is producing in code.

A team can have high engineering velocity and low product velocity if it is building the wrong thing. A team can also have high product velocity with lower engineering velocity if it is unusually efficient. The practical rule: engineering velocity is a signal of execution capacity, and it is most useful early, when there is no product revenue to measure yet.

As a company matures, product velocity becomes the more meaningful number, because revenue and usage exist to measure it. Engineering velocity does not stop mattering; it just recedes from being the primary signal to being one input among several.

How engineering velocity connects to DORA and developer productivity

Engineering velocity overlaps with a well-known framework from the DORA (DevOps Research and Assessment) research program, which measures software delivery with four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. Those four metrics are the industry standard for engineering throughput.

The difference is one of visibility. DORA metrics are usually measured inside a company with access to its CI/CD pipeline, which an outside investor cannot see. Public GitHub activity is the outside-in proxy for the same underlying question: how fast and how reliably does this team deliver software?

An investor cannot read a startup's deployment frequency directly, but a sustained rise in commit velocity and repository expansion is the public trace of a team that is delivering more. The two frameworks answer the same question from opposite sides of the company's firewall.

Reading velocity in context

Velocity is never meaningful in the abstract. Four contexts matter:

• Stage: a pre-seed team of three commits differently from a Series B team of forty, so the expectation scales with maturity.
• Sector: hardware and biotech teams commit differently from pure software teams, so cross-sector comparison is meaningless.
• Geography and tooling: some teams work in private repos or use GitLab instead of GitHub, which changes what is publicly visible.
• Business model: open-source companies have a public footprint by design, while closed-source companies may keep the core product private.

GitDealFlow handles the sector problem by normalizing every startup's momentum relative to its sector peers. That normalization is what lets you compare a fintech breakout to a developer-tools breakout on one leaderboard.

The limits and how to mitigate them

Engineering velocity has three structural limits, each with a mitigation. The signal can be gamed in the short run, so read sustained trends over months rather than single-week spikes. The signal is blind to private work, so treat a thin public footprint as a data limitation rather than a verdict. The signal is sector-dependent, so normalize within sector instead of comparing raw counts across sectors.

The discipline is to use engineering velocity to verify specific claims, not to generate a blanket score. 'Is the founder's momentum claim true?' is a clean question the data answers. 'Is this a good company?' is not, and no single signal should be asked to answer it.

How to verify an engineering velocity claim

Any velocity claim can be checked against the public record in minutes. Open the company's GitHub organization, find the repositories behind the product, and read the Insights views: Contributors for pace and team composition, and Pulse for the last week and month. If the claimed momentum does not appear there, treat the claim with skepticism.

The verification habit protects you from the most common failure: taking a pitch-deck momentum slide at face value. A founder can write 'we ship weekly' on a slide, but the commit graph either confirms it or does not, and the founder cannot edit the past. Make verification the default, and the signal becomes evidence instead of a talking point.

How investors use engineering velocity

The workflow is simple: watch for velocity breakouts, verify them against contributor growth and repository expansion, then reach out while the round is still being assembled. The signal does the sourcing; you do the judgment.

The free weekly GitDealFlow digest ships five breakout names every Sunday, each verifiable on GitHub, typically 21 to 47 days before the round is public. The Scout Score tool (0 to 100) is the backwards-looking companion: it checks whether a GitHub user starred validated unicorns before the market did, a measure of taste rather than momentum.

Start tracking for free →