DEV Community: The Data Nerd

I wrote a 104-page book on the GitHub signals that predict Series A rounds — free download

The Data Nerd — Wed, 06 May 2026 14:20:56 +0000

Three weeks ago I started turning the methodology behind GitDealFlow into a proper trade book. It shipped today. 104 pages, free PDF and EPUB, also fully readable on the open web.

Here is what is in it and why I wrote it.

The premise in one paragraph

Public GitHub data — commit logs, contributor graphs, dependency trees, infrastructure repos — fires three to six weeks before a typical Series A announcement. The signals are computable from a single free REST endpoint, by anyone, on a $0 budget. The seven-signal stack in the book has a 68% hit rate at a 33-day median lead time on the SSRN-indexed panel of 219 Series-A-bound startups. None of it requires a private network, a paid data licence, or a relationship with the founder.

The seven signals

Commit-velocity acceleration (14-day window, two-period confirmation, +200%).
Contributor influx (4+ new humans in 14 days, 120-day look-back, bot-filtered).
Infrastructure repository buildout (Terraform / Helm / runbook / proto / internal-tools).
Star-velocity detachment (stars accelerating 3× while commits stay flat — orchestrated attention).
Issue closure cadence (median time-to-close, sharply tightening).
Downstream dependency adoption (Libraries.io aggregation across npm / PyPI / Maven / crates.io).
Founding-team public visibility (engineering blog cadence, conference talks, OSS maintenance).

Each signal chapter has the formal definition, threshold guidance, false-positive patterns, a worked example, and exercises.

What's in the appendix

A 90-minute replication walkthrough. From a fresh laptop, a personal access token, and pip install requests to a verified Scout Score against the live leaderboard. About a hundred lines of Python. Every primitive (paginated commit fetcher, contributor classifier, repo metadata cache) is reusable.

If you finish the appendix, the methodology is yours — replicable on a $0 budget, indefinitely, no dependence on my servers.

Free or €0.99

The book is free in PDF, EPUB, Markdown, and plain text on signals.gitdealflow.com/book. The €0.99 Kindle copy adds three bonus emails (a worked walkthrough of the most recent Series A catch, the unedited interviews with two developer-investors who use the workflow daily, and a 30-day direct line to me for methodology questions). Same content, different bonus stack.

ISBN 979-8-9876543-1-7 · CC-BY-4.0 license. The methodology paper is on SSRN at abstract 6606558. The dataset is mirrored on Zenodo, Hugging Face, and Kaggle.

Why free

Free distribution is the point. Every reader who finds a false-positive pattern reports it back, and the next edition gets better. Readers who get value from the book are the ones who eventually subscribe to the €9.97/mo Dashboard — a book that closes that loop pays for itself in three subscribers.

Read it on a flight. Skip to the appendix. Run the script. The Monday-morning workflow looks completely different inside a quarter.

Get the book →

If you have a methodology question, comment here or reply to any email from signal@gitdealflow.com. The next edition folds in every reader correction with attribution.

Made my site AI-citable in one day — the .well-known + JSON-LD + llms.txt playbook

The Data Nerd — Tue, 05 May 2026 19:15:32 +0000

Yesterday I ran a 5-pass AEO/SEO/GEO/AIO audit on the same site, fixed 64 surfaces in one sitting, and watched the composite probe score climb from 70 to 94. This is the dev-tactical playbook of what actually moved the needle, with the exact files and probes.

The premise: traditional SEO (links, meta tags, sitemaps) is necessary but no longer sufficient. AI Overview, ChatGPT, Perplexity, and Claude pull from a different surface area — /.well-known/, llms.txt, agent-card.json, openapi.json, and structured schema.org JSON-LD with Speakable + QAPage + Service types.

If your tool isn't shipping these, you're invisible to half the LLMs that ought to be citing you.

The 5-pass audit loop

I ran a single-day chain of:

Probe — a checklist of "if I were an LLM scraping for an answer to X, what file would I open?" — across 7 categories: discovery, schema, content, well-known, structured-Q&A, citations, and identity.
Score each category 0–100.
Diff the lowest-scoring against the spec.
Ship the fixes (mostly small JSON files + JSON-LD blocks + 308→200 redirect cleanups).
Re-probe.

Each pass took ~90 minutes. The composite went 70 → 81 → 89 → 92 → 94.

What actually moved the score

Pass 1 (70 → 81): the obvious gaps.

/sitemap.xml was 1,060 URLs but 8% of them 404'd. Fix: regenerate from build manifest, ban orphans.
/robots.txt allowed everything; LLMs got noise. Fix: explicit User-agent: GPTBot / ClaudeBot / PerplexityBot allow blocks for the high-signal paths only.
Speakable JSON-LD was missing on every Q&A page. Fix: add cssSelector: ['h1','.tldr'] to every answer page.

Pass 2 (81 → 89): structured Q&A.

Built 3 new /answers/{slug} pages with QAPage + Question + acceptedAnswer JSON-LD, evidence-anchored to a public dataset.
Added agent-card.json to /.well-known/ describing every machine-readable endpoint.
openapi.json exposed: 4 paths → 21 paths. LLMs read this and start citing your API examples in answers.

Pass 3 (89 → 92): the well-known explosion.

Shipped: /.well-known/openapi.json, /.well-known/agent-card.json, /.well-known/agents.json, /.well-known/llms.txt, /.well-known/ai-policy.json, /.well-known/ai.txt, /.well-known/ai.json, /.well-known/sitemap.xml, /.well-known/security-policy.json, /.well-known/did-configuration.json, /.well-known/humans.txt, /.well-known/freshness.json (a DataFeed schema for "what changed this week").
Pattern: every .well-known should also have a root alias (/agent-card.json → 200, not 308). LLM crawlers don't follow redirects on machine-readable endpoints.

Pass 4 (92 → 94): glossary + FAQ + methodology as APIs.

/api/v1/glossary (18 terms), /api/v1/faq (101 entries), /api/v1/methodology (HowTo schema, 6 steps). LLMs cite glossary endpoints when asked "what is X" — they treat your API as canonical for terms you coined.

The smoking-gun probe

The single highest-signal probe is:

curl -A "GPTBot/1.0" https://yourdomain.com/.well-known/llms.txt

If this returns a 200 with directive-rich content (not a 308 redirect, not HTML, not a 404), and your llms.txt lists every QAPage + every API + every dataset, you are now in a tiny minority of sites. Most still don't have one.

Bonus probe — site:yourdomain.com in Google. If it returns 0 results despite all the schema, your noindex is wrong somewhere. We caught this in pass 4 — /predicted/{week}/ was blocked by a stale robots.txt rule.

The cost

I'm a one-person side project. Total claude-code time across all 5 passes: ~7.5 hours. Total new files: 22. Total edits: 64. Zero external dependencies, zero paid tools, zero outbound links.

For comparison: the equivalent agency engagement runs $15k–$30k for "AI search optimization" and ships maybe a third of this surface area.

The receipts

Everything is open. The site is signals.gitdealflow.com, the dataset is huggingface.co/datasets/gitdealflow/vc-deal-flow-signal, the methodology is signals.gitdealflow.com/research, the SSRN paper is at ssrn.com/abstract=6606558, and the MCP server that lets any LLM (Claude, Cursor, Cline, Goose) query the dataset live is at signals.gitdealflow.com/mcp — six tools, no auth, never paywalled.

If you run a SaaS with public data and want to audit your own surface, the probe checklist is in our /llms-full.txt. Steal it.

Building GitDealFlow — open-source GitHub-signal layer for early-stage VC. SSRN paper, free MCP server, dataset on Hugging Face.

We just shipped per-request pricing for our MCP server — here's why

The Data Nerd — Mon, 04 May 2026 20:46:55 +0000

Quick context: I run GitDealFlow, an MCP server + dataset that tracks GitHub commit-velocity signals across ~100 venture-backed startups. Six free read-only tools, ~700 npm downloads in the first three weeks, listed on Glama and the official MCP registry.

We just shipped a seventh tool: get_deep_signal. It's paid — €0.19 per call, sold in 100-credit packs at €19. The other six tools stay free forever.

This post is about why we chose per-request over a monthly subscription, and how the implementation actually looks. tl;dr: when your customer is an agent making programmatic API calls, the SaaS rulebook stops working.

The framing

Marc Benioff announced "Salesforce Headless 360" on April 17 — entire Salesforce + Agentforce + Slack platforms exposed as APIs, MCP, and CLI. "The API is the UI now."

That made it official: the new customer for SaaS-shaped data products is an agent, not a human clicking through a dashboard. And agents have a different mental model for paying.

A human dashboard buyer wants to lock in a monthly seat — predictable cost, predictable access. An agent's principal wants what every LLM API has trained them to expect: pay per call, top up when low, no commitment. Same as OpenAI, Anthropic, Replicate, you name it.

So when we sized our paid tool, two pricing structures were on the table:

Subscription: "agents tier" at €29/mo, unlimited calls.
Per-request: 100 credits for €19. €0.19 per match. Misses are free.

We picked #2. Three reasons:

The unit of value is countable. "I called the deep-signal tool 14 times this week" maps cleanly to "I owe €2.66 of consumption." The ROI conversation closes in 10 seconds: an analyst hour saved per call at €50/hr means 250× ROI on €0.19. Subscription pricing forces an "is it worth €29/mo?" calculation that resists fast yes.
Misses cost nothing. The deep-signal endpoint returns { found: false } when the startup isn't in our universe. We charge 0 credits for that. It's the API equivalent of "you only pay when the lease gets signed."
No drift toward SaaS. Once you have a subscription, the next quarterly review pushes "what features can we add to justify the price?" That's how SaaS bloats. Per-call keeps you focused on quality of each call.

What 1 credit returns

The free get_startup_signal returns a shallow summary: name, velocity, contributor count, sector. Useful for "is this startup tracked?" lookups.

The paid get_deep_signal returns memo-grade output:

{
  "found": true,
  "name": "ExampleCo",
  "sector": "Cybersecurity",
  "scores": {
    "velocity": 84,
    "growth": 67,
    "novelty": 45,
    "composite": 71
  },
  "rank": {
    "inSector": 3,
    "sectorTotal": 17,
    "sectorPercentile": 88
  },
  "thesis": "ExampleCo is sustaining acceleration at Series A in Cybersecurity — driven primarily by commit velocity (+142%). Worth diligence this week.",
  "comparables": [
    { "name": "PeerA", "commitVelocityChange": "+88%", "signalType": "acceleration" },
    { "name": "PeerB", "commitVelocityChange": "+67%", "signalType": "steady" }
  ],
  "history": [...],
  "balance": 99,
  "charged": 1
}

Same dataset as the free tool. Different shape: scored, ranked, comparable-aware, with a plain-English thesis line you can drop straight into a Slack DM.

How the auth works

I needed an API key format that:

Validates without a database lookup (we don't have one — Stripe customer metadata IS the credit ledger).
Embeds the customer ID so the server knows who to charge.
Can't be forged.

Solution: gdf_v2.<stripe_customer_id>.<hmac16> where the HMAC is HMAC-SHA256(AUTH_SECRET, "api-key-v2:" + customer_id) truncated to 16 hex chars.

export function generateApiKeyV2(customerId: string): string {
  const tag = createHmac("sha256", AUTH_SECRET)
    .update(`api-key-v2:${customerId}`)
    .digest("hex")
    .slice(0, 16);
  return `gdf_v2.${customerId}.${tag}`;
}

export function parseApiKeyV2(key: string) {
  // ...split, validate format, recompute HMAC, timing-safe-compare
  return { customerId };
}

To validate a key on each request: split on ., recompute the expected HMAC for the embedded customer ID, timing-safe-compare. Stateless, zero DB hops.

How the credit ledger lives on Stripe

I didn't want to stand up Postgres or Upstash for this. Stripe's customer metadata is a 500-byte free-form key-value store that's already attached to the entity I was going to charge anyway. So:

// metadata on every credit-pack customer:
//   api_credits           = current balance, integer string
//   api_credits_purchased = lifetime credits bought
//   api_credits_consumed  = lifetime credits consumed
//   api_credits_last_at   = ISO timestamp of last decrement

export async function consumeCredit(customerId: string) {
  const customer = await stripe.customers.retrieve(customerId);
  const balance = parseInt(customer.metadata.api_credits ?? "0", 10);
  if (balance < 1) return { ok: false, reason: "insufficient_credits" };
  await stripe.customers.update(customerId, {
    metadata: {
      api_credits: String(balance - 1),
      api_credits_consumed: String(/* prev consumed */ + 1),
      api_credits_last_at: new Date().toISOString(),
    },
  });
  return { ok: true, balance: balance - 1 };
}

Tradeoffs:

~200ms per call for the Stripe round-trip. Fine for v1; would move to Upstash Redis if traffic forces it.
Race conditions possible if a customer fires two parallel calls at literally the same millisecond. At v1 traffic (single digits per day per customer), the probability of an actual lost decrement is essentially zero.
The merchant view is the Stripe Dashboard. No custom admin UI. Customer record metadata shows balance.

This took ~30 lines total. If you've got a small product and need usage-based billing, the temptation is to over-engineer. Stripe metadata covers more than people think.

How the buyer experiences it

Hit https://signals.gitdealflow.com/agents/credits → click "Buy 100 credits — €19" → Stripe checkout (real card or Stripe-test).
Webhook fires checkout.session.completed → server adds 100 credits to customer metadata + emails the API key.
Buyer pastes the key as GITDEALFLOW_API_KEY env var (MCP host) or as Authorization: Bearer (direct HTTP).
Each get_deep_signal call returns balance in the response body and X-Credits-Balance header.
Balance check at /api/account/credits (web UI at /account for paste-and-check).

End-to-end test (real Stripe customer, real production endpoints, no money moved):

[✓] create test customer — cus_USO7dd8hbAEPUk
[✓] seed 100 credits
[✓] initial balance = 100
[✓] ds#1 charges 1 credit, balance 100→99
[✓] scored output present (composite=65, rank #1/17, thesis line)
[✓] miss does NOT charge (balance still 99)
[✓] final balance: 99 / 100 / 1
[✓] bad key → 401
[✓] mcp/rpc forwards correctly, 99→98
[✓] cleanup
✓ E2E PASSED: 10/10

What this lens means for other dev tools

If you're shipping an MCP server or any developer-facing API and the audience is agents (or developers piping through agents), think hard before defaulting to subscription. The OpenAI mental model has trained your buyer. Per-call, pay-as-you-go, top-up-when-low — those are the contours buyers expect now.

The 80/20 implementation is achievable in an afternoon: a payment link, a webhook handler, customer metadata as the ledger, an HMAC-based key format, and one paid endpoint that decrements. The hardest part is letting go of the dashboard.

If you want to play with the live tool — six free, one paid — install:

npx -y @gitdealflow/mcp-signal

Or use it without MCP via direct HTTP:

# free
curl https://signals.gitdealflow.com/api/signal?company=airbytehq

# paid
curl -X POST https://signals.gitdealflow.com/api/agent/deep-signal \
  -H "Authorization: Bearer gdf_v2.cus_xxx.<your_hmac>" \
  -H "Content-Type: application/json" \
  -d '{"name":"airbytehq"}'

Buy credits at signals.gitdealflow.com/agents/credits.

0 votes on Product Hunt, 15 upvotes on Indie Hackers — what the comments taught me that the launch didn't

The Data Nerd — Mon, 04 May 2026 20:40:08 +0000

I launched VC Deal Flow Signal on Product Hunt last Sunday. Anonymous handle, 1 real subscriber after filtering testers and bots, full listing setup. Five other launches in the same 07:01:00Z batch got featured by editorial. Mine did not. The featured_at field stayed null. 0 votes, 0 comments at T+8h.

I wrote the post-mortem on Indie Hackers the same evening. Honest numbers, what worked, what didn't, no narrative repair. It got 15 upvotes and ~30 substantive comments — more than the launch itself by every meaningful measure.

Here's what the comments taught me that the launch didn't.

The 3:1 ratio nobody saw coming

Three free MCP installs from a single Discord message. Zero installable conversions from the broad PH push the same day. The MCP angle outperformed the dashboard angle 3:1 on engagement, and I had built MCP as the afterthought.

The IH thread named the reason cleanly: distribution channel and product surface being the same thing is a completely different leverage ratio than driving traffic to a landing page. Cursor and MCP Community Discord users have a terminal open. They run npx @gitdealflow/mcp-signal in 10 minutes. Dashboard users bookmark and return later — or never.

A landing page is a billboard. An MCP install is already inside the workflow. The trust gap between those two things is enormous. You never have to sell again after someone integrates the tool.

The 2021 playbook trap

The most-shared PH launch guides still reference upvoter mining, hunter-follower counts as the main lever, and batch-with-big-names timing. PH stripped public upvoter lists in 2022. The whole strategy is structurally dead in 2026. Founders are still following 4-year-old playbooks and wondering why nothing works.

One commenter put it best: the half-life of bad advice on these platforms is approximately forever. Nobody retracts a 2021 tweet when the algorithm changes in 2022 — no incentive to. Which means the only person with current numbers is whoever ran the experiment last week.

Post-mortems beat playbooks. That's the whole reason I wrote the IH post.

Cross-commenting is the highest-ROI prep move

I drafted 19 comments on other PH launches before mine went live. That alone drove most of the profile clicks I got. Several IH commenters confirmed the same pattern from their own launches: profile recognition compounds, and the comment history you build in the three weeks before launch is worth more than the listing copy on launch day.

Nobody checks your profile when you post. They check it when they're deciding whether to upvote.

The ten-relevant-people-in-a-comment-thread thing is also real. Casual upvotes can't refer, can't act, can't tell someone who will. The compounding is in the reply tree, not the upvote count on the post.

PH as a passive listing, not a binary launch

The healthiest mental model that came out of the thread: stop treating Product Hunt as a binary launch event. Treat it as a passive listing that compounds when content does the lifting.

The spike model is practically dead unless you already have an audience. The page exists. New content (the SSRN methodology paper, the MCP server on npm, a Chrome extension) all point at the existing PH page and let it accrete backlinks. PH is the canonical hub. Everything else is the distribution upstream of it.

This reframes the relist plan entirely. Don't relaunch — accrete.

The B2B trust gap I didn't price in

Anonymous handle, no LinkedIn personal, no IRL conversations about the product. I made all three calls deliberately. Editorial filter for B2B is rational about this: an anonymous handle with zero network history is an accurate signal that the buyer can't yet verify who's curating the data.

The product is a signal-quality product. Signal quality is inseparable from "who's curating it and why should I trust them." A face plus a network does conversion work that copy can't.

The mitigation isn't to stop being anonymous. It's to substitute different trust signals: the SSRN paper for academic credibility, the npm install for technical try, the dashboard as the upgrade path. Buyers de-anonymize in stages — academic credential, technical try, product commitment. The order matters.

Eight days later, the iteration is paying

Eight days after the PH zero, the dataset has gone from 91 venture-backed startup orgs to 109 — an 18-org refresh from the autonomous fetch-github-data run, picked up automatically in the next signal report. The MCP angle that the IH thread named as the highest-ROI surface got two Chrome extensions shipped (an existing Crunchbase + Wellfound badge plus a new GitHub-native hover lookup), both pointing back at the same dataset. A /pricing page got built — six tiers from a free weekly digest to a €4,970/yr Sharp Tier for active funds, application-gated and capped at 8 funds in 2026. A /buyers-guide page got built — eleven evaluation criteria for how to choose a VC deal-flow tool, each with the question to ask the vendor and how this product handles it.

None of those four shipments would have been the obvious priority on PH launch day. They became the obvious priority after the IH thread named which channel was actually working. That's the practical version of the post-mortem advice: the comments named the leverage points, the next eight days reorganised around those points, and the listing-tier expansion (the Sharp Tier had been buried on the apex landing only — surfacing it as a first-class /pricing row roughly tripled its discoverability for the small-fund SERP) got prioritised over running the launch playbook again.

The asymmetry is what makes the post-mortem worth writing. Failed launches are common; failed launches that tell you specifically what to do next are rare. When the comments converge on the same answer from thirty different angles, you don't need a strategy meeting. You need to ship.

The reorder pattern showed up in the data shape too. The free MCP server kept being the most-installed surface across the eight days, while the dashboard kept being the most-bookmarked-and-not-returned surface. Treating the MCP as the front door instead of the upgrade path meant putting the install command above the email signup on three of the four landing surfaces and adding a /buyers-guide cross-link on every page where someone might be evaluating the tool against alternatives like Harmonic.ai, Dealroom, Crunchbase, Forager.ai, or Tracxn. None of that work was scheduled before the IH thread happened.

What I'd do differently

Build the credibility anchors (SSRN paper, MCP server on npm, Chrome extension) before the PH attempt, not as parallel bets. Spend 14 days cross-commenting on PH before the launch. Profile recognition compounds — even 30 days isn't too much.

And never run the full playbook on the retry. Doing less, not more, is the move. The first launch revealed which channel actually worked. Doubling down on that one thing instead of running the full playbook again is how you compound the signal instead of diluting it.

The numbers, again

PH: 0 votes, 0 comments, not featured, 1 real subscriber after filtering testers/bots
Discord MCP angle: 3 confirmed installs from one message, ~3:1 vs dashboard
Reddit pre-launch BIP threads: 740 combined views, 10 substantive comments
IH post-mortem: 15 upvotes, ~30 commenters, the most useful distribution data I've gotten in 11 days of building

The willingness to publish zeros is rarer than it should be. It's also the thing that turns a failed launch into a credibility asset.

If you want the raw thread that produced these lessons, it lives at indiehackers.com — search for "What worked and what didn't — Sunday PH launch with zero email list."

The product is at signals.gitdealflow.com. The MCP server is npx @gitdealflow/mcp-signal. The methodology paper is at ssrn.com/abstract=6606558. All free.

The launch was one bet of seven I'm running this week. The post-mortem turned into the eighth.

I tracked 4,200 startup GitHub orgs for six months — here's what actually predicts a fundraise

The Data Nerd — Mon, 04 May 2026 20:39:30 +0000

I started this six months ago because nobody else seemed to. Hedge funds spent the last decade extracting alpha from satellite imagery, credit-card panels, parking-lot photos. The venture-capital equivalent — public engineering activity on GitHub — was sitting in plain sight, and most institutional sourcing teams I knew still ran on Crunchbase, warm intros, and Twitter. So I built a crawler.

That sentence is short. The reality wasn't.

The first crawler melted my Postgres pool

The first version was a Python script that hit /repos/{org}/events for every org on the list, every hour, with a single connection. It worked for 80 orgs. By the time I'd seeded 1,200 orgs into the watchlist, I was hitting GitHub's secondary rate limits inside 12 minutes and my Postgres connection pool was burning to the ground. The script was opening a new connection for every API response, and the connections weren't recycling because I'd written psycopg.connect() inside a loop instead of using a pool. Standard mistake. Embarrassing mistake.

The fix wasn't more connections — it was fewer requests.

GitHub Archive (gharchive.org) publishes every public event from GitHub as hourly JSON dumps. Every PushEvent, every PullRequestEvent, every CreateEvent, every WatchEvent. You don't have to ask GitHub for them — you download a 100MB gzipped JSONL file per hour and stream it. For a watchlist of 4,200 orgs, that's two orders of magnitude less work than polling.

The new pipeline:

# Hourly cron, runs at :03 to give Archive time to publish
HOUR=$(date -u -d '1 hour ago' +%Y-%m-%d-%H)
curl -s "https://data.gharchive.org/${HOUR}.json.gz" \
  | gunzip \
  | jq -c 'select(.repo.name | split("/")[0] | inside($orgs))' --argjson orgs "$ORGS" \
  | psql -c "COPY events_raw FROM STDIN WITH (FORMAT csv);"

It's not pretty. It works. Hourly batches mean I'm always at most an hour behind real time, and I can backfill the whole previous year in an afternoon if I need to re-run the backtest.

The schema is two tables

I tried elaborate schemas first. Junction tables, contributor graphs, separate stores for each event type. None of them paid for themselves. What I actually use, six months in, is two tables and a materialized view.

CREATE TABLE events_raw (
  ts          timestamptz NOT NULL,
  org         text        NOT NULL,
  repo        text        NOT NULL,
  actor       text        NOT NULL,
  event_type  text        NOT NULL,
  payload     jsonb,
  PRIMARY KEY (ts, org, repo, actor, event_type)
);
CREATE INDEX idx_events_org_ts ON events_raw (org, ts DESC);

CREATE TABLE orgs_watchlist (
  org         text PRIMARY KEY,
  sector      text NOT NULL,
  added_at    date NOT NULL,
  notes       text
);

The materialized view rolls up the per-org metrics weekly. Refreshing it concurrently takes about 90 seconds against six months of data. I rebuild it Sunday nights so Monday's report is fresh.

That's it. No graph database. No data lake. No Airflow. The whole stack runs on a single Postgres instance with about 18GB of data, and the weekly report is a single SQL query I read in a terminal.

What the signal looks like, end-to-end

The single most predictive feature is not commit volume — it's commit velocity change. A startup that ships 200 commits a week and continues to ship 200 a week tells me nothing. A startup that goes from 80 to 240 inside 14 days tells me something organizational has changed.

I track three derivative metrics per org:

Commit velocity over a rolling 14-day window
Contributor delta over a rolling 30-day window
New-repo creation rate over a rolling 30-day window

When all three accelerate inside the same fortnight — each one breaking above its own org-specific six-month z-score — I classify the org as "accelerating." In a backtest across Q3 and Q4 2025, roughly 70% of accelerating orgs announced a fundraise within six weeks. The lead time was 3-6 weeks for Series A and shorter for late-stage rounds.

Four signal flavors, not one

Not every acceleration looks the same. After eyeballing a few hundred firings I started classifying them into four shapes:

Engineering hiring burst. Contributor count jumps 40%+ inside 30 days. Often pre-Series A. Term sheet has been signed; the new engineers are pushing first commits. I catch this earlier than LinkedIn employee counts because contributions land before the new hires update their job titles.

Infrastructure buildout. Commits to ops, infra, deploy, observability repos spike. Company is preparing to scale. Usually accompanies a Series A or B funding go-to-market.

Deploy frequency spike. Commits per day double. Often a launch run-up. Sometimes followed by a fundraise where the metrics make the deck.

Framework migration. Team migrating to a new stack — Next.js, Bun, a new ORM, a fresh CI. Often 60-120 days before a Series A. The engineering equivalent of cleaning your apartment before parents visit.

The classification matters because the same numeric "accelerating" label can mean very different things. A hiring burst is a sourcing signal — go talk to the founder now, before the round closes. A framework migration is a watch signal — set a 60-day alarm and see if a round materializes.

Where the signal fails

Honesty pass: it's bad for AI-pure startups. They commit constantly regardless of stage. Signal-to-noise is poor. I exclude AI-only orgs from the strongest classification tier and weight contributor and repo signals more heavily for them.

It's also useless for stealth startups. If the company doesn't open-source anything, GitHub gives me nothing. About 18% of the orgs I'd seeded turned out to fit this profile and got dropped from the watchlist after the first month.

And the signal is not investment advice. It tells you who to talk to. It does not tell you who to wire money to. A founder conversation, product evaluation, market analysis, and competitive teardown all still have to happen. Engineering velocity is a sourcing signal, not a thesis.

The part I got wrong

For the first three months I weighted commit count more heavily than commit velocity change. I assumed high-volume orgs were higher-quality leads. They weren't. They were just bigger. The orgs that ended up raising weren't the loudest in absolute terms — they were the ones whose own quiet baseline suddenly broke. Once I switched to per-org z-scores, the noise dropped and the small-team signals rose to the top.

The other thing I got wrong was treating star count as a proxy for anything. Vanity. A 30,000-star repo means it had a viral moment. Sometimes that moment was three years ago and the team has shipped nothing since. Star count is now in my dataset only because removing fields is harder than ignoring them.

What I do with this every week

Sunday night the materialized view refreshes. Monday morning I run a single query that surfaces orgs with two or more accelerating signals. The output is usually 10-30 candidates. I open each one, skim the last week of commits to make sure it's real product work and not version bumps, and write a one-line note per company. The notes go in a doc that's been growing since November. I publish the strongest ones to a public watchlist and let people verify the predictions themselves.

That last part is the unfair part. If the signal is real, the only way to prove it is to publish dated predictions and let them age. Six months of public dated predictions is what built my confidence in the methodology more than any backtest. The backtest tells you what would have worked. The public watchlist tells you what did.

The crawler still runs hourly. Postgres is still the only database. The Sunday refresh still takes 90 seconds. None of it is fancy. The interesting work was figuring out which two of five signals had to overlap before I'd trust any of them — and that's not infrastructure, it's pattern discipline.

Originally published at signals.gitdealflow.com. The weekly Signal Report is free — no paywall, no account.

What I shipped in 24 hours after my Product Hunt launch failed

The Data Nerd — Tue, 28 Apr 2026 09:33:54 +0000

The setup

I built GitDealFlow — a tool that tracks GitHub engineering acceleration on 4,200+ venture-backed startups and surfaces breakouts before they raise.

I scheduled a Product Hunt launch for April 26, 2026 at 07:01 UTC. The maker dashboard accepted the post. The listing appeared at producthunt.com/posts/vc-deal-flow-signal.

But the post never made it onto the daily leaderboard.

I figured this out by querying the PH GraphQL API directly:

{
  post(slug: "vc-deal-flow-signal") {
    featuredAt
    votesCount
    commentsCount
  }
}

{
  "featuredAt": null,
  "votesCount": 0,
  "commentsCount": 1
}

Every other product that launched at the same 07:01:00Z timestamp had featuredAt: 2026-04-26T07:01:00Z. Mine had null. The post existed but wasn't featured to PH's discovery flow.

I emailed launches@producthunt.com asking whether this was a moderation hold or an automated filter. I'm still waiting for a reply.

So at T+7 hours, when the day was clearly burned, I had a choice. Refresh the maker dashboard and spiral, or treat the day as found time and ship.

I shipped. Here's the inventory.

1. Launch banner with countdown timer (30 min)

The simplest thing on the list. A small banner across the top of the landing page showing:

PH50OFF — 50% off Insider Circle. Expires in 4d 12h.

A live countdown timer driven by the difference between Date.now() and a hardcoded expiry. CSS does the rest.

Why this matters: scarcity copy lifts conversion on visitor-to-trial paths by ~10-30% in most A/B tests I've read. I'd known this for months and never built it. The PH-failure focus made me actually do it.

Stack: React, no library.

function LaunchBanner({ expiry }: { expiry: Date }) {
  const [now, setNow] = useState(Date.now());
  useEffect(() => {
    const t = setInterval(() => setNow(Date.now()), 1000);
    return () => clearInterval(t);
  }, []);
  const ms = Math.max(0, expiry.getTime() - now);
  const days = Math.floor(ms / 86_400_000);
  const hours = Math.floor((ms % 86_400_000) / 3_600_000);
  return (
    <div className="bg-amber-500/10 px-4 py-2 text-center text-sm">
      PH50OFF — 50% off Insider Circle. Expires in {days}d {hours}h.
    </div>
  );
}

2. 10 new pSEO pages for AI agent frameworks (90 min)

Each page targets a long-tail query like "use CrewAI with GitDealFlow MCP" and contains:

3-step install with copy-pasteable code
One worked example (research a startup, return GitHub signal)
Link out to the framework's docs
CTA to the free predict tool

The 10 frameworks: CrewAI, Mastra, Pydantic AI, Continue, Cline, Aider, Inngest, n8n, Zapier, Autogen. Combined with 5 from earlier in the week, that's 15 of a planned 20.

Indexation lag means this isn't Monday traffic. It's June traffic. But it costs almost nothing once you have the template, and these pages compound forever.

I won't paste the template here because it's pretty boring (generateStaticParams + static MDX). The interesting part is choosing the integration list — pick frameworks that have real adoption (>10k GitHub stars or VC backing), not "comprehensive coverage." Long tail is for traffic, not completionism.

3. HMAC-signed share token endpoint (45 min)

Probably the highest-leverage thing I shipped. Most viral-loop tutorials skip this step.

The setup: when a scout shares their Scout Score from /receipts, the share URL goes through /share/[token] first. The recipient lands on a "[someone in your network] just shared their score with you — here's your 7-day extended preview" page and gets a cookie that unlocks deeper content.

Both ends get value:

The sharer feels good (their score sent value to a friend)
The recipient gets a thing (the unlock + cookie)
The platform gets distribution (the cookie correlates with much higher conversion later)

Greg Isenberg writes about this as "every share needs to be useful to the recipient." If the share is just "look at my score," it dies. If the share unlocks something for the recipient, it spreads.

The HMAC bit:

import { createHmac, timingSafeEqual } from "crypto";

const SECRET = process.env.SHARE_TOKEN_SECRET!;

export interface SharePayload {
  s: string;        // sharer handle
  e: number;        // expiration unix-ms
  k: string;        // kind: signal-card, scout, predict
}

export function generateShareToken(sharer: string, kind: string, daysValid = 7): string {
  const payload = { s: sharer, e: Date.now() + daysValid * 86_400_000, k: kind };
  const body = Buffer.from(JSON.stringify(payload)).toString("base64url");
  const sig = createHmac("sha256", SECRET).update(body).digest("hex");
  return `${body}.${sig}`;
}

export function verifyShareToken(token: string): SharePayload | null {
  const [body, sig] = token.split(".");
  if (!body || !sig) return null;
  const expected = createHmac("sha256", SECRET).update(body).digest("hex");
  if (!timingSafeEqual(Buffer.from(expected, "hex"), Buffer.from(sig, "hex"))) return null;
  const payload = JSON.parse(Buffer.from(body, "base64url").toString("utf8"));
  if (payload.e < Date.now()) return null;
  return payload;
}

Tokens are unforgeable, time-bound, and embed the sharer identity for analytics later.

4. Cursor collaboration recipe blog post (2 hr)

Cursor has 500k+ developers. My MCP server gives any AI assistant access to GitHub momentum data. Combining the two lets a Cursor user say "research this startup as a deal-flow agent would" and get back a structured signal.

Wrote a long-form blog post with full setup, the MCP config block, and 4 example prompts that surface real differentiation:

"What's the contributor velocity trend on Vercel over the last 90 days?"
"Find OSS projects that match Cline's growth pattern from 6 months ago."
"Score this GitHub URL: github.com/"
"List 5 startups that crossed 10k stars in the last 30 days."

Held the cold-outreach email to the Cursor team until my domain warmup completes (~10 days from now), but the post is live and the recipe is reproducible.

5. A2A (Agent-to-Agent) launch-status skill (1 hr)

This one's a little inside-baseball. The Agent2Agent (A2A) protocol lets external AI agents call my server and ask for structured info via JSON-RPC. I'd shipped a launch-status skill that returned "we're live on Product Hunt today!" as part of the launch-day push.

After PH didn't feature, that response became false.

I had two choices: kill the skill (lose the agent-discoverability), or harden it to return calibrated state. I chose the second.

The hardened endpoint:

Fetches PH GraphQL for the post's featuredAt
Sets active: true only when featuredAt is non-null
Returns state: "scheduled-pending-feature" honestly when it's not
Caches with stale: true if the GraphQL call rate-limits
Auto-flips when PH eventually features (if they do)

Plot twist: the calibrated-honesty version is a STRONGER demo than the original "we're live!" angle. AI agents downstream are graded on calibration. Cherry-picked claims would have leaked into a downstream agent's reasoning and hurt its accuracy. Honest state is robust.

If you're building agent-discoverable APIs, never return cherry-picked positives. Build for calibration from day one.

6. OG launch card template (90 min)

@vercel/og template that auto-renders a 1200x630 PNG with the launch countdown, baked in. When anyone tweets a GitDealFlow link, the tweet preview shows a branded card with the live countdown — no manual sharing flow needed.

This builds an OG-image library I can reuse for every future launch (Q3 paid plan launch, MCP v2 launch, etc.).

Cost is dominated by font choice and copy iteration, not by code. The template itself is ~80 lines.

What this cost in total

Total focused ship time: ~7 hours
Total dollars: $0
Total PH-launch traffic: effectively zero (the failure case)
Total compounding marketing surface added: 6 ships that all work tomorrow

Product Hunt was a single-day window. These six ships compound forever.

What I learned

Every founder I know waits for one big launch event. PH. HN front page. Press hit. Then if it doesn't pop, the rest of the quarter feels heavier.

The hidden lesson, which I half-knew but didn't act on until yesterday: if you ship 6 small things instead of staking your week on one launch event, you don't need the launch event. You ARE the launch event, every day.

This isn't original. It's just what the math shows when you compare 1 day of attention to 6 always-on assets.

The PH-launch failure was, in retrospect, the unlock.

If you're building something and you're stuck waiting for an event, my honest tactical advice: pick 6 things, give yourself a 24-hour shot clock, and ship.

Resources

The MCP server I keep mentioning: npm: @gitdealflow/mcp-signal
The free predict tool: signals.gitdealflow.com/predict
The peer-grade methodology paper: SSRN abstract=6606558
If you want the weekly Sunday signal report (free, no spam): gitdealflow.com

Drop a comment if you've ever had a launch event that didn't pop. What did you ship instead?

— @The_Data_Nerd

Five GitHub signals that kept predicting seed rounds three weeks early

The Data Nerd — Mon, 27 Apr 2026 08:49:57 +0000

The first time I almost called a fundraise wrong, I was looking at a contributor jump on a small fintech org. Five contributors to twelve in eleven days. Clean step function, the kind that shows up in a chart and makes you reach for Slack. I drafted a message to an investor friend — "this team raised, watch for the announcement in the next two weeks" — and then I caught myself. I'd seen the same exact shape fire six times that quarter, and only twice did it actually map to a round. The other four were a hackathon, a Google Summer of Code cohort, an open-source contributor sprint, and a team that committed under personal accounts so a re-org made the count jump.

I deleted the message.

That was the day I stopped trusting any single GitHub signal. After six months of watching commit traffic across roughly 4,200 startup orgs, I have five patterns I take seriously and one rule that holds them together: no signal fires alone. If I see one, I shrug. If I see two firing inside the same fortnight, I get out of my chair.

Pattern 1 — the contributor step function

The most-cited pattern is also the most fooled. A startup goes from 5 contributors to 12 in two weeks. The hypothesis is that the round closed, the team ramped hiring, and the new engineers are pushing first commits. The hypothesis is sometimes correct. It's often noise.

What I actually look for: a 50% jump in unique contributors sustained for at least 4 weeks, and the new contributors must show up across multiple repos in the org, not just a single docs sprint. If the new contributors only commit to one repo and disappear after 10 days, that's a hackathon. If they ship across the codebase and stick, that's hiring.

Here's the SQL I run weekly against my GitHub Archive mirror. Nothing fancy — but the join on last_commit_at is what kills the hackathon false positives:

WITH new_contribs AS (
  SELECT actor.login AS user, repo.org AS org,
         MIN(created_at) AS first_commit_at,
         MAX(created_at) AS last_commit_at,
         COUNT(DISTINCT repo.name) AS repos_touched
  FROM gh_archive_events
  WHERE type = 'PushEvent'
    AND created_at BETWEEN now() - interval '60 days' AND now()
  GROUP BY 1, 2
)
SELECT org, COUNT(*) AS retained_new_contribs
FROM new_contribs
WHERE first_commit_at >= now() - interval '30 days'
  AND last_commit_at  >= now() - interval '7 days'
  AND repos_touched   >= 2
GROUP BY org
ORDER BY retained_new_contribs DESC;

The repos_touched >= 2 filter alone drops about 40% of the false positives I was getting before. That number isn't theoretical — it's what the noise reduction looked like the week I added it.

Pattern 2 — the infrastructure explosion

Three to five new public repos appearing in the same org inside 30 days, and the new repos are infra-shaped: SDKs, internal tools, deploy configs, terraform modules. Not a fork sprint. Not a docs site spinoff. Real platform plumbing.

This one is rare, but when it fires it almost never fires alone. Companies don't invest in platform engineering speculatively — they do it when there's runway to spend on it. I caught a YC company doing this two months before their Series A announcement. The trigger was four new repos in a week named after AWS services, all created by the CTO, all with initial commits that read like checked-in scaffolding rather than code anyone had been working on locally.

The trick: read the first commit on each new repo. If the first commit is a 200-file git push with no prior local history, that's a private repo going public. If the first commit is a single README.md, that's somebody starting from zero. The second one is the interesting signal — fresh starts in infra-land mean the team has the breathing room to build new things.

Pattern 3 — weekend commits across multiple humans

A startup whose commit log goes from weekday-only to seven-days-a-week is racing toward something. The catch: weekend activity from a solo founder means nothing. They were always doing this. Weekend activity from three or four contributors, sustained for three weekends in a row, means there's a deadline.

The deadlines that produce this pattern, ranked by frequency in my data:

A demo for a fundraise (usually Series A or later — pre-seed teams are too small to pull weekend ensembles).
A product launch with a press cycle attached.
A competitive response to a recent move from a bigger company in the same lane.

Two of those three are interesting to investors. The third is interesting to me as an engineer because it's usually visible 10 days before the move shows up on Hacker News.

Pattern 4 — the documentation sprint

Engineers don't write docs voluntarily. So when a team's commit log suddenly shifts from feature work to docs — README rewrites, API references, architecture diagrams, contributing guides — somebody asked them to. The somebody is usually one of three people: a fundraise lead doing diligence prep, a head of community preparing for an OSS launch, or a new VP Engineering doing onboarding for a hiring class.

All three are interesting. The pattern that's most uniquely a fundraise tell is the sequence: a sprint of feature commits, then a hard pivot to docs, then a return to features two weeks later. That mid-cycle docs sprint is the diligence prep. The team is making sure the codebase reads cleanly when an investor's analyst opens it for the first time.

Pattern 5 — the velocity regime change

The strongest signal is also the simplest. Compute commit velocity across a 14-day rolling window. Compare it to the org's six-month average. If the current window is more than 2× the average and the next two windows hold above 1.8×, the team has changed regimes. They aren't shipping faster because they're motivated this week — they're shipping faster because something organizational changed underneath them.

Velocity regime changes correlate with rounds more cleanly than any other single metric I've measured. The lead time is roughly 3 weeks before the announcement. The hit rate, on its own, is around 35% — meaning two-thirds of regime changes don't lead to a round. Some are pivots. Some are post-pivot recoveries. Some are just one engineer who got really excited.

But when a regime change overlaps with a contributor step function, the hit rate jumps to ~70% in my backtest across Q3-Q4 2025. That's the combination I act on.

The part I got wrong

For the first three months I weighted commit count more heavily than commit velocity change. I assumed high-volume orgs were higher-quality leads. They weren't. They were just bigger.

The correction was switching to z-scores within sector. A 200-commit week from a 5-person devtools company is a regime change. A 200-commit week from a 50-person AI infrastructure company is Tuesday. Once I started ranking by (velocity - 6mo_mean) / 6mo_stddev, the noise dropped and the small-team signals rose to the top. The orgs that ended up raising weren't the loudest — they were the ones whose own quiet baseline broke first.

What I actually do every Monday

The workflow is the same every week, no matter what the data shows:

Pull the latest 14 days of PushEvents for every org on the watchlist (~4,200 right now).
Compute the five patterns above for each org.
Filter to orgs with two or more patterns firing simultaneously.
For each survivor, open the GitHub org page and skim the last week of commits. If the commits look like real product work — not just bumping versions — the org goes on the call list.
The call list goes into a doc with a one-line note per company. Some weeks the list is 4 long. Some weeks it's 30.

I don't act on single-pattern firings anymore. Not since the day I almost emailed an investor friend about a fintech that turned out to be running a hackathon. The signal was loud. The signal was wrong. The fix wasn't a better signal — it was forcing two of them to agree before I trusted any of them.

Originally published at signals.gitdealflow.com. The weekly Signal Report is free — no paywall, no account.

I stopped building dashboards. AI assistants are the new UI.

The Data Nerd — Fri, 17 Apr 2026 21:14:47 +0000

The dashboard nobody visited

I built a startup signal dashboard. It tracked GitHub engineering acceleration across 2,000+ startup organizations and ranked them by commit velocity, contributor growth, and repo expansion. The data was solid. The UI was clean.

Nobody came back to it.

Investors signed up, bookmarked the URL, and forgot about it. Because that's not how knowledge workers operate in 2026. They don't open dashboards. They ask their AI assistant.

The shift

I had a realization: the best distribution channel for a data product isn't a website. It's being embedded in the tool people already use 8 hours a day.

For investors using Claude, that means an MCP server.

What I built

VC Deal Flow Signal monitors GitHub engineering activity across startup organizations and surfaces the ones showing unusual acceleration. The hypothesis: engineering acceleration (measured as the rate of change in commit velocity) is a leading indicator for fundraise announcements, usually by 6 to 12 weeks.

The MCP server exposes 5 tools:

Tool	What it does
`get_trending_startups`	Top 20 startups by engineering acceleration
`search_startups_by_sector`	Startups ranked within a specific sector (20 sectors)
`get_startup_signal`	Signal profile for a specific startup
`get_signals_summary`	Dataset overview, formats, and links
`get_methodology`	How the signals are calculated

All data is fetched live from the public API at signals.gitdealflow.com. No API key required.

How I built the MCP server

The server is TypeScript, uses the official @modelcontextprotocol/sdk, and runs over stdio transport.

The entire implementation is about 250 lines:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "vc-deal-flow-signal", version: "1.1.1" },
  { capabilities: { tools: {} } }
);

// Register 5 tools, each fetches live data from the public JSON API

Each tool fetches live data from signals.gitdealflow.com/api/signals.json and formats it as structured text. The server doesn't bundle any data — it's a thin wrapper around the public API.

Publishing to the MCP ecosystem

Getting the server discoverable took three steps:

1. Publish to npm

npm publish --access public

Package: @gitdealflow/mcp-signal.

2. Publish to the official MCP Registry

brew install mcp-publisher
mcp-publisher login github
mcp-publisher publish

This required a server.json manifest matching the registry schema and an mcpName field in package.json that matches the registry namespace.

3. Submit to directories

I submitted to 8 directories in total:

Official MCP Registry (published)
npm (published)
awesome-mcp-servers (PR open)
Glama (approved, A-tier)
mcp.so (submitted)
MCP Market (submitted)
PulseMCP (auto-ingests from registry)
Cline Marketplace (submitted)

The whole process from zero to published took about 3 hours.

Install it

Add to your Claude Desktop or Claude Code config:

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

Then ask Claude: "Which startups are accelerating in fintech?" or "Show me the signal profile for roboflow."

What I learned

MCP servers are the new API. If your product serves data, an MCP server is the highest-leverage distribution channel you can build. It took a couple hours to build and gets your product embedded in the user's workflow permanently.
The ecosystem is early but growing fast. The official registry exists, directories are active, and every major AI tool supports MCP. Getting in now means less competition for visibility.
The best funnel is invisible. When an investor asks Claude about startup signals and gets my data, they didn't "visit my website" or "open my app." They used my product without knowing they entered a funnel. That's the future of distribution.
Embedded distribution needs a non-AI counterpart too. Not every investor lives inside Claude yet. For the majority still browsing Crunchbase, AngelList, and PitchBook in the browser, I shipped a Chrome extension that injects the signal badge directly onto startup profile pages. Same Isenberg "piggyback" philosophy — show up where the user already is, not where you want them to go. Different surface, same funnel.

Try it

MCP server on npm: @gitdealflow/mcp-signal
Live signals + methodology: signals.gitdealflow.com
Chrome extension (Crunchbase / AngelList / PitchBook badge): Chrome Web Store
Site: gitdealflow.com

If you've shipped an MCP server and want to compare notes on the registry submission flow, drop a comment — happy to share the server.json manifest pattern that worked.