What is the critical path in a startup? It's the exact sequence of steps your pilot customer takes from receiving your invite to reaching their first moment of value. Not the entire product. Not every feature. The specific path they walk. Bugs on the critical path kill deals. Bugs off it are forgiven. Most early-stage teams don't know where their critical path is, which means they can't protect it. This post shows you how to map it, why it decides your first three deals, and how to build coverage that scales as your pilot count grows.
A pre-seed startup spends eight weeks building a product. It has a settings panel, four integrations, three main views, an admin dashboard, reporting features, and thirty-something individual functions that all more or less work. The engineering team has a rough sense of which parts are stable and which are duct-taped. The whole thing is technically a beta. Critical path testing, covering only the specific sequence your customer walks, is the answer to this situation. Most teams don't do it because they haven't named the problem yet.
Then the first customer pilot starts. The evaluator, a senior operator at a company trying to solve a real problem, logs in and does approximately four things: sets up their account, connects one integration, runs the core workflow twice, and checks the output. She doesn't touch the reporting features. She doesn't explore the settings panel. She definitely doesn't use the admin dashboard.
But: when the founder asks how the pilot is going two weeks in, the feedback is "it's been a bit buggy." The product has 30 stable features and four that the pilot customer actually touched. The bug was in one of the four.
Therefore: the testing strategy that protects this deal is not "cover the product." It's "know which four things she actually uses and make sure those don't break."
Why "Test Everything" Is the Wrong Goal for Pre-PMF Startups
The testing advice written for mature engineering teams, comprehensive coverage, unit tests on every module, integration tests across services, is technically correct and tactically wrong for a team of four that hasn't found product-market fit yet.
The problem is not that comprehensive testing is bad. It's that it's expensive. It takes engineering time to write, takes more time to maintain, and produces a suite that breaks every time you make a major product change, which happens constantly before PMF. The teams that pursue comprehensive coverage before they understand their product end up spending more time maintaining tests than shipping the features that would get them to PMF.
There is a more targeted approach. It starts with a question you probably haven't written down: what does your pilot customer actually do during their evaluation?
Not what could they do. Not what you hope they'll explore. What do they do. In what sequence. Through which parts of your product.
The answer to that question is your critical path. It is usually short. It usually involves a small fraction of your product's total surface area. And it is the only part of your product that actually decides the deal.
How to Map Your Critical Path
Mapping the critical path is a thirty-minute exercise. You need a whiteboard or a document, your most recent two pilot recordings if you have them, and someone who was on the onboarding call.
Walk through the pilot from the customer's perspective, step by step.
Entry point. How does the customer first access your product? An email invite? A link from your website? An SSO integration? This is step one of the critical path and a common source of deal-killing bugs. Write down every authentication state they might arrive in: fresh signup with email, returning user with Google OAuth, team member added via invite, admin resetting their own password.
Setup. After they're in, what configuration is required before the product does anything useful? Connecting an integration, adding a data source, configuring a project, inviting team members. Write each step. This is the part of the pilot that most often requires hand-holding from your team, which means it is also the part most likely to reveal gaps when they do it alone.
Core action. What is the one thing your product does that is the entire reason they agreed to a pilot? Write that down as a single sentence. "Run a scan and see results." "Generate a report from the connected data." "Test a deployment and see pass/fail." This is the center of the critical path. Everything else in the pilot is context.
Value confirmation. How does the customer know the core action worked? What does success look like to them? A number, a status indicator, a report, an alert? This output is the end of the critical path. If it is wrong or absent, the pilot fails regardless of how smoothly everything else went.
That's it. Entry, setup, core action, value confirmation. Draw it as a linear sequence. The result is your critical path.
Why Bugs On the Path Are Different From Bugs Off It
This is the insight that changes how you allocate testing effort: a bug on the critical path and a bug off it have almost no relationship to each other in terms of their deal impact.
A bug in your settings panel, maybe a toggle that doesn't save correctly, maybe a display issue in a section the customer rarely visits. It will probably never surface during the pilot. If it does, it registers as "rough around the edges," which is expected and forgivable in an early-stage product. The customer notes it, assumes you'll fix it, and does not revise their assessment of the core value proposition.
A bug in the core action flow, the thing they came to evaluate, has the opposite effect. It does not register as a rough edge. It registers as a product that does not work. And "does not work" is not a conversation you can recover from easily, especially when the customer has already spent time on the evaluation and is now explaining to their team why the thing they vouched for is not working.
The distinction matters because it means you do not need to protect your entire product to protect your deals. You need to protect a specific slice of it.
This is not permission to ship a broken product broadly. It is a framework for prioritizing your reliability investment when you have limited engineering time and multiple competing demands on it.
The 3 Types of Coverage That Actually Protect Deals
Once you have mapped the critical path, there are three types of automated coverage worth building before everything else.
Happy path coverage. A single test that walks the entire critical path from entry to value confirmation, using a clean test account, hitting real infrastructure, and asserting that the output is correct. This test should run on every pull request. If it fails, nothing goes to production until it passes. This is the highest ROI test a pre-PMF startup can write. One test, covering the path your pilot customer walks, catching the breaks that would cost you the deal.
Auth state coverage. Authentication bugs kill more pilots than any other category because they're often invisible during development and staging. Write tests for every entry state your pilot customers arrive in. New user via email signup. Returning user via Google OAuth. Team member added by admin via invite email. User on a mobile device who has never seen your app. Each of these is a path to your product. Each can fail independently.
Output assertion coverage. Whatever your product produces as its primary output, a report, a test run, a recommendation, an integration status. Write assertions about what correct output looks like. Not exhaustive schema validation. Basic sanity checks: the output is present, it contains what it should, it does not contain obvious error states. A 30-second assertion catches the class of bug where your output is silently wrong, which is the category of bug that breaks trust most severely.
// Example: Critical path coverage for a YC startup's B2B SaaS product
// Three test files, each covering one type
// 1. Happy path: full critical path in one test
test('critical path: invite → setup → core action → output', async ({ page }) => {
await page.goto('/accept-invite?token=TEST_INVITE_TOKEN')
await page.fill('[data-testid="name"]', 'Test User')
await page.fill('[data-testid="password"]', 'Secure123!')
await page.click('[data-testid="complete-signup"]')
// Setup: connect integration
await page.click('[data-testid="connect-integration"]')
await page.waitForSelector('[data-testid="integration-connected"]')
// Core action
await page.click('[data-testid="run-primary-workflow"]')
await page.waitForSelector('[data-testid="workflow-results"]', { timeout: 30000 })
// Output assertion
const output = await page.locator('[data-testid="workflow-results"]').textContent()
expect(output).not.toContain('Error')
expect(output).not.toContain('undefined')
expect(output).toMatch(/\d+/) // Output contains a meaningful number
})
// 2. Auth state: returning user via OAuth
test('auth: Google OAuth returning user', async ({ page }) => {
await page.goto('/login')
await page.click('[data-testid="google-oauth-btn"]')
await page.waitForURL('/dashboard')
await expect(page.locator('[data-testid="user-greeting"]')).toBeVisible()
})
// 3. Output assertion: correct report format
test('output: report contains required fields', async ({ request }) => {
const response = await request.post('/api/generate-report', {
data: { projectId: TEST_PROJECT_ID }
})
const report = await response.json()
expect(report.status).toBe('complete')
expect(report.summary).toBeTruthy()
expect(report.items).toBeInstanceOf(Array)
expect(report.items.length).toBeGreaterThan(0)
})These three test files, running on every pull request, cover the specific failures that end deals. Not every possible failure. The ones that matter when a pilot customer is in the product alone.
If writing and maintaining Playwright tests is a cost you'd rather avoid while shipping features, Autonoma generates this coverage from your codebase automatically. Point it at your critical path, it generates the tests, and they stay current as your product evolves without requiring manual updates.
What Your Pilot Customer Forgives Versus What They Don't
Understanding deal-critical coverage requires understanding the customer's mental model during a pilot. They are not evaluating your product the way a QA engineer would. They are evaluating it the way someone who needs to solve a problem would.
This means they are applying a roughly binary judgment: does this do the thing it's supposed to do, yes or no? Everything else, how fast it does it, how clean the UI looks doing it, how many secondary features exist around it, all relevant but secondary. The binary question comes first.
The practical implication: a pilot customer will almost always forgive bugs that don't touch the binary question. A broken export-to-PDF feature is forgiven if the core workflow is solid. A slow-loading admin panel is forgiven. A missing integration they weren't planning to use is forgiven. These are features on the roadmap. They don't change the answer to the binary question.
Bugs that touch the binary question are not forgiven in the same way. A core action that returns an error half the time cannot be rationalized. An output that is sometimes wrong cannot be trusted. Authentication that works on desktop but breaks on mobile means the product doesn't work for half the use cases they might have. These change the binary answer from yes to not sure, and not sure is often enough to kill a deal.
| Bug category | On critical path? | Typical pilot impact | Recovery difficulty |
|---|---|---|---|
| Auth / access failure | Yes | Pilot stalls or never starts | High, first impression set |
| Core action error | Yes | Value proposition questioned | High, trust requires rebuilding |
| Incorrect output | Yes | Trust in all output destroyed | Very high, doubt compounds |
| Slow secondary feature | No | Noted as rough edge | Low, "it's early" applies |
| Missing admin functionality | No | Usually not encountered | Minimal, roadmap conversation |
| UI polish issues | No | Noted, not weighted heavily | Minimal, expected in early product |
How the Critical Path Changes as Your Product Evolves
The critical path is not fixed. As your product matures and your customer base diversifies, different customers will walk different paths. A power user who has been on the product for three months has a different critical path than a pilot customer in their first week.
This is important to track explicitly because coverage that protects a pilot may not protect a renewal. A renewal customer cares about the features they've been using daily. A pilot customer cares about the core promise. If you only maintain critical path coverage for the pilot journey, you will catch pilot-breaking bugs but miss the bugs that drive churn at the 90-day mark.
The practical approach: maintain explicit documentation of your critical path, review it quarterly, and extend test coverage as the path evolves. Add a test for every new integration a customer onboarded with. Add output assertions for every report type you've shipped to customers. Let the suite grow with your customer journey, not with your feature list.
The teams that do this consistently end up with coverage that maps to how customers actually use the product. It is not comprehensive. It is not trying to be. It is a living representation of the path from zero to value, maintained as that path deepens and branches over time.
Turning the Critical Path Map Into Team Practice
The critical path mapping exercise described earlier is useful once. It is most useful as a recurring practice. Before each sprint, ask: are we shipping anything that touches the critical path? If yes, does our existing test coverage catch a regression there?
This question, asked consistently, changes the relationship between shipping and testing from adversarial to complementary. You are not testing in addition to shipping. You are protecting the path while you ship.
The friction version of this practice looks like manual QA before every release: someone clicking through the critical path, checking that it still works, filing a ticket if it doesn't. This works at one pilot. It does not scale past three. It depends on someone remembering to do it, having time to do it, and knowing the current state of the critical path well enough to test it correctly.
The automated version is a CI check. Pull request opens, critical path tests run, green means the path is protected. No memory required. No manual effort per deploy. No knowledge transfer required when the person who normally does manual QA is on vacation during a critical deployment window.
That version scales to ten pilots. It scales to your first 50 customers. It scales to a team of 20 engineers shipping independently without coordination overhead. The investment to get there from the single-test happy path is not large. The payoff, measured in deals closed versus deals lost to avoidable bugs, is very large.
Frequently Asked Questions
The critical path is the specific sequence of steps your pilot customer takes from first accessing your product to reaching their first moment of value. It typically includes: gaining access (login, SSO, or invite acceptance), completing required setup (connecting an integration, configuring a project), executing the core action your product is built for, and seeing the output that confirms success. The critical path is usually much shorter than the full product surface area. For most B2B SaaS products in the pilot stage, it involves three to five screens and one primary workflow. This is the slice of your product that decides deals.
Map your critical path first: trace the exact steps your pilot customer takes from invite to first value. This is a 30-minute exercise that requires walking through the pilot journey step by step. The resulting path (entry, setup, core action, value confirmation), is where you concentrate your testing investment. Everything else can be tested manually or deferred. Start with one end-to-end test that covers the full critical path, add auth state coverage for every way a customer might log in, and add output assertions for whatever your product generates. These three coverage areas protect the moments that decide whether pilots convert.
Pilot customers are applying a roughly binary judgment: does this product do the thing it's supposed to do? A bug that touches the binary question, a broken core action, a wrong output, a failed login, changes the answer from yes to not sure. Not sure is often enough to kill a deal. Bugs off the critical path are evaluated differently: they register as rough edges in an early product, which is expected and forgivable. The asymmetry is stark. A broken export feature is a roadmap item. A broken core action is a failed evaluation.
Three tests are sufficient to protect your first deals. One end-to-end test covering the full critical path from entry to value confirmation. One or more auth state tests covering every way a pilot customer might log in (email signup, Google OAuth, invite link, SSO). At least one output assertion test verifying that what your product generates is present, correct, and free of obvious error states. These three test types cover the failure modes that kill pilots. You can write them in an afternoon, run them in CI on every pull request, and ship with confidence that the deal-critical path is protected.
Full coverage testing aims to verify every function, feature, and edge case in your product, appropriate for mature products with dedicated QA and predictable feature surfaces. Critical path testing verifies only the specific sequence of actions your customers take to reach value. For pre-PMF startups, full coverage is expensive to write and expensive to maintain as the product evolves rapidly. Critical path testing is cheap, targeted, and directly correlated with deal outcomes. It does not replace full coverage as an eventual goal; it is the minimum viable testing investment that protects revenue before you have the resources to build comprehensive coverage.
The critical path evolves with your product and customer base. A pilot customer's path (entry, setup, core action, first output) is different from a renewal customer's path (daily workflow, advanced features, reporting). Track your critical path explicitly and review it quarterly. Add test coverage for new integrations as you ship them. Add output assertions for new report types as customers adopt them. Let coverage grow with how customers actually use your product, not with your feature list. Teams that maintain explicit critical path documentation consistently end up with test suites that match real customer behavior.