Frequently Asked Questions

Enterprise SaaS teams operate under structural throttles that AI or developer-tools companies do not: SOC 2 and ISO 27001 change-control processes require review gates before deploys, enterprise customer contracts specify change-notification windows, and senior buyers are sensitive to regression risk. These constraints mean the average enterprise SaaS team commits less frequently than a comparably sized consumer or dev-tools team. The implication is that acceleration against this lower baseline is more statistically meaningful — a 50% velocity increase at an enterprise SaaS company is a stronger signal than the same move at an AI startup.

The integration API buildout pattern occurs when an enterprise SaaS company creates a cluster of new repositories within 20–35 days, each dedicated to integrations with major CRM, ERP, or productivity platforms — Salesforce, HubSpot, Workday, Slack, or Microsoft 365. These repositories typically appear simultaneously, signaling a coordinated product initiative driven by enterprise customer demand. The pattern is a reliable Series A and B precursor because it indicates product-market fit in the enterprise channel: customers are requesting integrations, which means they are already using the core product at meaningful scale.

Compliance-driven bursts are characterized by high activity in configuration, policy, and infrastructure repositories while product-facing repositories remain flat. The diagnostic check is repository segmentation: inspect which repos are accelerating. If the acceleration is concentrated in repositories named audit, compliance, soc2, security-controls, or infra-policy, treat it as a compliance cycle. If the acceleration is in product repositories, client SDKs, or integration modules — or runs concurrently with compliance work — the signal is worth investigating further.

A public SDK or CLI release indicates the company is confident enough in its API stability to invite external developers to build on top of it — a platform bet that typically follows a strong Series A or substantial customer traction. SDK repositories also attract external contributors, providing a secondary confirmation signal: if the SDK repository gains stars and external forks within four weeks of creation, the market is validating the platform play in real time.

Many enterprise SaaS startups maintain a very small active contributor pool for extended periods — two to four engineers committing to a handful of repositories for 6–15 months. When contributor count jumps from that compressed state, the move is almost always capital-driven: the company has raised, is deploying capital, and is hiring. This contributor compression reversal is more diagnostic in enterprise SaaS than in AI or developer-tools, where external community contributors can produce similar contributor-count jumps that are unrelated to the company's financials.

Enterprise SaaS teams often operate on two-week sprint cycles that produce naturally lumpy commit distributions — a heavy push in sprint weeks followed by relative quiet during planning. A 14-day window can catch one half of a sprint cycle and misread the quiet half as deceleration, or vice versa. The 28-day window smooths over this sprint artifact and produces a more accurate read of whether the team's overall pace is genuinely changing. The DORA research confirms that sprint-level deployment frequency variation is a standard characteristic of mature engineering teams in enterprise environments [4].

Multi-module expansion is the pattern where an enterprise SaaS company creates several new repositories within a 30-to-45-day window, each representing a distinct product surface — an admin dashboard, an analytics module, a webhook service, a developer API, a customer-facing portal. This decomposition is typically driven by enterprise customer requirements for custom deployment or integration. At the Series A-to-Series B inflection, multi-module expansion is the most reliable structural signal the panel has identified for enterprise SaaS, because it reflects a company moving from a single product to a platform architecture.

They can, but the pre-seed signal is weak in this sector. Most enterprise SaaS teams at pre-seed are two to four engineers working partly in private repositories with a thin public footprint. The practical recommendation is to treat pre-seed enterprise SaaS GitHub signals as verification tools — confirming that a team you encountered through other channels is actively building — rather than cold-discovery tools. Seed and Series A are where the GitHub signal becomes discovery-grade for this sector.

Engineering acceleration is the rate of change in a startup's public GitHub engineering output, expressed as the percentage change in 14-day commit velocity compared to the prior 14-day window. A team that goes from 20 commits per period to 40 shows +100% acceleration. The metric measures whether a team is speeding up relative to its own historical baseline, which is more informative than raw commit volume because it controls for differences in team size, commit conventions, and codebase complexity.

They are unrelated concepts that share a word. A startup accelerator is a fixed-term program (Y Combinator, Techstars) that founders join for mentorship, capital, and networking. Engineering acceleration is a quantitative signal computed from a startup's GitHub activity. Throughout this playbook, engineering acceleration always refers to code-side momentum measured in public commit, contributor, and repository activity — not program participation.

The causal chain is short: a startup decides to raise capital or has just closed a round, this drives hiring and a sprint to a milestone, that activity produces commits faster than the team's normal rate, and the change is observable in public GitHub data days after it happens. Press coverage, Crunchbase entries, and SEC filings follow weeks later. Tracking commit velocity catches step three before steps four through six are visible to traditional databases.

Across the 4,200-startup panel maintained at VC Deal Flow Signal, the median lead time between a sustained acceleration signal and a public fundraise announcement is 3 to 6 weeks. The distribution has a long tail: roughly 12 percent of breakout signals do not result in any announced fundraise within 12 weeks, often because the round was extended, the company quietly raised through a SAFE, or the signal reflected a launch rather than a fundraise.

A useful working threshold is +100% sustained over two consecutive 14-day windows. One-period spikes are often noise: a hiring sprint, a hackathon, a single contributor onboarding. Sustained doubling across at least 28 days is the most reliable threshold for prioritizing investor attention. Different sectors have different baselines, and pre-seed teams with very low absolute volume require larger percentage moves to clear the noise floor.

In theory yes; in practice it is expensive and easy to detect. A team can pad commit counts with mechanical edits, but contributor growth, repository creation, and language-mix changes are harder to fake. Most importantly, gaming the signal requires sustained effort from multiple contributors over weeks, which is itself a form of real engineering activity. Detecting gaming requires looking at commit size, file diversity, and contributor recency — the same checks a careful investor performs anyway.

It works for any startup whose product or core platform is built on public code. That covers a broader population than developer tools — fintech infrastructure, climate-tech sensor stacks, healthcare APIs, e-commerce platforms with custom storefronts, and consumer apps with public iOS or Android repositories all leave engineering footprints. Pure marketplaces, services businesses, and consumer-only products with closed codebases are not well covered by this signal.

Hiring data has a longer lead time at the very top of the funnel — a job posting precedes the actual engineering output by weeks. But hiring data is also noisier: many postings never close, many teams hire and then fail to ship, and visible hiring activity shows up in LinkedIn long before the team's first GitHub commit. Engineering acceleration is downstream of hiring, which makes it lower-noise: by the time a team is shipping faster, the hires they made are already proving productive. The two signals are complementary.

DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore) measure the quality of an engineering process — how reliably a team ships. Engineering acceleration measures the rate of change in engineering output volume — whether a team is speeding up. DORA is internal and requires CI/CD telemetry; acceleration is external and reads off public commit activity. They are useful in different contexts: DORA for engineering management, acceleration for investor sourcing.

The pragmatic integration is a weekly digest: every Monday, review the top 20 startups in your sectors of interest ranked by acceleration, cross-reference against your CRM for any prior contact, prioritize the unflagged ones for a 30-minute desk dive, and tag the rest for monitoring. The signal complements rather than replaces existing sourcing: founder networks, demo days, and accelerator pipelines stay intact; engineering acceleration adds an external, quantitative top-of-funnel feed that is hard to source any other way.

Alternative data sources are any signals outside the standard Crunchbase or LinkedIn pipeline that reveal startup traction before it shows up in a fundraise announcement. Examples include GitHub commit velocity, SEC Form D filings, npm package downloads, Discord server growth, and SSL certificate transparency logs. Each source has a different lead time – some surface signals 6-12 weeks before a traditional database, which is the window that matters for angels who want to reach founders before a round is crowded.

GitHub engineering acceleration typically gives the longest lead time, averaging 6-12 weeks before fundraise announcements. SEC Form D filings also give a structural edge because they are filed within 15 days of a first sale of securities, and most press coverage follows 4-6 weeks later. SSL certificate transparency logs and DNS record changes can flag infrastructure buildouts even earlier, though they require more interpretation.

No. Most of the 47 sources in this guide are free or have a generous free tier. GitHub, npm, PyPI, Docker Hub, SEC EDGAR, Companies House UK, USPTO, FDA, ClinicalTrials.gov, OpenAlex, bioRxiv, Hugging Face, and Google Trends are all free with public APIs or web interfaces. Paid sources like Specter, Synaptic, and Predictleads are only worth the spend if you are sourcing at scale; a solo angel can build a credible signal stack entirely from free sources.

Engineering acceleration is the rate of change in a startup's commit velocity – not absolute output, but whether engineering activity is speeding up relative to the company's own baseline. When a startup's commit velocity doubles in two weeks, something fundamental has changed: new hires, product-market fit, or fundraise-driven shipping. VC Deal Flow Signal tracks this metric across 20 sectors as a leading indicator of startup momentum.

In VC Deal Flow Signal's data, engineering acceleration signals precede fundraise announcements by three to six weeks on average. The pattern starts with rising commit velocity in weeks 1-2, becomes obvious in weeks 3-4 with new repositories and classifiable signal types, and the fundraise announcement typically follows in weeks 8-12. Reaching out to founders in weeks 2-4 puts investors ahead of the crowd.

While individual commits can be trivially created, sustained engineering acceleration is very difficult to fake. VC Deal Flow Signal measures change from baseline rather than absolute counts, which filters out documentation sprints, CI/CD noise, and inflated commit volumes. A genuine product sprint looks fundamentally different from artificial activity when compared to a company's own historical patterns.

Deal flow signal is any data-driven indicator that helps an investor identify a promising startup before traditional deal sourcing channels – warm introductions, pitch decks, demo days, and press coverage – surface it. The most common types include engineering signals (GitHub commit velocity), hiring signals (job postings), web traffic signals, and social signals. Engineering signals provide the longest lead time at 6-12 weeks before fundraise announcements.

Investors can use four main types of alternative data for deal sourcing: engineering activity from GitHub (6-12 weeks lead time), hiring signals from job boards and LinkedIn (4-8 weeks), web traffic data from tools like SimilarWeb (4-6 weeks), and social signals from Twitter, Hacker News, and Product Hunt (1-2 weeks). GitHub engineering data has the highest lead time and is the hardest to game.

Engineering signals from GitHub typically provide 6-12 weeks of lead time over traditional deal flow channels. Traditional deal flow – Crunchbase alerts, warm introductions, press coverage – surfaces companies after they have already raised or are well into a competitive round. Engineering acceleration signals appear when the team starts building, which is weeks before any public announcement.

No. Public GitHub data cannot replace a proper technical deep dive with the engineering team. But it can do something equally valuable: help investors decide which companies deserve that deep dive in the first place. It serves as a fast screening tool at the sourcing stage and a verification tool at the due diligence stage, complementing – not replacing – traditional technical evaluation.

Investors should check five things: (1) commit velocity consistency – regular shipping vs. erratic bursts, (2) contributor count and growth – a proxy for team size and scaling, (3) technology choices – whether the stack matches the company's stage, (4) new repository creation – signs of platform building, and (5) the ratio of product code to maintenance activity. These checks take 2-5 minutes per company.

Using public data for investment decisions is legal and common practice. However, investors should not contact individual contributors directly or attempt to recruit from portfolio companies based on GitHub profiles. GitHub data should be one signal among many – never the sole basis for an investment decision. The strongest investment thesis combines engineering signals with market analysis, founder evaluation, and customer reference checks.

Five GitHub patterns reliably precede fundraise announcements: (1) The Contributor Step Function – a sudden 50%+ jump in unique contributors, indicating post-round hiring, (2) The Infrastructure Explosion – 3-5 new repos in a month, signaling platform buildout, (3) The Weekend Surge – sustained 7-day commit patterns from multiple contributors, (4) The Documentation Sprint – proactive documentation suggesting preparation for scrutiny, and (5) The Velocity Regime Change – commit velocity exceeding the 6-month average by 100%+.

GitHub patterns are leading indicators, not guarantees. They appear with enough regularity to be useful – particularly when multiple patterns overlap – but not all engineering acceleration leads to fundraising. Some acceleration reflects product-market fit, pivots, or hackathon activity. The patterns are most reliable when a startup shows two or more signals simultaneously, such as contributor growth combined with a velocity regime change.

The strongest combination is Pattern 1 (contributor step function – sudden team growth) plus Pattern 5 (velocity regime change – sustained doubling of commit velocity). When both appear simultaneously, the startup has almost certainly either just closed a round or is in the middle of one. The new hires are shipping code at an accelerated pace, and the compound signal is very difficult to produce without real organizational change.

Alternative data in venture capital is any dataset that reveals startup traction before it appears through conventional deal sourcing channels. The main categories include engineering activity from GitHub (commit velocity, contributor growth), hiring signals from job boards, web traffic from analytics tools, social mentions from platforms like Twitter and Hacker News, and patent filings. Unlike traditional deal flow data (funding announcements, press, warm intros), alternative data provides a leading rather than lagging indicator.

GitHub data stands out among alternative data sources because it is continuous (updated daily, not monthly), free and public (no scraping or paid tools required), hard to fake (commits represent real engineering work), and reveals intent (the type of activity tells you what phase the company is in). Despite these properties, almost no investor monitors GitHub systematically – creating an information asymmetry for those who do.

Quantitative investment firms have used alternative data in public markets for over a decade – satellite imagery of parking lots, credit card transactions, app downloads. The edge comes not from exclusive data but from reading what others ignore, faster and more consistently. The same principle applies to venture capital: every investor has access to GitHub, but almost none monitor it systematically. Building a workflow around engineering signals creates a structural timing advantage.

Investors can find deals before Crunchbase using three signal types: (1) GitHub engineering signals – the earliest indicator, detecting commit velocity spikes 6-12 weeks before fundraise announcements, (2) community signals from Hacker News, Product Hunt, and Indie Hackers – variable lead time, wide coverage, and (3) hiring signals from job boards and LinkedIn – 4-8 weeks lead time. Combining all three with Crunchbase for verification gives both timing advantage and diligence depth.

GitHub engineering acceleration is the earliest publicly available signal of startup momentum. The logic is straightforward: engineering acceleration precedes product milestones, which precede fundraise decisions, which precede Crunchbase entries. When a startup's commit velocity doubles in a two-week window and the change is sustained, the underlying cause – post-fundraise scaling, product-market fit, or launch preparation – is already in motion 6-12 weeks before any public announcement.

GitHub engineering signals provide 6-12 weeks of lead time over Crunchbase alerts. Crunchbase alerts trigger on fundraise announcements, which are published after the round closes – zero lead time. GitHub signals detect acceleration patterns while the round is still in progress or before fundraising even begins. The top movers in VC Deal Flow Signal's weekly rankings consistently include companies that announce raises 4-8 weeks later.

Investors should track seven engineering metrics from public GitHub data: (1) commit velocity – 14-day rolling commit count, (2) commit velocity change – the percentage change vs. prior period (the primary signal), (3) contributor count – proxy for team size, (4) contributor growth rate – indicates hiring bursts, (5) new repository count – signals infrastructure buildout, (6) weekend commit ratio – indicates deadline pressure, and (7) language/framework distribution – reveals technical maturity and stack choices.

Commit velocity change – the percentage change in 14-day commit count compared to the prior window – is the single most useful engineering metric for investors. It measures acceleration rather than absolute volume, which makes it comparable across startups of different sizes. A sustained velocity change above +50% for 3 or more consecutive windows is a meaningful signal. Above +100% is a regime change that has historically preceded fundraise announcements.

A quick screening checklist: (1) Is commit velocity change positive and above 50%? (2) Has contributor count grown recently? (3) Are there new repos in the last 30 days? (4) Is the activity product-related, not just docs or CI/CD? (5) Does the tech stack match the company's pitch? If a startup passes all five checks, it deserves a deeper look. If it fails the first two, the engineering signal is not there. VC Deal Flow Signal automates checks 1-4 across 20 sectors weekly.

Engineering acceleration measures the rate of change in a startup's engineering output relative to its own historical baseline. It is calculated as the percentage change in 14-day GitHub commit velocity versus the prior period. A +100% acceleration means the team doubled its commit rate. The metric is computed per startup, not across the population, which means a small team and a large team are measured against their own historical pace rather than each other.

No — they are unrelated concepts that share a word. A startup accelerator (Y Combinator, Techstars, 500 Global) is a fixed-term program founders join for mentorship, capital, and networking. Engineering acceleration, as defined at VC Deal Flow Signal, is a quantitative signal computed entirely from a startup's public GitHub activity. Throughout this site, the term refers exclusively to code-side momentum: GitHub commit velocity, contributor growth, repository creation. It has nothing to do with program participation.

Engineering acceleration is a leading indicator of startup momentum. When a team accelerates its engineering output, the cause is usually post-fundraise scaling, product-market fit iteration, or launch preparation — all of which precede the public signals (press coverage, Crunchbase entries, hiring announcements) that most investors rely on. Catching the change at the GitHub layer typically gives investors a 3 to 6 week lead time over the press cycle.

DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore) measure engineering process quality — how reliably a team ships. Engineering acceleration measures output momentum — whether the team is speeding up. DORA requires internal CI/CD access; acceleration is computed from public GitHub data, making it useful as an external investment signal. The two are complementary: DORA helps engineering managers; acceleration helps investors source.

A useful working threshold is +100% sustained over two consecutive 14-day windows. One-period spikes are usually noise — a hackathon, a single contributor onboarding, a documentation push. The two-period confirmation rule filters most of that noise. Pre-seed teams with very low absolute volume require larger percentage moves (often +200% or more) to clear the noise floor; later-stage teams can show meaningful signals at +50% because their absolute output is large.

Acceleration patterns sort into four operational types. The hiring burst combines rising commit velocity with rising contributor count — the strongest fundraise predictor. The shipping sprint shows velocity rising while contributor count stays flat — typical of launch preparation. The infrastructure buildout shows new repository creation accelerating — a structural investment, often platform migration. The platform migration shows language mix shifting between primary languages — the slowest-moving but most strategically significant signal. Each pattern implies a different diligence question.

In theory yes; in practice it is expensive and easy to detect. A team can pad commit counts with mechanical edits, but contributor growth, repository creation, and language-mix changes are harder to fake. Most importantly, gaming the signal requires sustained effort from multiple contributors over weeks, which is itself a form of real engineering activity. Detection looks at commit size variance, file diversity, and contributor recency — checks any careful investor performs anyway.

Engineering acceleration is the longest-lead-time signal in the public alternative-data stack. Hiring data (LinkedIn, Wellfound) is upstream of engineering output but noisier — many job postings never close. Web traffic (SimilarWeb, Specter) and social signals (Twitter, Hacker News) are typically downstream of engineering activity. The strongest sourcing stacks layer all three: engineering acceleration for early discovery, hiring for validation, web/social for downstream cross-validation. Each catches a different point in the startup's development arc.

Commit velocity is the total number of commits to a startup's most active public GitHub repository over a rolling 14-day window. It measures the raw volume of engineering output.

Not necessarily. High absolute commit velocity can reflect automated commits, documentation updates, or CI/CD activity rather than meaningful product development. What matters more is commit velocity change – whether the rate is accelerating.

There is no universal benchmark – commit velocity depends on team size, commit granularity, and workflow conventions. A solo founder with 50 commits/week and a 10-person team with 200 commits/week may have equivalent per-engineer output. The useful metric is velocity change relative to the company's own baseline, not absolute counts.

Yes. Pre-seed startups often have public GitHub activity before they have any other public presence. Look for organizations with 1-3 contributors showing rapid commit acceleration from a low base – this pattern indicates early product development that often precedes a first fundraise.

Pre-seed activity typically shows 1-7 contributors, commit velocity under 100 per 14 days, but with high acceleration rates (+200% or more). New repository creation (infrastructure buildout) is common as founders move from prototype to more structured development.

Filter sector rankings for startups with 1-7 contributors showing +200% or higher velocity change. These disproportionate acceleration rates from a small base indicate a product breakthrough or first-fundraise preparation. Then verify on GitHub: is the activity product-related? Check Hacker News and Twitter for founder activity.

Series A startups typically show 20-49 contributors, infrastructure buildout (3+ new repos in 30 days), and increasing repository specialization. The dominant signal type is 'infrastructure buildout' – the team is building the platform around a working core product.

Infrastructure buildout means a startup created 3 or more new public repositories in 30 days. At Series A, these typically include API client libraries, SDK packages, CLI tools, and deployment infrastructure – signs that the team is building a platform around a working core product.

When contributor count jumps 50%+ in a short window (e.g., from 12 to 20 contributors), the company has likely closed a round and is scaling. This appears in GitHub data within weeks of new hires joining, but the Crunchbase entry may lag by 6-12 weeks.

Focus on the company-owned organization (not community forks), track core maintainer growth rather than total contributors, and look for commercial infrastructure signals – new repos for enterprise features, billing, or deployment tooling. Community star velocity is a social signal; commit velocity in the core product is the engineering signal.

Simultaneous community growth and commercial acceleration. When the open source project is gaining stars and contributors while the company organization is building enterprise infrastructure (billing, auth, deployment tooling), the open source flywheel is working – community traction is converting into commercial opportunity.

Stars measure social interest, not engineering traction or commercial viability. A repository with 10,000 stars may have zero revenue. Stars can indicate developer mindshare, but commit velocity in the company's own repositories is a more reliable signal of engineering momentum.

GitHub signals provide earlier lead time (6-12 weeks vs 4-8 weeks for hiring) because engineering acceleration precedes hiring decisions. Hiring data is more explicit about growth type. The combination of both is stronger than either alone – GitHub for timing, hiring for confirmation.

GitHub engineering signals typically provide 6-12 weeks of lead time before fundraise announcements, compared to 4-8 weeks for hiring data. The gap exists because engineering acceleration (more commits, faster shipping) precedes the hiring decisions that follow. By the time a job posting appears, the engineering acceleration has been visible for weeks.

Both – sequentially. Use GitHub signals for early detection (which companies are accelerating?) then hiring data for confirmation and growth-type classification (are they hiring engineers, sales, or marketing?). The combination provides both timing advantage and strategic context.

Fintech engineering signals are influenced by regulatory requirements. Infrastructure buildout often indicates compliance infrastructure (KYC, AML, audit logging) rather than product expansion. Deploy frequency spikes may reflect regulatory deadline-driven development rather than customer-driven iteration.

Simultaneous product acceleration and compliance buildout. When a fintech company is shipping product features and building compliance infrastructure (KYC, audit logging, encryption) at the same time, it is preparing for a regulated launch – which requires significant capital and often precedes fundraising.

Yes, but with sector-specific interpretation. Fintech companies with public repos typically focus on developer-facing products (payment APIs, banking-as-a-service, trading infrastructure). Consumer fintech companies are less likely to have public GitHub activity. Check the Fintech sector rankings for current data.

Distinguish model training infrastructure (sporadic large commits, research-oriented) from product engineering (frequent small commits, customer-driven iteration). The strongest signal is a transition from research-style to product-style commit patterns, indicating the company is moving from experimentation to shipping.

AI startups show the highest average commit velocity but also the highest noise of any sector. Open source experimentation, research-oriented commits, and community activity inflate the standard metrics. The key is separating product engineering (shipping features) from research exploration (running experiments).

The research-to-product transition. When an AI startup's commit pattern shifts from sporadic large commits (experiments, model checkpoints) to frequent small commits (API endpoints, deployment config, monitoring), the team is moving from 'does this work?' to 'let's ship this.' This transition often precedes a fundraise.

30 minutes per week. The workflow is designed to fit into a Monday morning routine: check rankings, screen candidates, verify signals, and add qualified leads to your pipeline.

2-5 actionable leads per week, depending on how many sectors you track and how selective you are. The quality is high because engineering acceleration is a leading indicator – you are finding companies before they appear in traditional deal sourcing channels.

Cybersecurity deploy frequency spikes often reflect CVE response rather than product iteration. Infrastructure buildout may indicate compliance infrastructure (SOC 2, ISO 27001). The strongest signal is sustained acceleration outside of incident-response cycles.

Check the timing: does the velocity spike coincide with a major CVE disclosure? If the spike happens within days of a published vulnerability, it is likely reactive patching. Sustained acceleration over 2-3 weeks without an external trigger indicates genuine product momentum.

New repositories related to SOC 2 audit trails, ISO 27001 documentation, or penetration testing frameworks indicate a company preparing for enterprise sales. Most enterprise buyers require SOC 2 compliance, so this buildout is a positive investment signal – it requires capital and precedes revenue growth.

Yes, but with nuance. Software-heavy climate companies (carbon accounting, energy trading) show standard engineering signals. Hardware-adjacent companies show lower commit velocity but meaningful infrastructure buildout when transitioning from R&D to deployment.

The R&D-to-deployment transition. When a climate tech company's GitHub activity shifts from experimental (research notebooks, prototype code) to operational (deployment scripts, monitoring, CI/CD pipelines), the technology is moving from lab to field. This transition requires capital and often precedes fundraising.

Software-heavy climate companies appear most clearly: carbon accounting platforms, energy trading tools, grid optimization software, and ESG reporting systems. Hardware-adjacent companies building intelligence layers (battery management, sensor networks, predictive maintenance) also show meaningful GitHub signals.

The five most common: confusing stars with traction, ignoring the private repo blind spot, overweighting absolute commit counts over acceleration, missing the context behind velocity spikes (bots, docs, migrations), and treating engineering signals as investment decisions rather than sourcing signals.

GitHub signals are reliable for deal sourcing – identifying interesting companies early. They are not reliable as standalone investment decisions. Engineering acceleration should be the first step in a diligence process, not the last. Always verify with direct founder conversations, product evaluation, and market analysis.

We compute a rolling 14-day window of commits per startup org, contributor count delta over 30 days, and new-repo creation rate. When all three accelerate inside the same two-week window, we classify the startup as 'accelerating'. Historical backtest shows ~70% of accelerating startups announce a fundraise within 6 weeks.

AI startups commit constantly regardless of fundraise timing – the signal-to-noise ratio is poor. The pattern is most diagnostic in devtools, infrastructure, fintech, and cybersecurity, where engineering velocity tracks more closely with company stage and runway pressure.

Yes. The free tool at /predict accepts any GitHub org name and returns the live signal classification (accelerating, steady, decelerating) plus the underlying commit and contributor numbers. No signup required.

The /predicted page is a public, dated, snapshot watchlist. Bookmark it. Come back in 6 months and check how many of the 10 startups raised, were acquired, or had a major launch. Each card links to the underlying GitHub org so you can audit the signal yourself.

There is no universal number, but the heuristic that works in practice is: one tool per distinct user intent, not one per REST endpoint. For @gitdealflow/mcp-signal, that came out to five tools mapping eight endpoints — three endpoints folded into multi-purpose tools, two were renamed for verb-noun clarity. Most teams ship with too many tools, not too few. Every tool in the menu costs the model reasoning bandwidth, costs the user latency, and increases the chance of a wrong-tool selection. Audit by logging what your users actually ask for in plain English, then reverse-engineering the smallest tool surface that covers those intents.

The model selects tools by matching the user's prompt embedding against each tool description's embedding. When two tools share half their vocabulary — list_startups and get_startup, for example — the confidence between them collapses to a coin flip. Verb-noun names parse better than camelCase boundaries, and when the noun is a word the user actually says (startups, signals, sectors), you get a much cleaner lock. Renaming list_signals to get_startup_signal alone fixed selection on prompts that did not even contain the word signal, because the model parsed startup from context.

Every tool you expose adds its full schema to the model's context every single turn — description, parameter list, parameter types, return shape. With terse docstrings, that runs ~600 input tokens per tool. Eight tools is ~5,000 tokens of menu before the user has said anything. The tax is paid in three currencies: input tokens (cost), reasoning bandwidth (accuracy), and time-to-first-token (latency). Cutting tools you do not actually need reclaims all three.

No. REST APIs are designed around resources; MCP tools should be designed around user intents. Most APIs have more endpoints than they have distinct intents. Mapping one-to-one ships the extra endpoints as MCP tools that mostly get confused for one another by the model. The cleaner mental model is: list the conversational intents your users have (what would they say in plain English), then design the smallest tool set that covers them. Implementation detail like single-resource gets and list-with-filter pairs almost always collapses into one tool with optional parameters.

A2A is an open protocol from Google for agent-to-agent communication. An agent publishes a JSON AgentCard at /.well-known/agent-card.json describing its capabilities and exposes a JSON-RPC 2.0 endpoint that other agents call to send messages and receive task results. By April 2026 it had passed 22,000 GitHub stars and was supported by 150+ organizations including Microsoft, Salesforce, and SAP. It is complementary to MCP — MCP exposes tools to a single AI assistant, A2A lets agents call other agents across the network.

Same five skills, different transport. The MCP server runs over stdio and is configured per-AI-assistant (Claude Desktop, Cursor, Windsurf). The A2A agent runs over HTTP/JSON-RPC and is configured per-agent-runtime (Google Agent Builder, LangChain, CrewAI, Mastra, Vercel AI SDK). MCP is for direct AI-to-tool calls. A2A is for agent-to-agent chains where another agent calls us as one node in a workflow. We ship both because the audiences are different.

No. The A2A endpoint at signals.gitdealflow.com/api/a2a is unauthenticated. There is no signup, no rate limit enforced at the application layer, and the upstream CDN absorbs typical agent traffic. The six free MCP tools and five free A2A skills are part of our distribution-magnet strategy and stay free forever. Paid features are scoped to /predict and the Insider Circle layer.

The stub I shipped is read-only and synchronous. It does sync message/send returning a terminal Task, all five skills via text intent or structured data parts, CORS preflight, and JSON-RPC error codes. It does NOT do streaming via message/stream, task persistence with tasks/get, push notifications, authenticated extended cards, or per-user prediction skills. The first four are stubbed because no paying customer has asked for them. The fifth — predictions as an A2A skill — is the cliffhanger. Today /predict is browser-only. When it is callable by your AI, this gets interesting.

Drop the AgentCard URL — https://signals.gitdealflow.com/.well-known/agent-card.json — into your runtime's agent registry. Most runtimes (Google Agent Builder, LangChain, CrewAI, Mastra, Vercel AI SDK, Inkeep) auto-parse the card and expose the five skills as callable tools. The interactive playground at /a2a-demo lets you watch a live JSON-RPC request and response without any runtime configuration.

You paste a GitHub username. We fetch the user's public starred repos via the GitHub API (no login, no OAuth — starring history is public metadata). Then we cross-reference each starred repo against a curated database of ~75 validated unicorns: companies that hit a $1B+ valuation, raised a Series A or later, were acquired, or crossed 25K+ stars in the last five years. For every match, we measure the gap between when you starred the repo and when the validation event happened. The earlier you starred, the more points. Top 5 wins are summed and normalized to a 0-100 Scout Score, with a rank from Curious to Oracle.

/predict asks you to call a startup before they raise. The resolution window is six months. That works for taste validation but it has a virality ceiling — Twitter does not share things that pay off in Q4. Receipts inverts the timing: you get instant proof of taste from a database we already maintain. Same Scout ladder, same ranks, same brand. Receipts is the top-of-funnel; /predict is the conversion. Both feed the existing five-email welcome sequence.

For each starred repo that matches a validated win, points = weight × min(months_early / 24, 1.0). Weight scales with the event: Series A = 50, Series B = 70, Series C+ or acquisition = 80-90, $1B+ valuation = 100. Twenty-four months early is a perfect multiplier — past that we cap because you cannot get more credit for being twenty years early. We dedupe to one win per company (you do not get points for starring three Vercel repos), then sum the top 5 and normalize so five perfect early calls equals 100. Scoring code is open-source at the route handler in the pseo-site repo.

No. The GitHub API endpoint we hit (`GET /users/:username/starred`) only returns public starring data. We never see private repos, DMs, your follower graph, your contributions, your forks, or anything that requires user-scoped OAuth. The token we use server-side is a fine-grained PAT with no scopes — it exists only to raise our shared rate limit from 60 requests per hour to 5,000. Receipts works on any public GitHub username without that user's involvement.

The list is biased toward developer-tools, AI infrastructure, and data/ops companies that have public GitHub presence and a clear validation event in the last five years (Vercel, Anthropic, LangChain, Hugging Face, Supabase, Linear, Cursor, Bun, Astro, OpenAI, Mistral, Modal, Pinecone, Stripe, Grafana, dbt, Airbyte, etc.). Closed-source unicorns without public repos cannot be in the database. The list will grow — every funded GitHub-native company is a candidate. If a company you think should be here is missing, the receipt fails to register a win and your score is lower than reality. That is a known false-negative.

The current Scout Score (0-100) and rank (curious / scout / sharp / elite / oracle) for the GitHub user named in the URL. Score is computed live from the user's public starring history vs. our database of validated unicorns — same algorithm as /receipts. The badge re-fetches when the CDN cache expires, so a user's score on the badge keeps pace with their score on the receipts page within an hour.

The current commit-velocity tier (cold / warming / hot / breakout) for any tracked GitHub org, plus the percent change. Tiers map to ranges of the 14-day velocity change versus the prior 14-day window: breakout is +200% or more, hot is +50% or more, warming is -30% or more, cold is below -30%. Untracked orgs render an 'untracked' pill so the badge degrades gracefully if a maintainer adds it before we are tracking that org.

READMEs are the most-trafficked surface in open source. A vanity-driven SVG badge in a profile or repo README compounds: each render is a brand impression for our domain via GitHub's camo CDN, each click is a visitor on a branded GDF page. Codecov, WakaTime, GitHub Stats all proved the pattern. The badge is autonomous — once a maintainer pastes it, it self-distributes for as long as the repo or profile is public. Zero ongoing maintenance.

No. GitHub renders all README images through its camo proxy, which caches the SVG aggressively (24h on our CDN, with ETag revalidation hourly). The badge endpoint always returns 200 even on transient errors — a bad render is a neutral gray pill, never a broken-image icon. Cache miss is 1-4 seconds (the GitHub starring API is the slow leg); subsequent hits are sub-30 ms.

Not yet. The Scout badge color reflects the user's current rank (curious=teal, scout=sky, sharp=purple, elite=amber, oracle=rose). The Momentum badge color reflects the tier. The label text is fixed. The point of locking these is that a casual reader scanning a README should be able to recognize a Scout badge from a Codecov badge from a WakaTime badge at a glance. We may add a color override later, but only after the visual identity is established.

All 30 findings live at signals.gitdealflow.com/research. Each one has a dedicated sub-page at signals.gitdealflow.com/research/{slug} with full ScholarlyArticle JSON-LD, citation chain (SSRN, OpenAlex, Crossref, Zenodo), and a copy-paste citation block.

Each sub-page carries a "How to cite" block. The canonical form is: The Data Nerd (2026). "{finding title}." Finding {n} of 30 in: A Longitudinal Panel of GitHub Engineering Velocity for Venture-Backed Startups. SSRN abstract=6606558. Retrieved from signals.gitdealflow.com/research/{slug}. The full cross-graph identity map is at signals.gitdealflow.com/citations.

Engineering acceleration is a quantitative GitHub momentum signal — code-side momentum measured from public commit-velocity data, contributor growth, and repository creation. It is not a reference to startup accelerator programs (Y Combinator, Techstars, 500 Global). Every finding page restates this disambiguation in its provenance block.

Not yet. The methodology is openly published on SSRN (abstract=6606558), CC BY 4.0, and is auto-indexed by Crossref, OpenAlex (W7154916891), Semantic Scholar, Unpaywall, and DataCite. The dataset has a permanent DOI on Zenodo (10.5281/zenodo.19650920). Replication studies are welcome — signal@gitdealflow.com for co-authorship on funding-event joins.