u/Worth_Wealth_6811

Disclosure up front: I built the project this dataset backs, and I am sharing the raw data here because it is genuinely useful for anyone mining founder or engineering signals.

This is Q3 2026 engineering momentum across 350+ startup GitHub organizations in 15 sectors (web3, data infrastructure, enterprise SaaS, robotics, healthcare, legal tech, space tech, and more). Updated weekly.

What is inside, per org:

• 14-day commit velocity and velocity change %
• contributor count and growth
• new-repo creation
• a signal label (engineering hiring burst / deploy frequency spike / infrastructure buildout / framework migration)
• funding stage estimate (pre-seed through growth) and geography

Collected from public GitHub events only. No private repositories.

The research finding this backs: in a panel of 219 confirmed fundraises (SSRN preprint), a composite of commit velocity and contributor diversity preceded fundraise announcements by 21 to 47 days (median 31), a 3.4x lift over baseline. The methodology page has the full definition; the preprint is at papers.ssrn.com, abstract 6606558.

Get the data (free, no API key):

• JSON: signals.gitdealflow.com/api/signals.json
• Catalog with CSV + JSON exports and field docs: gitdealflow.com/datasets
• Methodology: signals.gitdealflow.com/methodology

License: CC BY 4.0 (attribute as 'Source: GitDealFlow, CC BY 4.0').

One caveat worth knowing: velocity-change % saturates at +999% on the biggest jumps, so for top movers rely on the absolute commit counts rather than the percentage.

Happy to answer questions about the pipeline or the caveats.

I run a small open dataset that tracks public GitHub activity across ~350 startup organizations in 15 sectors. Six months in, the patterns around pre-fundraise acceleration are consistent enough to share. One data point, not gospel: signals fail, and the methodology is published as a preprint so the misses are on the record.

Four patterns that show up repeatedly before a round is announced:

1. Deploy spikes beat raw commits. Companies about to raise tend to ship: merge velocity goes flat or even dips while deploy frequency jumps. Commit count alone hides it.

2. Contributor growth leads hiring news. New contributors appear 70-400% faster in the weeks before a fundraise becomes public. Founders build the team before they talk about the team.

3. New repos = new product lines. A fresh repo (or a dormant one revived) usually precedes a positioning change. It is the cheapest way to watch a pivot happen in real time.

4. Infrastructure buildout before scale. CI/CD, testing, and deployment tooling commits rise right before the hiring blitz. You see the scaffolding go up first.

This week's standouts from the dataset:

• liberusoftware (UK, seed-stage): 135 commits in 14 days, +3,275% commit velocity, contributors 3 to 14.
• fleetbase (APAC, pre-seed): 17 commits in 14 days, +1,600% velocity, +73% contributor growth.
• StanfordSpezi (US, pre-seed): a deploy spike with 5 active committers on a new health-data repo.

The claim, under test: across a backtest panel of 219 fundraise announcements, acceleration signals preceded the announcement by 21-47 days (median 31). That is prospective, not proven. I publish the misses too.

Full weekly dataset + methodology: link in the top comment.

Built a read-only MCP server over the last six weekends and shipped it to the official registry + Glama A-tier. Sharing the architecture in case it helps anyone building MCP tooling.

WHAT IT DOES

Five tools your AI client can call:

- get_trending_startups — top startups by engineering acceleration this week

- search_startups_by_sector — filter by AI, fintech, healthcare, etc. (20 sectors)

- get_startup_signal — deep profile on any tracked startup

- get_signals_summary — dataset overview

- get_methodology — how the signals work, with limits

ARCHITECTURE

- TypeScript MCP server, ~250 lines, stdio transport

- Streams from a Vercel-hosted JSON API with no auth (60 req/min)

- Anonymous PostHog telemetry per tool call (opt-out via MCP_TELEMETRY_DISABLED=1)

- npm u/gitdealflow/mcp-signal, ~5 KB install

INSTALL

{

"mcpServers": {

"vc-deal-flow-signal": {

"command": "npx",

"args": ["-y", "@gitdealflow/mcp-signal"]

}

}

}

Works in Claude Desktop, Cursor, Cline, Continue, any MCP-compatible client.

THE DATASET BEHIND IT

Engineering acceleration metrics across ~4,200 startup GitHub orgs. Refreshed weekly. Methodology paper at ssrn.com/abstract=6606558 with the false-positive analysis (~35-40% at the org level so it is a ranking signal, not a single-feature predictor).

WHAT I LEARNED

1. MCP stdio transport is dead simple. Do not overthink it.

2. The hard part is not the protocol, it is the dataset. Build the dataset first.

3. Telemetry per tool call is critical. Without it you have no idea if anyone uses what you ship. Opt-out, anonymous, document loudly.

4. The npm install path beat any "visit the website" CTA 5-1 for technical users.

Source: github.com/kindrat86/mcp-deal-flow-signal

npm: npmjs.com/package/@gitdealflow/mcp-signal

Happy to walk through any part of the build.

Built a read-only MCP server over the last six weekends and shipped it to the official registry + Glama A-tier. Sharing the architecture in case it helps anyone building MCP tooling.

WHAT IT DOES

Five tools your AI client can call:

- get_trending_startups — top startups by engineering acceleration this week

- search_startups_by_sector — filter by AI, fintech, healthcare, etc. (20 sectors)

- get_startup_signal — deep profile on any tracked startup

- get_signals_summary — dataset overview

- get_methodology — how the signals work, with limits

ARCHITECTURE

- TypeScript MCP server, ~250 lines, stdio transport

- Streams from a Vercel-hosted JSON API with no auth (60 req/min)

- Anonymous PostHog telemetry per tool call (opt-out via MCP_TELEMETRY_DISABLED=1)

- npm u/gitdealflow/mcp-signal, ~5 KB install

INSTALL

{

"mcpServers": {

"vc-deal-flow-signal": {

"command": "npx",

"args": ["-y", "@gitdealflow/mcp-signal"]

}

}

}

Works in Claude Desktop, Cursor, Cline, Continue, any MCP-compatible client.

THE DATASET BEHIND IT

Engineering acceleration metrics across ~4,200 startup GitHub orgs. Refreshed weekly. Methodology paper at ssrn.com/abstract=6606558 with the false-positive analysis (~35-40% at the org level so it is a ranking signal, not a single-feature predictor).

WHAT I LEARNED

1. MCP stdio transport is dead simple. Do not overthink it.

2. The hard part is not the protocol, it is the dataset. Build the dataset first.

3. Telemetry per tool call is critical. Without it you have no idea if anyone uses what you ship. Opt-out, anonymous, document loudly.

4. The npm install path beat any "visit the website" CTA 5-1 for technical users.

Source: github.com/kindrat86/mcp-deal-flow-signal

npm: npmjs.com/package/@gitdealflow/mcp-signal

Happy to walk through any part of the build.

Sharing an open-source MCP server I built and shipped to the official MCP registry + Glama A-tier. MIT-licensed, ~250 lines of TypeScript. In case the architecture is useful for anyone shipping their own MCP.

WHAT IT IS

A read-only MCP server with 5 tools your AI agent can call:

- get_trending_startups — top startups by engineering acceleration this week

- search_startups_by_sector — filter by 20 sectors

- get_startup_signal — deep profile on any tracked startup

- get_signals_summary — dataset overview

- get_methodology — false-positive rate, sample frame, limits

INSTALL (any MCP-compatible client)

`npx u/gitdealflow/mcp-signal`

ARCHITECTURE

- TypeScript, ~250 lines, stdio transport

- Streams from a Vercel-hosted JSON API with no auth (60 req/min)

- Anonymous opt-out telemetry (`MCP_TELEMETRY_DISABLED=1`)

- npm package, ~5 KB install

THE DATASET

GitHub commit velocity across ~4,200 startup orgs, weekly refresh. Methodology paper at ssrn.com/abstract=6606558 with the false-positive analysis (~35-40% so it is a ranking signal not a predictor).

WHY IT'S OPEN

The dataset itself is closed-source bot-filtered output, but the MCP server, schemas, and tool definitions are MIT. Fork freely, swap the upstream API for your own dataset, ship your own MCP. The pattern matters more than this specific dataset.

WHAT I LEARNED SHIPPING IT

1. MCP stdio transport is dead simple. The hard part is the dataset, not the protocol.

2. Telemetry per tool call is critical. Without it you have no idea if anyone uses what you ship. Opt-out, anonymous, document loudly.

3. Glama A-tier review took 4 days. Worth doing — listing surfaced ~12 daily installs.

Source: github.com/kindrat86/mcp-deal-flow-signal

npm: npmjs.com/package/@gitdealflow/mcp-signal

Happy to walk through the build.

Cline supports MCP out of the box, so this drops in and works.

WHAT IT DOES

Five tools your Cline agent can call:

- get_trending_startups — top startups by engineering acceleration this week

- search_startups_by_sector — filter by AI, fintech, healthcare, etc. (20 sectors)

- get_startup_signal — deep profile on any tracked startup

- get_signals_summary — dataset overview

- get_methodology — how the signals work, with limits

INSTALL (Cline settings.json or MCP config)

{

"mcpServers": {

"vc-deal-flow-signal": {

"command": "npx",

"args": ["-y", "@gitdealflow/mcp-signal"]

}

}

}

~5 KB install, stdio transport, no auth, 60 req/min.

THE DATASET BEHIND IT

Engineering acceleration metrics across ~4,200 startup GitHub orgs. Refreshed weekly. Methodology paper at ssrn.com/abstract=6606558 (false-positive rate ~35-40% so it is a ranking signal, not a single-feature predictor).

WHY YOU MIGHT WANT IT IN CLINE

If you point Cline at "find me three early AI infra startups shipping fast this month" the agent now has live data instead of stale training. Useful for VC-curious devs, scout work, or building competitive-intel automations.

Source: github.com/kindrat86/mcp-deal-flow-signal

npm: npmjs.com/package/@gitdealflow/mcp-signal

Anonymous opt-out telemetry per tool call (MCP_TELEMETRY_DISABLED=1). Happy to walk through the build.

Built a read-only MCP server over the last six weekends and shipped it to the official registry + Glama A-tier. Sharing the architecture in case it helps anyone building MCP tooling.

WHAT IT DOES

Five tools your AI client can call:

• get_trending_startups — top startups by engineering acceleration this week
• search_startups_by_sector — filter by AI, fintech, healthcare, etc. (20 sectors)
• get_startup_signal — deep profile on any tracked startup
• get_signals_summary — dataset overview
• get_methodology — how the signals work, with limits

ARCHITECTURE

• TypeScript MCP server, ~250 lines, stdio transport
• Streams from a Vercel-hosted JSON API with no auth (60 req/min)
• Anonymous PostHog telemetry per tool call (opt-out via MCP_TELEMETRY_DISABLED=1)
• npm u/gitdealflow/mcp-signal, ~5 KB install

INSTALL

{
  "mcpServers": {
    "vc-deal-flow-signal": {
      "command": "npx",
      "args": ["-y", "@gitdealflow/mcp-signal"]
    }
  }
}

Works in Claude Desktop, Cursor, Cline, Continue, any MCP-compatible client.

THE DATASET BEHIND IT

Engineering acceleration metrics across ~4,200 startup GitHub orgs. Refreshed weekly. Methodology paper at ssrn.com/abstract=6606558 with the false-positive analysis (~35-40% at the org level so it is a ranking signal, not a single-feature predictor).

WHAT I LEARNED

1. MCP stdio transport is dead simple. Do not overthink it.
2. The hard part is not the protocol, it is the dataset. Build the dataset first.
3. Telemetry per tool call is critical. Without it you have no idea if anyone uses what you ship. Opt-out, anonymous, document loudly.
4. The npm install path beat any "visit the website" CTA 5-1 for technical users.

Source: github.com/kindrat86/mcp-deal-flow-signal npm: npmjs.com/package/@gitdealflow/mcp-signal

Happy to walk through any part of the build.

Most threads about deal sourcing devolve into "warm intro" or "Twitter network." Both real, neither scalable past your friend group.

I have been tracking public engineering activity across ~4,000 early-stage orgs for 6 months as one signal layer. The most counter-intuitive thing I have found: hiring signals decay fast. Companies that posted a VC-relevant hire in the last 14 days are 4-5x more likely to be in an active raise cycle. 30 days out, you are pitching ghosts.

Curious what other angels here actually use:

• Job posts / hiring signals (and how you filter VC-relevant from regular)
• Public commit activity / GitHub momentum
• Founder LinkedIn changes
• Conference attendee lists
• Substack or Twitter follower spikes
• Domain registration or deploy timing
• Other?

Specifically interested in what you have tried and abandoned. The dead-ends often teach more than the wins.

Six months ago I was an engineer with a Series A coming up at my day job and a side project nobody had heard of. The side project was a tool that scrapes public GitHub data across 4,200 startup orgs and ranks them by engineering acceleration as a leading-indicator deal-flow signal for angel investors.

I am not a marketer. I am not a designer. I had no audience, no email list, no Twitter following. I shipped the v1 anyway. Today I have a published research paper, a Chrome extension on the Web Store, an MCP server in three registries, a dataset on Kaggle, 26 blog posts, and a tiny but real list of paying users. I also failed a Product Hunt launch this morning. It did not get editorially featured. Zero votes at T+7h.

Here are seven things 6 months of solo-shipping taught me.

1. Distribution is the product. I spent 4 months obsessing over the data pipeline. The pipeline works. Almost nobody knew it existed. If I had spent that time building one good landing page and posting in three communities I cared about, I would be 4 months further along.
2. The buyer reads code, not marketing copy. My ICP is engineer-investors. They install the MCP server before they read the homepage. They check the GitHub repo before they check the pricing page. The homepage was the last thing I built and probably should have been first, but only because the things engineers actually read (the docs, the methodology paper, the source code) were already in place.
3. What they drive is the moment a skeptical buyer searches my name and sees a published paper, and the objection dissolves before it forms. (Paper is on SSRN, abstract 6606558, if you want to look it up.)
4. Anonymous works for builders, badly for buyers. I post under a pseudonym to keep the day-job and side-project separated. Engineers do not care. Investors absolutely care. The first cold-email round under the pseudonym got fewer responses than the same emails from a real-named address would have. If I am still here in six months I have to solve this.
5. Launches are a coin flip. Today I launched on Product Hunt. The post created at the right timestamp alongside 9 other launches that all featured. Mine did not. I have no idea why. I emailed support. I am not changing the product. I am writing this post.
6. Free distribution surfaces compound. The MCP server got A-tier on Glama. The dataset got Bronze on Kaggle. The paper is on SSRN with a DOI in queue. Each of these is a backlink and a discovery surface. None of them cost anything. All of them are still working at 3am while I am asleep.
7. The boring channels outwork the loud ones. The single highest-converting channel for me has been replying to specific comments on niche subs. Not posting. Not threading. Replying. The least-converting has been Twitter, where I have 1 follower after 6 months of effort. Match the channel to the buyer, not to the volume.

That is the ride-along so far. Six months in, paying users in the single digits, a real research footprint, and one failed Product Hunt launch. The deal-flow tool is called GitDealFlow if anyone is curious, but the post is not about the tool. The post is about what shipping it taught me about shipping.

Happy to answer questions about any of the seven.

I’ve been building a product around a simple question:

Can public GitHub activity tell you something useful about early-stage startup momentum?

The idea came from noticing that some technical companies seem to “get louder” in public code activity before the rest of their story becomes visible.

So I built a tool that tracks signals like contributor growth, shipping cadence, repo activity, and docs/issues movement.

The problem is not building it. The problem is positioning it.

I can make arguments for three audiences:

• founders who want to benchmark momentum
• investors who want better sourcing/diligence context
• startup researchers/operators who like data-rich tracking

If you were a solo founder building this, how would you decide which audience to go after first?

I’m happy to share the link in the comments if helpful.

I’ve been thinking about whether public engineering activity is an underrated input for startup investing, especially at pre-seed and seed where hard financial data is still thin.

Not vanity metrics. I mean things like:

• contributor growth
• release cadence
• new repo creation
• issue resolution
• documentation activity
• sustained acceleration over a few weeks, not one random spike

The bullish view is that real execution sometimes shows up in product and engineering behavior before it shows up in revenue, fundraising visibility, or founder narrative.

The skeptical view is just as strong:

• open-source noise
• contractor-driven bursts
• bot activity
• lots of code with weak connection to customer demand
• sectors where the most valuable progress is invisible from public repos

For people here who invest in startups:

1. Do you look at public engineering activity at all when evaluating early-stage companies?
2. Which patterns have actually been useful vs mostly misleading?
3. In which categories is this strongest: devtools, infra, AI tooling, security?
4. If you had to rank early signals, where would this sit relative to founder quality, customer pull, hiring, and market timing?

My instinct is that this is either a genuinely underused diligence input or a very smart-looking false positive machine. Curious which side people here land on.

When evaluating very early-stage software startups, how much weight do you give to publicly visible engineering activity?

I mean things like sustained contributor growth, faster release cadence, new repos, issue resolution, and documentation updates over a short period.

On one hand, it seems like this could reflect real execution and product momentum. On the other hand, open-source activity can be noisy and easy to misread.

For angels here:

1. Do you treat public engineering activity as meaningful during diligence, or mostly as background context?
2. Which patterns look genuinely useful to you, and which ones are usually noise?
3. What would you need alongside it before taking it seriously: customer traction, revenue, founder background, hiring, retention, or something else?

I’m interested in how investors separate real operating progress from activity that only looks impressive on the surface.

I am a senior software engineer who started writing angel checks two years ago.

For the first year I sourced deals the same way most people do. Twitter. Substack roundups. AngelList syndicates. Demo days. The problem with all of those: by the time the deal hits my inbox, it has been seen by 200 other people. I wanted to see the company before the deck existed.

Eight months ago I started building a dataset of public GitHub activity across 4,200 startup orgs. Weekly commit velocity, contributor count delta, weekend-commit ratio, repo creation rate. The question I cared about: does engineering activity show a pattern before a Series A is announced?

What I found, after 219 fundraise events.

Five patterns that DID show up 3 to 6 weeks before the round announcement:

1. Contributor-count step function. A jump of 4+ unique contributors in a 14-day window, sustained. Capital came in, hires landed, commits started.

2. Weekend-commit ratio doubling. Engineers shipping toward a deadline. Demo, fundraise demo, or product launch.

3. New repo creation in adjacent areas. A company spinning up an /infra-v2 or /enterprise repo two weeks before the round closes is putting Series A money to work in advance.

4. Sustained velocity above 1.5x baseline for 3+ weeks. Not a one-week spike. The acceleration has to persist to be signal.

5. New senior contributors landing. First-PR-ever-merged from accounts with 500+ public commits elsewhere is a hire signal that the rest of the cap-table data sees later.

Three patterns that LOOK like signal but are mostly noise:

A. Documentation sprints. Companies push docs in batches. It looks like activity. It is not signal.

B. Refactor-heavy weeks. Big rewrites inflate commit counts without indicating product progress. Filter by file-extension delta, not raw count.

C. Open-source-maintenance bursts. Companies with a popular OSS project get contributor spikes from external folks. Filter to commits from email addresses on the company domain.

Where the signal failed:

- 38 of the 219 events were rounds I did not predict from the GitHub data. Most were either non-tech (DTC, biotech, hardware) or had primary engineering on private repos I cannot see.

- Pre-seed rounds are mostly invisible on GitHub. The team has not shipped enough yet to leave a signature.

- M&A and partnership announcements do not show up. Engineering velocity does not predict acquirers.

So this is not a deal-flow oracle. It is one signal layer that complements network and Twitter and demo days. The hit rate is roughly [TBD: 64%] on the cases where the company has primary engineering on public GitHub. Sample is small enough to caveat heavily.

I posted the methodology and the full dataset on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6606558

Replication welcome. If you have a watchlist of startups you are tracking and want me to pull their GitHub numbers, drop the org names and I will pull what I can. Five-name limit because this takes time.

What I am NOT claiming: I am not running a fund. I am not telling you to invest in anything. The data is one input among many. It works on a specific slice of startups and breaks on others.

What changed for me: I stopped reading TechCrunch and started reading commit graphs.

I am a senior software engineer. I do not work at any of the companies below.

Two years ago I missed the CRWD run-up. Watched it from the sideline. Afterwards I started reading GitHub repos the way an analyst reads point-of-sale data, because engineering activity at a SaaS company is operational telemetry hiding in plain sight. Every commit is a timestamped event. Every contributor onboarding leaves a graph signature. The data is public. Nobody parses it.

Six weekends ago I picked 12 public SaaS names with their primary engineering on public GitHub orgs (CRWD, NET, DDOG, MDB, SNOW, ESTC, GTLB, S, TEAM, OKTA, HUBS, MNDY) and computed weekly commit velocity, weekend-commit ratio, and unique-contributor delta against an 8-week trailing baseline. The question: does engineering velocity acceleration show up before earnings prints?

What I found, in plain language:

- DDOG: contributor count widened roughly [TBD: 35%] in the 5 weeks before the [TBD: Q3 2024] beat. Weekend commits roughly [TBD: 2.4x] the baseline. Public price was flat through that window.

- MDB: velocity COLLAPSED roughly [TBD: 5 weeks] before the [TBD: Q1 2025] guide-down. Contributor count dropped, weekend commits stopped. Stock did not move until the print.

- NET: weekend commits roughly [TBD: doubled] in the 8 weeks before the [TBD: Q4 2024] print. Same pattern.

- 3 more cases like this. Numbers and chart in the dataset linked below.

Where the signal failed:

- M&A driven moves (one of the 12). Engineering does not predict acquirers.

- Pure rate-cut multiples expansion (two cases). Velocity does not move with the discount rate.

- Infra-monorepo orgs where most code lives in private repos (two cases). Public GitHub is a lossy proxy for those.

So the hit rate is real but not magical. Maybe [TBD: 6 of 9] of the cases where I had clean public-GitHub coverage. Could be coincidence on a sample that small. I posted the methodology, the 50-org universe I screened from, and the raw weekly counts on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6606558

Replication welcome. If anyone runs this against a different universe (your own watchlist, semis, fintech, whatever), happy to compare notes.

What I am NOT claiming: I am not telling you to buy or sell anything. I am not running a fund. The pattern works on a small sample of public SaaS where engineering happens in public. It probably does not transfer to companies where it does not.

What changed for me: I stopped checking earnings tickers and started checking their commit graphs.