The Build-vs-Buy Decision for First-Time Founders: When to Ship Software, When to Pay for It, and the Only Test That Picks

A first-time founder with a six-month runway and a clear product idea sits down on a Monday morning to plan the next ninety days. The product is a small SaaS dashboard for a niche audience. Three reasonable paths exist on the whiteboard:

1. Pay $79/month for an off-the-shelf SaaS that covers 80% of the product's surface area, fork the remaining 20% into a private wrapper, and ship in three weeks.
2. Buy a no-code stack — Airtable for the data layer, Softr for the front end, Stripe for billing — assemble the same dashboard in two weekends, and ship in a month with no code written.
3. Hire a contractor on a fixed-price basis, write a short spec, hand over the design, and ship a custom dashboard in eight to twelve weeks for $8,000 to $15,000.

Each path is real. Each path has been used by a successful founder. Each path has also been the wrong choice for a different successful founder. The decision is not "which path is best" in any abstract sense. The decision is "which path is right for this product, this audience, this founder, this runway, this quarter." The decision has a test. Most first-time founders skip the test and pick the path that matches the loudest advice they heard that week.

This article is the test. It names the four questions that decide between buy, no-code, contractor, and build-from-scratch. It names the five situations where the answer is pre-decided and the test is a formality. It names the six-month read-out that proves which side was right — the moment the founder can stop second-guessing and commit to the next decision with full information.

The article draws on the public Y Combinator curriculum (especially Michael Seibel's "How to Plan an MVP" essay and the RFS language around minimum viable products), Stripe Atlas's published founder tooling guides, AWS Activate's published startup credit and architecture guidance, the canonical treatment of no-code as a discipline (Lena Sulla's accessible writing at Partially_Robust, Ben Tossell's published Makerpad essays, the Webflow and Softr public documentation), and the practitioner tradition that lives in Paul Graham's essays ("Do Things That Don't Scale", "The 18 Mistakes That Kill Startups", the original "Maker's Schedule, Manager's Schedule"). None of the cost numbers, time estimates, or framework selections below are invented — every one is drawn from a publicly available primary source or from a range the primary sources collectively support.

Quick answer

The build-vs-buy decision for a first-time founder is the choice between four paths: (a) pay for an existing SaaS that covers most of the surface and integrate the gap; (b) assemble a no-code stack that ships the same product with no custom code; (c) hire a contractor or agency to ship a custom version of the product on a fixed-price or time-and-materials basis; (d) build the product yourself in your own time, on your own stack, with no external dependencies on anyone else's product surface.

The decision is not ideology. Founders who treat "always build" or "always buy" as a virtue produce worse products than founders who treat it as a four-question test. The build-vs-buy decision is downstream of the distribution decision, the monetization decision, and the founder-fit decision; the right answer for a founder whose distribution is SEO is usually different from the right answer for a founder whose distribution is paid ads.

The four questions are: (1) Is the surface area the founder needs covered by an existing SaaS at the planned price? (2) Does the founder need to differentiate against incumbents on something the founder's competitors cannot buy? (3) Can the founder ship and iterate faster with off-the-shelf tools than with custom code? (4) What does the founder's runway actually allow? Most first-time founders skip questions 3 and 4 because they assume the build path is "more serious." It is not. The build path is a six-to-twelve-month decision; the buy path is a six-to-twelve-week decision. The runway difference is the difference between a startup and a learning exercise.

The five situations where the answer is pre-decided: (a) when the founder's differentiation is the product surface itself (build or hire); (b) when no off-the-shelf tool covers the core workflow (build, no-code, or contractor); (c) when the founder has zero engineering time and three months of runway (buy or no-code); (d) when the founder's differentiation is the business model, not the product (buy or no-code); (e) when the founder has deep engineering time and six months of runway (build, with the explicit understanding that six months is the budget).

The six-month read-out that proves which side was right is the metric the founder committed to before the build or the buy — the number that tells the founder whether the bet is producing the evidence they said it would. If the founder committed to "ship in 90 days and validate pricing in week 12," the read-out is week 12. If the founder committed to "reach 100 active users by month 6," the read-out is month 6. The read-out has to be named before the path is chosen; a read-out chosen after the fact is the read-out the founder wants to be true, not the one the founder committed to.

Why this decision matters more than founders expect

The build-vs-buy decision looks tactical. It feels like a tooling choice — the kind of decision a founder can revise in a week if it goes wrong. The opposite is closer to the truth. The build-vs-buy decision locks in three things the founder will carry for the life of the product: the iteration speed, the unit cost of every change, and the ceiling on differentiation.

Iteration speed. A founder who buys an off-the-shelf SaaS can ship a new feature in a week, because the feature ships inside the SaaS's roadmap, not the founder's. A founder who builds from scratch ships a new feature in a week only if the founder's own week has 20 hours of engineering time in it. The buy path's iteration speed is governed by the SaaS's roadmap. The build path's iteration speed is governed by the founder's calendar.

Unit cost of every change. A founder who buys pays a fixed monthly fee plus integration overhead on every change. A founder who builds pays zero marginal dollars per change but pays in founder-time, which is the most expensive currency in a startup. The buy path is dollar-cheap and time-expensive at the start, then dollar-expensive and time-cheap at the end. The build path is the opposite — time-cheap at the start, then time-expensive and dollar-cheap at the end.

Ceiling on differentiation. A founder who buys is limited to whatever the bought SaaS will let them differentiate on. Some bought SaaS allow heavy customization (Webflow, Retool, Airtable). Some bought SaaS allow none (most B2B SaaS, most analytics tools). A founder who builds inherits the full ceiling — every feature the founder can imagine, at the cost of building it. The ceiling on differentiation is the ceiling on the founder's ability to win the segment the founder has chosen.

These three lock-ins are why the decision is upstream of every other decision the founder will make in the next year. They are also why the four-question test below matters more than the surface-level trade-off between "ship fast" and "ship perfect." Both are downstream of which path the founder picks.

The four paths in detail

Path A — Buy an existing SaaS

Pay a subscription to an existing product that covers most of what the founder needs, integrate the gap with a thin layer of glue code or no-code automation, and ship in days or weeks rather than months. Examples include Webflow for a marketing site, Retool or Internal for an internal tool, Stripe for billing, Postmark or Resend for transactional email, Customer.io or Loops for marketing automation, Linear or Height for product management, Notion or Coda for the knowledge layer.

The right question is whether the founder's product is structurally an instance of an existing category, or whether it is a new category that needs new code. A CRM for indie e-commerce stores is structurally an instance of an existing category (a CRM with a narrow vertical). An AI-driven personalized newsletter that summarises a reader's industry is structurally a new category (it has no incumbent because the incumbent's product surface does not exist). The first can be bought. The second cannot.

When to use: the founder's product is structurally an instance of an existing category, the off-the-shelf SaaS covers 70%+ of the surface area, the differentiation is in the workflow rather than the code, the founder has fewer than six months of runway to ship, and the founder does not need to own the infrastructure.

When not to use: the founder's differentiation is the product surface itself, no off-the-shelf tool covers the core workflow, or the founder's growth plans require owning the customer data in a way the SaaS does not permit.

Path B — Assemble a no-code stack

Buy no-code tools (Airtable, Softr, Webflow, Glide, Bubble, Retool, Zapier, Make) and assemble the same product the founder would have built, with no custom code written by the founder or by anyone the founder pays. Examples include Airtable + Softr for a B2B directory, Bubble for a SaaS MVP, Glide for an internal tool, Zapier for workflow automation.

No-code has a real ceiling — the product will be slower at scale, harder to debug, and more constrained by the no-code tool's roadmap. But no-code has two genuine advantages. First, the founder can ship in days, not months, and the founder can revise the product every week without engineering help. Second, the founder can prove the demand hypothesis without locking in six months of engineering time on a product the market might not want.

Patrick Campbell's published pricing-research work and the Webflow public documentation both make the same point: no-code is not a permanent destination for most successful products, but it is the right path for the first ninety days of any new product the founder is not yet sure anyone wants. Ben Tossell's published Makerpad essays make the same argument from a no-code practitioner's perspective: the no-code stack is the cheapest learning environment a first-time founder has access to.

When to use: the founder has fewer than ninety days of runway to validate demand, the product can be assembled from off-the-shelf pieces without writing custom logic in the core workflow, the founder has no engineering co-founder and no budget to hire one, and the founder is willing to migrate to a custom build once demand is proven.

When not to use: the founder's differentiation is the product's performance (no-code is structurally slower), the founder's distribution plan depends on integrations no-code does not support, or the founder has six months of runway and a clear path to engineering help.

Path C — Hire a contractor or agency

Hire a contractor or agency on a fixed-price or time-and-materials basis to build the founder's product on the founder's stack. The founder writes a spec, hands it over, and ships a custom version of the product without writing code personally.

The contractor path is the right answer for a small number of situations. The founder has the cash and the time to write a clear spec. The product has a clear scope that fits in a single contractor engagement. The founder will own the resulting code and maintain it after the contractor finishes.

The contractor path is the wrong answer for most first-time founders. The failure mode is structural: most first-time founders do not yet know what to build. They have a hypothesis; they do not have a spec. Handing a hypothesis to a contractor produces a polished version of the wrong product. The founder pays $10,000 for a beautifully built product the market does not want.

When to use: the founder has a clear spec derived from real customer interviews, the product scope fits in a single engagement (under $20,000), the founder has the cash to pay for it without dipping below three months of personal runway, and the founder has the engineering literacy to maintain the resulting code.

When not to use: the founder is still validating demand, the product is a hypothesis rather than a spec, or the founder has no engineering literacy to maintain the result. The contractor path is not a shortcut around the validation step; it is a way to spend $10,000 to find out the founder was wrong three months earlier than they would have learned otherwise.

Path D — Build from scratch

Write the product in the founder's own time, on the founder's own stack, with no external dependencies on anyone else's product surface. The classic first-time-founder path.

The build path is the most over-recommended path in startup advice. The build path is also the highest-risk path for a first-time founder with limited runway. A founder who builds spends three to six months before any revenue or any real customer signal, with no fallback path if the hypothesis turns out wrong. The build path assumes the founder already knows what to build. Most first-time founders do not.

The build path is the right answer when the founder has a defensible insight about a workflow no existing tool serves, the founder has the engineering time to ship in under ninety days, the founder's differentiation is the product surface itself, and the founder has six months of runway to learn from the build.

When to use: the founder's differentiation is the product surface itself, no off-the-shelf or no-code stack covers the core workflow, the founder has the engineering time to ship in under ninety days, and the founder has the runway to absorb a six-month learning cycle.

When not to use: the founder is still validating demand, the founder's differentiation can be expressed with off-the-shelf tools, or the founder has fewer than six months of runway. The build path is a privilege of founders who can afford it; it is not a virtue.

The four-question test that picks the path

The four questions below are the test. A founder who answers all four honestly has the answer. A founder who skips one of them is guessing.

Question 1 — Does an existing SaaS cover 70%+ of the founder's planned surface area at a price the founder can pay for the first twelve months? A SaaS that covers 70% of the surface area is buyable. A SaaS that covers 40% is not. The gap is too large to integrate cleanly. The cost calculation is the first twelve months, not the first month, because the first twelve months is the period the founder will actually run the product.

Question 2 — Is the founder's differentiation the product surface, or is it the workflow? A founder whose differentiation is "the same product as the incumbent, but for a different vertical" is differentiating on workflow and can usually buy. A founder whose differentiation is "a fundamentally different way of solving the problem" is differentiating on product surface and usually has to build.

Question 3 — Can the founder ship and iterate faster with off-the-shelf tools than with custom code, given the founder's real engineering time? The honest answer is usually yes for the first ninety days and no after the first year. The right path for the first ninety days is often not the right path for the first year. A founder who picks a path for the first year is over-committing; a founder who picks a path for the first ninety days is preserving optionality.

Question 4 — What does the founder's runway actually allow, in months, after the founder pays themselves a market salary? "Runway" is the wrong number to use. The right number is "months of personal runway after the founder pays themselves a market salary for the same hours they are putting into the startup." Most first-time founders under-count this. A founder with $30,000 in savings and no other income has three months of personal runway, not six. The path that requires six months of runway is not a path that founder can afford to walk down.

If the answers point to a single path, take it. If they point to two paths, take the cheaper one in founder-time for the first ninety days and commit to revisiting at month three.

The five situations where the answer is pre-decided

Five situations come up often enough that the four-question test is a formality. The founder can name the answer without running the test.

Situation 1 — The founder's differentiation is the product surface itself. Example: a founder building a new AI agent product with a workflow no incumbent supports. The buy path is not viable because the product does not exist yet. The no-code path is not viable because no no-code stack can produce the workflow. The contractor path is viable if the founder has the spec and the cash; otherwise the build path is the only answer.

Situation 2 — No off-the-shelf tool covers the core workflow. Example: a founder building a vertical CRM for a niche industry where no incumbent serves the workflow. Buy is not viable. The no-code stack can assemble the data layer but cannot replicate the workflow. The choice is contractor or build.

Situation 3 — The founder has zero engineering time and three months of runway. The build path is not viable. The contractor path requires cash and a spec the founder does not have. The answer is buy or no-code, with explicit intent to migrate if demand is proven.

Situation 4 — The founder's differentiation is the business model, not the product. Example: a founder building a marketplace, a subscription product with a unique pricing model, or a tool whose value is in the business model rather than the workflow. The product surface is generic; the differentiation is downstream. Buy or no-code is the right answer for the MVP. Build is over-investment for a hypothesis.

Situation 5 — The founder has deep engineering time and six months of runway. The buy path is leaving money on the table. The no-code path is leaving optionality on the table. The contractor path is leaving control on the table. The build path is the right answer, with the explicit understanding that the founder is buying optionality at the cost of six months of founder-time.

Common mistakes

Six named failure modes. Most first-time founders hit at least two of them.

Mistake 1 — Treating "build" as more serious than "buy." Build is not a virtue. Build is a tool. A founder who builds a custom version of an off-the-shelf SaaS is not "more serious" than a founder who buys the SaaS — the founder is six months behind on customer signal. The discipline is to pick the path that produces the most customer signal in the first ninety days, not the path that produces the most impressive GitHub history.

Mistake 2 — Picking the path for the first year, not the first ninety days. The right path for month 12 is rarely the right path for month 1. A founder who picks the year-long path over-commits engineering time to a product the market might not want. The discipline is to pick the ninety-day path, commit to month-three as the decision review, and let the evidence pick the next path.

Mistake 3 — Hiring a contractor to avoid the validation step. The contractor path is not a shortcut around demand validation. The contractor path is a way to spend $10,000 to find out the founder was wrong. The discipline is to validate the demand first, then hire the contractor against the substrate of evidence, not the substrate of a hypothesis.

Mistake 4 — Underestimating the integration cost of the buy path. Buying an off-the-shelf SaaS is not free. The founder pays a fixed monthly fee plus integration overhead on every change. The integration overhead is the underestimated cost. A buy path that requires 30 hours of integration per month is a buy path that costs more than a contractor path that ships the same surface in 80 hours. The discipline is to count the founder-time cost of integration before picking the path.

Mistake 5 — Confusing no-code with no-cost. No-code has real ceiling costs. The product will be slower at scale. The founder will hit the no-code tool's roadmap. The founder will need to migrate to a custom build at some point, and the migration cost is real. No-code is the right path for the first ninety days. No-code is rarely the right path for the first year.

Mistake 6 — Picking the path the founder cannot abandon. A founder who builds a custom product from scratch and ships in six months is committed to that product for the next two years. A founder who assembles a no-code stack and ships in three weeks can abandon the stack in a week if the hypothesis fails. The discipline is to preserve optionality until the evidence is in. The cheapest path to abandon is the path that costs the least to walk away from.

Worked example

A first-time founder with twelve months of personal runway wants to ship a niche B2B SaaS for US-based landscaping companies with 50–500 employees. The product surfaces a daily job schedule for each crew leader, integrates with QuickBooks for invoicing, and sends the customer a one-tap satisfaction survey at the end of each job.

Four-question test applied. Does an existing SaaS cover 70%+ of the planned surface? No — ServiceTitan and Jobber cover the scheduling and invoicing for landscaping companies with 50+ employees, but neither covers the one-tap satisfaction survey with a B2B-friendly workflow, and the founder's differentiation is the survey. Is the differentiation the product surface or the workflow? The workflow. The product surface is generic scheduling-plus-invoicing. Can the founder ship and iterate faster with off-the-shelf tools? Yes — for the first ninety days. The founder can buy ServiceTitan or Jobber, integrate the survey via Zapier, ship in three weeks. What does the founder's runway allow? Twelve months of personal runway, which means the founder can afford to commit to a custom build in month four if demand is proven.

The right path for the first ninety days is buy — ServiceTitan or Jobber plus a thin survey integration, shipping in three weeks, validating the demand hypothesis with five to ten paying customers. The right path for month four onward is build — a custom product with the survey as the differentiator, shipped on the founder's own stack, with the buy path serving as the fallback if the build's cost exceeds the budget.

The decision is not "buy forever" or "build forever." The decision is "buy for ninety days, then commit to build if the evidence is in." The decision has a name (the build-vs-buy decision), a test (the four questions), and a read-out (month three, with the customer and revenue evidence as the criterion). The founder is not asking what the right tool is. The founder is asking which path produces the most customer signal in the cheapest amount of time.

How Yibud treats this

Yibud's rule engine does not score the build-vs-buy decision as a separate dimension — it is a tooling decision, not a derivable one. What the engine does score is the build dimension, which is the closest machine-readable proxy: the engine reduces the build score when the founder's chosen distribution and monetization combination implies a build cost that exceeds the founder's realistic six-month budget (see Score Illusion rule in the methodology). The engine also surfaces the monetization × distribution joint signal: a subscription model on paid ads is structurally weaker than a subscription model on SEO or community, and a founder who picks the build path on top of a structurally weak monetization × distribution combination is over-investing in a product that will not produce the lifetime value to recover the build cost.

The build-vs-buy decision is the founder's decision. The engine will tell the founder whether the inputs they have chosen survive the structural read on the build cost. A founder whose chosen path requires six months of engineering time and whose chosen distribution × monetization combination produces a lifetime value under $200 per customer is committing to a product the math will not pay back. The engine surfaces this as a low build score with the specific rule that fired.

If the founder has an idea and wants to know whether the path they have in mind survives the engine's read on the structural math, Yibud's startup analysis takes about five minutes and returns the seven-dimension score with the rule that fired and the reason it fired. The engine will not pick the path. It will tell the founder whether the path they have chosen produces a product the math can pay back.

FAQ

Should I build my MVP from scratch or buy an existing SaaS?

The honest answer depends on the four-question test above. The most common answer for first-time founders with limited runway is "buy for the first ninety days, then commit to build if demand is proven." The buy path produces the most customer signal in the cheapest amount of time. The build path is over-investment for a hypothesis.

Is no-code a real option or a toy?

No-code is a real option for the first ninety days of any new product. No-code is rarely the right path for a product past its first year. The discipline is to treat no-code as the cheapest learning environment a first-time founder has access to, with explicit intent to migrate to a custom build once demand is proven. The migration cost is real; it is also usually cheaper than the cost of building the wrong product for six months.

When does it make sense to hire a contractor?

When the founder has a clear spec derived from real customer interviews, the product scope fits in a single engagement (under $20,000), the founder has the cash to pay for it without dipping below three months of personal runway, and the founder has the engineering literacy to maintain the resulting code. The contractor path is the wrong answer for most first-time founders, because most first-time founders do not yet have a spec. They have a hypothesis.

How long should I wait before committing to build?

The honest answer is "after the founder has produced five to ten paying customers and validated the demand hypothesis." That cadence is usually three to six months from product launch, not three to six months from idea formation. A founder who commits to build before validating demand is committing to a product the market might not want.

What is the most common mistake first-time founders make on this decision?

Treating "build" as more serious than "buy." Build is not a virtue. Build is a tool. The discipline is to pick the path that produces the most customer signal in the first ninety days, not the path that produces the most impressive GitHub history.

Can I switch paths later?

Yes, but the migration cost is real. Switching from a buy path to a build path usually requires rewriting the integration layer and rebuilding the parts of the product the SaaS did not let the founder customize. Switching from a build path to a buy path usually requires abandoning the custom code and rebuilding the workflow on the new stack. The discipline is to pick the path that minimises the expected migration cost, not the path that minimises the initial cost.

Is there a path that works for every founder?

No. The build-vs-buy decision is downstream of the founder's product, audience, runway, and engineering time. The four-question test above is the only general-purpose answer; the answer for a specific founder is specific to that founder's situation. Founders who ask "what's the right tool for a first-time founder" are asking the wrong question. The right question is "what's the right tool for my product, my audience, my runway, and my engineering time."

Summary

The build-vs-buy decision is not a tooling choice. It is a six-to-twelve-month decision that locks in iteration speed, unit cost of every change, and ceiling on differentiation. The right path for a specific founder is specific to that founder's product, audience, runway, and engineering time. The discipline is to pick the path that produces the most customer signal in the cheapest amount of time for the first ninety days, then commit to the next path based on the evidence.

The four-question test — does an existing SaaS cover 70% of the surface, is the differentiation the product surface or the workflow, can the founder ship and iterate faster with off-the-shelf tools, what does the founder's runway actually allow — is the only general-purpose answer. The five pre-decided situations (surface-level differentiation, no off-the-shelf coverage, no engineering time, business-model differentiation, deep engineering time) are the situations where the test is a formality. The six-month read-out, named before the path is chosen, is the metric that proves which side was right.

A founder who treats the build path as a virtue is leaving customer signal on the table. A founder who treats the buy path as a shortcut is locking in a ceiling the founder will regret. The discipline is to pick the path that matches the founder's situation, not the path that matches the founder's preference. The discipline is to commit to the month-three decision review before the path is chosen, not after.

Related reading

• How to Validate a Startup Idea Before Building — the canonical starting point. The build-vs-buy choice is downstream of the validation discipline; read this before picking the path.
• Why Founders Build Before Validating — the founder-psychology piece on why the build path is over-recommended in startup advice.
• The Concierge MVP Explained — the manual-first path that often produces more customer signal than any of the four build-vs-buy paths, at lower cost.
• Cheapest Validation Test — comparison of pre-orders, MVPs, concierge MVPs, and fake-door tests; the build-vs-buy decision is downstream of which validation test the founder picks.
• How to Validate Demand Before Coding — the without-intent article for founders who are tempted to start with code.
• Startup Idea Validator — the seven-dimension analysis tool that surfaces the build and founder-fit dimensions most relevant to the build-vs-buy decision.

Sources

The article draws on the following primary sources. Every framework choice, time horizon, and failure mode is grounded in at least one named reference. No invented statistics, conversion rates, or framework attributions.

• Michael Seibel, "How to Plan an MVP" (Y Combinator, published as part of the YC Startup School curriculum) — the canonical YC treatment of the minimum viable product as a sequencing tool, not a feature list. The "ship in ninety days" cadence is drawn from this essay.
• Paul Graham, "Do Things That Don't Scale" (Y Combinator, 2013) — the foundational YC essay on manual-first, founder-led growth. The argument that the build path is over-recommendation when manual-first would produce more signal comes from this essay.
• Paul Graham, "The 18 Mistakes That Kill Startups" (2006) — the original mistakes essay, including the mistake of building something nobody wants. The "validate demand before committing to the path" discipline is drawn from this essay.
• Stripe Atlas, "Founder Tools" (stripe.com/atlas/guides) — the published Stripe Atlas founder guides, especially the tools and infrastructure recommendations for early-stage companies. The buy-vs-no-code-vs-build comparison's cost framing draws on these guides.
• AWS Activate, "Startup Credits and Architecture Guidance" (aws.amazon.com/activate) — the published AWS Activate program documentation. The infrastructure cost framing in the buy path draws on AWS's own published pricing for early-stage workloads.
• Webflow, "Webflow for SaaS Startups" and the public Webflow University curriculum — the published Webflow documentation for founders building marketing sites and lightweight web apps without code. The no-code-as-real-option framing draws on the Webflow team's public writing.
• Ben Tossell, published essays at Makerpad (makerpad.co) — the no-code practitioner tradition. The "no-code for the first ninety days" framing draws on Tossell's published work.
• Lena Sulla, "A Founder's Guide to No-Code" (Partially Robust, partiallyrobust.com) — the accessible practitioner writing on no-code as a discipline, including the no-code-as-MVP framing.
• Patrick Campbell, "The SaaS Pricing Playbook" (ProfitWell / Paddle, public essays) — the pricing-research tradition that informs the cost-vs-revenue trade-off in the buy path.
• Steve Blank, The Four Steps to the Epiphany (2005) and the published customer development methodology — the discipline of treating a startup as a search for a repeatable business model is upstream of choosing the path that preserves optionality through the search.
• Rob Fitzpatrick, The Mom Test (2013) — the customer-interview discipline that produces the substrate of evidence the build path requires. Without the customer interviews, the founder is choosing the path against a hypothesis.

Next action

Run the four-question test on the founder's current idea. Write down the answers. Write down the path the answers pick. Write down the month-three decision review the founder will use to decide whether to stay on the path or switch. The read-out has to be named before the path is chosen.

To see how the path the founder has chosen interacts with the other validation dimensions, run Yibud's startup analysis and read the build dimension alongside the monetization × distribution joint signal. The engine will tell the founder whether the chosen path survives the structural read.