Series A DevTools SaaS:
empty repo to pilot revenue in 12 weeks.

Challenge

A Series A DevTools company had raised on a thesis their founders could explain in 60 seconds and on a prototype that did about 30% of what the deck implied. The runway calculus was simple: ship a real MVP that pilots could actually use within a quarter, or burn the round on infrastructure that nobody touched.

Their internal team was three engineers — strong, but stretched between hiring, infra, and a half-rewritten prototype that had accumulated nine months of "we'll fix it later." They needed a pod that could land on the codebase, take ownership of a clean v1 build alongside the founders, and not require a quarter of onboarding to become productive.

Approach

We scoped to a 12-week build with three fixed milestones, weekly Friday demos to investors and design partners, and a hard rule that anything outside the milestone list moved to backlog without debate.

Week 1 — discovery and architecture freeze

We did not start coding. We sat with the three pilot design partners, walked through their actual workflows in the existing prototype, and identified two features that mattered and four that didn't. We froze the API surface, the database schema, and the authentication model in writing before the first PR.

Weeks 2–6 — vertical slices

Every Friday demoed an end-to-end vertical slice, not a horizontal layer. Week 2: a single user could sign up, create one resource, see it persisted. Week 3: that resource could be edited, versioned, and shared via a real link. By Week 6 the loop was complete and design partners could log in.

Weeks 7–10 — pilot hardening

This is where most "MVPs" die. We spent four weeks on the unsexy part: error handling, audit logs, role-based access for pilots' teams, billing instrumentation (Stripe metered + flat tier), and a real on-call rotation with paging.

Weeks 11–12 — pilot onboarding and revenue plumbing

First three pilots onboarded with white-glove sessions. Stripe wired to a real subscription model. Activation events instrumented in PostHog so the founders could see pilot behavior the day after a demo, not the next quarter.

What we built

• Web app — React + TypeScript on Next.js, App Router, server components for the dashboard tier, edge-cached marketing surface.
• API — Node + Fastify, OpenAPI spec generated from types, a single typed client shared between web app and pilot SDK.
• Database — Postgres on a managed service, schema versioned via migrations from day one, RLS for tenant isolation.
• Pilot SDK — minimal TypeScript client, generated from OpenAPI, published as a private npm package with semver discipline.
• Billing — Stripe Subscriptions + metered usage, webhook handlers covered by integration tests, idempotency keys on every write.
• Observability — structured logs, traces on critical paths, alerting on the four metrics the founders actually cared about (sign-up success, first-resource-created, retention day-7, error rate).
• Onboarding playbook — a real document handed off to the in-house team so we weren't a single point of knowledge.

Results

The pilot launched on the date in the kickoff doc. Three design partners onboarded and stayed paying through the cohort. The founders' next investor update led with the product, not the thesis. Internal hiring picked up because there was now a real codebase and a real product to recruit against.

Equally important: the in-house team owned the codebase by week 13. Our pod stayed on a reduced retainer for a further six weeks for handover support, then exited cleanly. No "indispensable contractor" trap.

Stack

Why the timeline held

The schedule held because we said no to four features the founders wanted, and we put that no on a slide each Friday with the reason. By week six the design partners stopped asking for them. The pattern is reliable: investor-grade urgency plus weekly accountability plus a senior pod that has shipped this shape of product before.