Most SaaS builds that go wrong don't go wrong in the code. They go wrong in the two or three weeks before it: in what was agreed, what was quoted, and what nobody wrote down. By the time the symptoms show (missed dates, a growing invoice, a demo that never quite arrives), the causes are months old.
The good news: the causes are visible early, from the founder's chair, without reading a line of code. Here are the three we see most, and for each one the question to ask this week to test for it.
1. Nobody has written down what v1 deliberately does NOT do
What it looks like from your chair. You have a document (maybe a proposal, maybe a long email thread) that describes what the product will do. It reads well. What it doesn't contain is a single sentence saying what's been cut: no “v1 will not have X”, no “we're deferring Y”. Every conversation about scope ends with “yes, we can include that”.
Why it predicts trouble. Scope with no edges isn't scope; it's a wish list, and a quote against a wish list is fiction. Every build decision from here on (the data model, the third-party services, the timeline) depends on where the edges are. If they were never drawn, they get drawn later, mid-build, one awkward conversation at a time, and each one arrives as either a delay or a change-order invoice. A team that pushes back on your scope before signing is not being difficult; they're doing the part of the job that protects your budget.
The question to ask this week. “Show me the list of things v1 deliberately doesn't do.” If the answer is a list, you're in good shape. If the answer is a pause, you've found the problem while it's still cheap to fix: the fix is a half-day scoping conversation, not a rebuild.
2. The plan has no working software until near the end
What it looks like from your chair. The plan is milestones: design phase, then development phase, then testing, then a big reveal in month three or four. Between kick-off and reveal, your visibility is status updates and maybe some screenshots. Nothing you can click.
Why it predicts trouble. Long silences are how budgets double. If nothing runs until month three, then month three is the first moment anyone, including the team, discovers whether the estimates were right, whether the design survives contact with real data, and whether what's being built matches what you meant. Every one of those discoveries is cheap in week two and expensive in month three. A healthy build has a walking skeleton early: something thin but real (deployed, clickable, end to end), usually within the first two or three weeks, growing every week after. It's how we structure our own SaaS builds, not because it's fashionable but because it's the only reliable way to keep an estimate honest.
The question to ask this week. “What will I be able to click in week three?” The answer should be a URL, however ugly. “You'll have the designs to review” is not working software; designs can't reveal that the estimate was wrong.
3. Nobody has talked about the plumbing, or about what happens after launch
What it looks like from your chair. The conversations have all been about features: the exciting part, the thing that makes your product yours. Nobody has raised sign-up and login, password resets, payments, transactional emails, backups, or monitoring. And the quote ends at launch day: no line for the bug fixes and small pivots that the first month of real users always brings.
Why it predicts trouble. The plumbing is unglamorous, unavoidable, and a large slice of any real build. When it's absent from the conversation, it's usually absent from the estimate, which means it either gets bolted on late (badly), invoiced as a surprise, or quietly cut in ways you can't see until they leak. And a quote that ends at launch isn't a product quote; it's a demo quote. Products meet real users; demos don't have to.
The question to ask this week. Two, really: “Where are auth, payments, backups and monitoring in this quote?” and “What happens in the month after launch, and is it priced?” A team that has built SaaS before will answer both without blinking. A team that hasn't will treat the questions as scope creep, which is itself the answer.
What to do with a bad answer
One shaky answer doesn't mean fire your team. It means you've found the conversation to have now, while it costs a meeting instead of a rebuild. All three of these are cheap to fix before code is written and expensive after. That's exactly why they're worth testing for this week rather than next quarter.
Worried about a build you've already started, or about one you're about to commission? Bring it to a 20-minute call. Bring the quote and the plan; you'll leave knowing which of these three signs apply and what to do about each. If the honest answer is that your current team just needs a scoping session, that's what you'll hear.
