The fastest way to lose money on a SaaS build is to underestimate how much "build" is actually scope creep wearing a build hat. The second fastest way is to underestimate how much discovery you owe the product before writing a single line of code. The third fastest way is to skip launch infrastructure because you are too tired by then to care.
This is a case study of a 14-week SaaS sprint we ran in early 2026 that avoided all three failure modes. Names and a few specifics are anonymized at the client's request, but the timeline, stack, team, metrics, and decisions are all real. If you are looking at a sprint of similar shape, this is the playbook.
The TL;DR
- 14 weeks total. Discovery (2 weeks) -> Design (3 weeks) -> Build (7 weeks) -> Launch (2 weeks).
- Team of 5.5 people: 1 PM, 1 designer, 2 senior engineers, 1 QA, 0.5 founder time on our side. Plus the client founder full-time.
- Stack: Next.js + Supabase + Stripe + Resend. Boring, fast, well-supported.
- AI-augmented engineering pattern drove roughly 2.3x throughput on routine work. Architectural decisions and edge cases stayed human.
- Shipped on time. Three features got cut, two of them by design.
- Launch metrics: 41 paying customers in week one, $4,800 MRR, 1.9% trial-to-paid, p95 LCP 1.4s.
The brief
The client was a vertical SaaS founder targeting US-based residential cleaning businesses. The product is a CRM and dispatch tool: schedule jobs, send techs to addresses, capture before/after photos, generate invoices, get paid. Salesforce-style for an industry where Salesforce was always the wrong answer.
The brief in one sentence: ship a working product to 50 paying customers in 90 days, with a clear story for raising a seed round on the back of it.
The constraints we agreed to:
- 14 weeks from kickoff to public launch.
- $145,000 fixed price for our scope (design + build + launch).
- The founder owns sales. We do not promise a seed round; we promise a product the seed round can be raised on.
- Quality bar is "real B2B SaaS." Not "weekend MVP." Not "enterprise platform."
We covered the broader question of SaaS MVP cost in 2026 elsewhere; the price band on this one was on the low end of "serious" and the high end of "scrappy."
The team
Five and a half people on our side, plus the client founder full-time:
- PM (0.5 FTE). Ran the sprint cadence, owned the change-control conversations, was on every client call.
- Designer (1.0 FTE for weeks 3-5, 0.3 FTE thereafter). Owned the design system, all primary flows, and the marketing site at launch.
- Senior engineer A (1.0 FTE). Backend lead. Owned the Supabase schema, API surface, Stripe integration, and the dispatch logic.
- Senior engineer B (1.0 FTE). Frontend lead. Owned the Next.js app, the design system implementation, and the photo capture flow.
- QA (0.5 FTE). Owned the test plan, automated test coverage, and pre-launch UAT.
- Founder oversight (0.5 FTE). Pricing, escalations, and one weekly architectural review.
Plus the client founder, who was at every standup, made every business decision in the call rather than offline, and personally interviewed every UAT customer.
This last point matters more than people credit. The client founder being present and decisive is the single biggest predictor of a sprint that hits its date. We covered why most projects fail right here.
The stack
Next.js 16 (React 19) on Vercel for the application and the marketing site, single codebase with route segmentation.
Supabase for Postgres, auth, storage, edge functions, and realtime subscriptions. Single vendor for the data layer.
Stripe for billing, with checkout-in-Next.js and the customer portal for subscription management.
Resend for transactional email - sign-up, magic link, job notifications, daily digest.
Vercel for hosting and edge.
Sentry for error monitoring from day one.
Posthog for product analytics from day one.
The decision was made in the discovery phase based on the client's team profile (one technical co-founder, intermediate React skills) and the product's needs (multi-tenant SaaS with realtime dispatch). We covered the broader stack landscape in Top 10 Tech Stacks for SaaS in 2026 and the broader stack-choice framework in How to Choose the Right Tech Stack.
The 14-week Gantt
Here is the actual sprint shape we ran, week by week:
| Week | Phase | Primary work | Milestones |
|---|---|---|---|
| 1 | Discovery | Stakeholder interviews, JTBD mapping, competitive teardown | Brief locked |
| 2 | Discovery | Tech stack decision, ICP and pricing model, feature scope | SOW signed, scope frozen |
| 3 | Design | Information architecture, wireframes, design system foundations | IA approved |
| 4 | Design | Hi-fi screens for the 5 primary flows | Design checkpoint with UAT panel |
| 5 | Design | Hi-fi screens for secondary flows, marketing site design | Final design approval |
| 6 | Build | Project scaffolding, Supabase schema, auth flow | Auth shipped, deployed to staging |
| 7 | Build | Dispatch core: job creation, assignment, schedule view | Dispatch demo to client |
| 8 | Build | Photo capture, mobile-responsive tech app | Field tech UAT round 1 |
| 9 | Build | Stripe integration, billing flows, subscription tiers | Billing live in staging |
| 10 | Build | Customer-facing job tracking, notifications | End-to-end demo to client |
| 11 | Build | Reports dashboard, daily digest, admin tools | Feature complete in staging |
| 12 | Build | Bug fixes, performance, accessibility audit | Performance budget hit |
| 13 | Launch | UAT with 8 friendly customers, polish | Soft launch with friendlies |
| 14 | Launch | Public launch, monitoring, week-one support | 41 paying customers |
The visual shape of this Gantt is "discovery is short, design is medium, build is long, launch is short - but launch is two weeks, not one." Squeezing launch to one week is a classic failure mode that turned into 11 cases of "we wish we had a second week" out of the last 12 sprints we ran. Two weeks is now the default.
Phase 1: Discovery (weeks 1-2)
Two weeks of discovery saved us at least three weeks of build later.
Week 1 was stakeholder interviews and JTBD (jobs-to-be-done) mapping. The founder had hypotheses about what cleaning business owners needed; we tested them against eight current owners we found through the founder's network. Three of the founder's hypotheses survived. Two were partially right. Three were wrong - the owners did not care about features the founder thought were core, and they desperately wanted features the founder had not considered.
Week 2 locked the tech stack, the ICP, the pricing model ($49/month for solo, $149/month for teams), and the feature scope. We deliberately scoped narrow: the v1 would do six things excellently and zero things poorly.
The key discovery output was a one-page brief that named the ICP in plain language, named the three features that absolutely had to ship, named the four features that we would ship if time allowed, and named the seven features we would explicitly not ship in v1. This list became the change-control bible for the rest of the sprint.
We covered the broader case for serious discovery in The Discovery Phase Cost-Saving Approach.
Phase 2: Design (weeks 3-5)
Three weeks of design in the middle of the sprint - longer than many teams budget. We made it work because the design did not stop when build started; the designer dropped to 30% time during build to handle the inevitable design questions that come up under construction.
Week 3 was information architecture and wireframes. The designer ran one half-day workshop with the founder to anchor the IA against the JTBD map.
Week 4 was hi-fi design for the five primary flows: sign up, create a job, dispatch a tech, capture a job in the field, get paid. The designer reviewed each flow with the UAT panel of three friendly customers before locking. Three changes came out of those reviews; two of them mattered and got incorporated.
Week 5 was hi-fi design for the secondary flows and the marketing site. The marketing site was deliberately small - hero, features, pricing, FAQ, sign up. We modeled it after the patterns we covered in SaaS Website Design: Patterns That Convert in 2026 - real product screens above the fold, transparent SMB pricing, a customer logo bar (empty at launch, filled by week six).
The design system shipped as Tailwind tokens with a small set of ShadCN UI primitives extended to match the brand. The designer documented it in Storybook so the engineers could build to it without ambiguity.
Phase 3: Build (weeks 6-12)
Seven weeks of build. The cadence:
- Daily standup, 12 minutes, AI-generated brief on screen.
- Sprint demo every Friday to the client founder. Whatever was working in staging got demoed.
- PR review pass at end of every day. Two senior engineers reviewed each other's work; AI review pass ran first to catch the obvious stuff.
- Friday afternoon retro every week. What worked, what slipped, what changes for next week.
The AI-augmented engineering pattern that drove the throughput is the one we described in detail in What an AI-Augmented Workflow Actually Looks Like at an Agency. Routine refactors, test scaffolding, type definitions, and CRUD endpoints went through Claude Code with human review. Architectural decisions, edge cases, integration design, and the dispatch algorithm stayed primarily human.
Where the AI pattern saved time:
- Test scaffolding was 4-5x faster than hand-writing.
- Boilerplate API endpoints (~25 of them) shipped in roughly 30% of the historical time.
- Migration writing went from "annoying" to "trivial."
Where it did not help much:
- The dispatch algorithm took the time it always takes - because the hard part was the business logic, not the code.
- The Stripe integration took the time it always takes - because the hard part was the edge cases, not the typing.
- The photo capture flow on mobile took longer than estimated - because mobile camera APIs are still mobile camera APIs.
The two weeks where we burned the most time on the wrong things:
- Week 8 went 1.5 days over because the field tech UAT surfaced a usability issue we had to redesign mid-sprint. We caught it, but it cost us.
- Week 10 went 1 day over because Stripe webhooks behaved differently in production-mode test mode than we expected. Common gotcha; we should have known. Cost us a day.
Phase 4: Launch (weeks 13-14)
Two weeks. Worth every day.
Week 13 was UAT with eight friendly customers. Six of them were beta accounts the founder had been talking to for months. Two were cold introductions through the founder's network. Each got a 45-minute onboarding call. Five logged in within 48 hours and started using it. Three needed a follow-up nudge. All eight provided feedback within the week.
The week 13 feedback drove three small fixes:
- The dispatch view defaulted to today; it should default to "today and tomorrow."
- The job status badges were ambiguous; we relabeled and recolored them.
- The Stripe checkout was too detached from the rest of the app; we added inline upgrade prompts.
Week 14 was public launch. Marketing site live. Pricing page live. Sign-up open. The founder did the launch outreach - LinkedIn post, three industry forums, and a paid placement in a residential services trade newsletter.
What we instrumented before launch (this list is the difference between "launched" and "launched well"):
- Posthog with conversion events for sign-up, trial start, first job created, first invoice sent, paid conversion.
- Sentry with sourcemaps and a Slack alert on any error rate spike.
- Vercel Analytics + Speed Insights for real-user CWV.
- A weekly Looker-style dashboard generated from Posthog and Stripe data, sent to the founder every Monday morning.
The launch metrics from week one:
- 41 paying customers (founder's stretch goal was 50; week-one realistic was 25-30).
- $4,800 MRR (avg ARPU $117).
- 1.9% trial-to-paid conversion rate on day-7 trials (industry benchmark for vertical SaaS at this stage is ~1.5-2.5%).
- p95 LCP 1.4s, p95 INP 180ms on the application; the marketing site clears all three Core Web Vitals at p75.
- Zero P1 incidents in week one. Two P2 bugs filed and fixed within 36 hours.
What got cut
Three features did not ship in v1. Two were intentional cuts; one was a forced cut.
Cut by design: Customer-facing self-service portal. The founder wanted it; the discovery surfaced that customers preferred SMS notifications over a portal at this stage. We shipped SMS notifications via Resend SMS. The portal is a v1.2 candidate.
Cut by design: Multi-region support. The founder's first 200 target customers are all US-based. Multi-region adds complexity (locale, currency, timezone math, GDPR). We deliberately deferred.
Cut under pressure: A reporting dashboard with custom date ranges. We shipped a fixed "last 7 days / last 30 days" version. The custom range was descoped in week 11 to protect the launch date.
The discipline that made these cuts work: the v1 brief named exactly which features were in scope, which were "if time allows", and which were explicitly out. When week 11 hit and the custom date range was at risk, we did not panic - we executed the change-control conversation we had pre-negotiated in week 2.
What we would do differently
Three things we would change next sprint:
- Budget mobile camera work as a one-week task, not a half-week task. Every mobile camera feature takes longer than you think.
- Run the Stripe webhook integration end-to-end in week 7, not week 9. The earlier this works in test mode, the less it bites in production mode.
- Add a half-week of buffer between week 12 and week 13. Going straight from "feature complete" to "UAT" with no air assumes the build is right. Sometimes it is not.
Cost economics
The fixed price was $145,000. The breakdown:
- Discovery: $18,000 (12%)
- Design: $32,000 (22%)
- Build: $80,000 (55%)
- Launch and post-launch support (first 30 days): $15,000 (11%)
The founder spent another ~$11,000 on direct infrastructure (Vercel Pro, Supabase Pro, Stripe fees, Posthog, Sentry, Resend, Stripe initial implementation fees, etc.) over the 14 weeks plus first 30 days post-launch. Total ~$156,000 to working SaaS with paying customers.
The price ratio against historical similar projects: roughly 30% lower than the same-scope project would have cost in 2024, primarily because the AI-augmented engineering pattern compressed build hours without compressing build quality.
The reading list we point clients at when they are evaluating a similar sprint: The SaaS MVP Cost Guide for 2026, Idea to MVP in 30 Days, and How to Build an Outstanding SaaS Product.
Where to start
If you are about to commission a sprint of similar shape:
- Budget two weeks for discovery. Not one. Not "we already know what we want." Two.
- Lock the v1 brief with explicit "in / if-time-allows / out" lists. This is the change-control bible.
- Pick boring, well-supported infrastructure. Next.js + Supabase + Stripe + Resend is a great default for vertical SaaS in 2026.
- Instrument launch from day one of build. Sentry, Posthog, Vercel Analytics. The metrics you do not capture are the metrics you cannot improve.
- Plan two weeks of launch, not one. UAT in week n-1, public in week n. The week of buffer is where the polish happens.
If you are evaluating a SaaS sprint of this shape and want a second opinion - on the brief, the team, the stack, the timeline, or the price - that is the conversation we run as part of our SaaS Development service and our Software Development practice. We will tell you straight when 14 weeks is realistic and when the brief is hiding 22 weeks of work.
Want a second opinion on a SaaS sprint plan? Contact us for a free 30-minute consultation.