How to Scope a SaaS MVP in 10 Business Days (Published Playbook)

For the operator who has been carrying a SaaS idea in their head for eight months — and needs a forcing function to turn it into a spec a developer can build.

The Situation

You run a business. You noticed a gap. Your industry has a recurring, painful, expensive problem that nobody is solving well. You could build the thing that solves it. You have even told three or four trusted friends about the idea and they all nodded and said "yeah, that should exist."

Since then, you have done the following: opened a Google Doc and written seven rambling paragraphs of ideas. Started a Notion page and created a "v1 features" list that grew to 47 items. Watched six YouTube videos about "how to validate a SaaS idea." Signed up for the waitlist of three competitors to see what they do. Sketched wireframes in a notebook and a napkin. Asked ChatGPT to "write the PRD for a SaaS that does X" and received a bland document that felt technically correct and operationally useless.

You have not written a single line of code. You have not commissioned a single design mockup. You have not talked to a single paying customer about what they would actually pay for. You have not scoped anything a developer could quote without asking you thirty clarifying questions.

The idea is real. Your capacity to turn it into a spec is not. Every week you stay in this state, two things happen. First, your enthusiasm decays — the idea gets less exciting the longer you carry it without shipping. Second, the market moves. Somebody else noticed the same gap. Right now it is probably a three-person team in Austin, or a Stanford grad in SF, or a Bangalore-based solo founder with four free weekends. They will not out-think you. They will out-write-the-spec you.

The problem you actually have is not "should I build this SaaS." The problem is that you do not have a repeatable process for converting a fuzzy idea into a buildable, pricable, defensible spec in a bounded timeframe. Every founder needs one. Most never get one. This post is the published version of the one Routiine uses, day by day, for ten business days.

The Problem

Scoping is not one job. It is a sequence of five jobs, usually run in the wrong order, by the wrong people, with no artifact between them.

Job one is discovery. What problem are you actually solving, for whom, and what do they pay today to solve it badly. Most founders skip this and start with a feature list. The feature list is the last thing you should write, not the first.

Job two is competitive framing. Who already tries to solve this. Which ones your target customer has heard of, hated, loved, or paid. A SaaS idea without a competitive frame is a guess. A SaaS idea with a competitive frame is a hypothesis — and hypotheses can be tested.

Job three is usage modeling. How many times per day or week will a customer open this product. How long will they stay. What will trigger them to open it. Pricing falls out of usage, not out of features. A tool opened daily can charge $89 a month. A tool opened twice a month cannot.

Job four is surface definition. Not features — surfaces. Screens, inputs, outputs, and the data that moves between them. A scope defined in features bloats without limit. A scope defined in surfaces terminates, because each surface has an edge.

Job five is delivery architecture. The stack, the deployment, the auth, the payment rail, the data model, the integration surface. A spec that skips this leaves the developer to invent it, which means every developer invents it differently and none of the quotes you get are comparable.

The standard founder failure is running these five jobs out of order, with no artifact between them, over three to eight months, with enthusiasm bleeding out of each meeting. The Routiine playbook runs them in order, with a documented artifact ending each day, in ten business days. You finish day ten with a buildable spec that any competent engineering firm can quote and most will quote within a 15 percent range, not a 36x range.

The Implication

Here is what founders who scope in ten business days get that founders who scope in eight months do not.

First, a priced, timed, falsifiable spec. A document that says: this is the product, these are the screens, here is the data model, this is the target user, here is the pricing hypothesis, here is how it is tested, here is what it costs to build, here is how long. A document you can hand to a developer, an investor, a co-founder candidate, or a potential customer. A document that commits.

Second, a validated customer. Inside the ten days, the playbook includes four to six customer interviews. Not feedback sessions with your friends. Interviews with people in the target segment who have expressed the pain and have a budget for the solution. Interviews conducted with a specific script that captures willingness to pay, not "would this be cool."

Third, a time-boxed enthusiasm window. Ten days is short enough to hold founder attention. Eight months is not. Every extra month your scope lives in your head, the odds you ship drop by roughly 9 percent — not because you stop caring, but because the market noise accumulates and the fresh conviction of the original insight fades.

Fourth, a pricing model that is not guessed. By day seven, you have interviewed enough customers to know what they pay now for the workaround, what they would pay for the replacement, and the price at which they switch. You do not launch and guess. You launch with a pricing hypothesis grounded in conversations.

Fifth, a buildable spec that gets real quotes. The quote-range problem from the last post — 36x variance on the same idea — collapses when the spec is tight. We routinely see founders get $22,000 and $28,000 and $26,500 quotes from three different Dallas shops on the same tight spec. The shops disagree on who builds it. They mostly agree on what it costs. That is the signal that the spec is ready.

The implication of skipping this process is not that you never build. It is that you build late, you build the wrong thing, you overpay, and you launch to crickets because the pricing and the customer were never validated. Every one of those failures is directly caused by a scope that was never run through a real ten-day sequence.

The Need-Payoff

Here is the published Routiine SaaS MVP scoping playbook. Day by day. Artifact by artifact. Run it yourself or run it with us — the content is the same either way.

Day 1 — Problem Definition. One sentence. Who hurts, what hurts, what they currently do about it. No features yet. No technology yet. Artifact: a one-page problem brief with the sentence, three examples of the pain observed in the wild, and one paragraph on why existing tools fail.

Day 2 — Customer Hypothesis. Who exactly is the target. Job title, company size, industry, geography, technology stack. Not "small business owners." Specifically: "operations managers at Dallas-area commercial HVAC companies with 15 to 80 technicians using ServiceTitan or FieldPulse." Artifact: a one-page customer card with ten named companies that match the hypothesis.

Day 3 — Competitive Frame. List every tool the customer considers today. Their price, their strengths, their weaknesses, their user reviews on G2 and Capterra. Read the one-star reviews most carefully — the language of broken expectations is the language your marketing page will later use. Artifact: a competitor matrix with columns for price, features, rating, and the quoted complaint that best describes your wedge.

Day 4 — Customer Interview Round 1. Three customer interviews, 30 minutes each, on Zoom. Script included. The goal is not to pitch — it is to capture the language the customer uses to describe the pain and the workaround. Artifact: interview transcripts with the three most repeated phrases highlighted.

Day 5 — Usage Model. How often does the target customer encounter the pain? How often would they open this product? What triggers the open? Who else in their org would open it? Artifact: a usage scenario document with daily, weekly, and monthly touchpoints described.

Day 6 — Customer Interview Round 2. Three more interviews. This time pitch a specific shape of the solution — described verbally, not shown — and capture the reaction. Willingness to pay question goes in the last five minutes of each call. Artifact: interviews plus a one-page pricing hypothesis ($X/month, $Y setup fee, willingness to pay supported by N customer quotes).

Day 7 — Surface Map. The five to nine screens the product must ship with. Each screen described in one paragraph. The data each screen reads and writes. The navigation between them. Artifact: a surface map that a designer could wireframe and a developer could estimate.

Day 8 — Data Model. The five to twelve objects in the system. The fields on each. The relationships between them. The lifecycle of the most important object. This is where most amateur specs fail — they describe UI but never describe data. Artifact: a data model diagram.

Day 9 — Delivery Architecture. The stack. The auth provider. The payment provider. The hosting. The integrations. The analytics. The error tracking. Specific choices, not "to be determined." Artifact: a one-page architecture document.

Day 10 — Build Plan and Budget. The scope broken into phases with estimates. Phase 1 MVP, Phase 2 monetization polish, Phase 3 scale readiness. Each phase with a timeline, a cost range, and a success criterion. Artifact: a build plan that can be handed to any competent engineering firm for quote.

That is the full playbook. Ten days. Ten artifacts. A spec that moves.

Running it yourself is possible if you have the discipline. Most founders do not, not because they are undisciplined, but because they are running a business at the same time and the playbook requires roughly six to nine focused hours a day for ten days. That is why Routiine runs this as a Sprint Scope engagement at $2,500. You bring the idea and the attention. We bring the playbook, the interview scripts, the frameworks, the artifacts, and the finishing Build Plan. At the end of ten business days you own the complete spec and a priced estimate for Phase 1.

The Sprint Scope is run under the FORGE methodology. The Product agent leads. The Brand, Search, Paid, Content, Growth, and Data agents each add their domain insights to the artifacts where relevant. The spec passes our ten Quality Gates — yes, even a spec has Quality Gates in the Routiine system. The gate examples: is the problem defined in customer language? Are the interviews actually conducted, not skipped? Does the pricing hypothesis have at least five supporting quotes? Can the data model be implemented without inventing new fields? If any gate fails, we extend the sprint at no additional charge until the gate passes.

Every deliverable is Living Software compatible — the architecture decisions made on day 9 assume the product will evolve continuously after launch, not be shipped and forgotten. The Decay Thesis is baked into the scope itself. If the architecture cannot evolve, it does not pass the gate.

The Ship-or-Pay Guarantee covers the Sprint Scope. If we do not deliver the complete set of ten artifacts in ten business days, you pay nothing. We have run this engagement enough times to know the cadence. Missing it is our problem, not yours.

If you proceed into a Phase 1 build with us after the Sprint Scope, 100 percent of the Sprint Scope fee is credited toward the build. If you take the spec to another firm, it is yours to keep — Ownership Transfer applies to ideas, not just code.

Next Steps

Three actions, in order of commitment.

Read the FORGE page to see the seven agents and the ten Quality Gates in detail, including the gate set that applies specifically to Sprint Scope engagements. Fifteen minutes.

Book a free FORGE Audit at /contact. We take thirty minutes to pressure-test your idea against the day 1 and day 2 artifacts before you commit to the full ten-day sprint. If the idea is not ready for Sprint Scope, we will say so, and recommend what is.

Apply to the Founding Client Program. The first five Dallas–Fort Worth clients lock in a 20 percent founding-rate discount on every Routiine engagement including the Sprint Scope, the Phase 1 Launch build, and the Phase 2 Platform build that typically follows. The seats close when the fifth is filled.

Ten days is short. Eight months is long. The difference between them is not talent, and it is not budget. It is whether you run a playbook or not. The playbook above is published in full. You can use it. You can also stop carrying the idea in your head and ship something that customers pay for by the end of the quarter.