The question this engagement had to answer
*Can a founder get a real, paid-usable product into customers' hands in one quarter — without the build turning into an eighteen-month platform nobody asked for?*
Every failed MVP we have inherited failed the same way. It was not too slow. It was too broad. Six months in, there is an admin panel, a permissions matrix, three integrations and a billing system, and still no evidence that a single user completes the workflow the company exists to sell.
The commercial reality underneath is simple: runway is finite, and the purpose of an MVP is to convert money into evidence.
What was hard
The tradeoff: depth versus surface. Ninety days buys roughly one deep workflow or four shallow ones. Founders want four, because four looks like a product in a pitch deck. One deep workflow that a user finishes is the only thing that produces a usable signal. We argue for depth every time and we lose that argument sometimes.
The rejected alternative: build it multi-tenant-flexible from day one. The instinct is to build configurable — per-customer fields, per-customer workflow steps, a rules engine — because enterprise buyers will ask. We reject it in Blueprint. Configurability triples the surface area of every screen and every test, and it is the single most reliable way to burn a 90-day window. We build for one opinionated workflow and add configuration when a paying customer names the specific field they need.
What broke: the auth and billing detour. On an early build we let authentication, role management and subscription billing start in week two because they felt foundational. By week six they had eaten a third of the budget and no user had touched the core workflow. Now these are deliberately deferred, thin, or bought. Roles are two values, not a matrix. Billing is a hosted checkout, not an entitlement engine.
Founders change their minds, and that is legitimate. The hard part is not saying no. It is having a mechanism that makes yes affordable.
What we did
1. Blueprint — wrote the scope down, then wrote the "not in this build" list next to it. The Blueprint is a paid, fixed-length phase that produces four artefacts: the locked scope, the architecture, the fixed price and the ship date. It also produces the list nobody else writes — the explicit out of scope register. Admin panel, SSO, audit exports, mobile app, second integration, white labelling. Each item is named, not implied. A feature that is absent but unnamed comes back as an argument in week nine.
2. Defined the activation metric before any code. Before a screen is designed, we agree one number: the percentage of new signups that complete the core workflow end to end within their first session. Not signups. Not DAU. Completion of the thing the product is for. That single definition governs the whole build. Every scope debate resolves the same way — does this feature move activation, or does it move a slide? Onboarding gets built because it moves activation. The admin panel does not, so it does not get built. We instrument the activation funnel in the same sprint as the workflow itself, not afterwards. An MVP that ships without event instrumentation is a 90-day build that produces no evidence, which is a 90-day build that failed.
3. Locked scope with a change mechanism, not a change freeze. Scope is locked, but not frozen. The mechanism is a one-in-one-out swap, decided by the founder in writing, allowed until the end of week eight. Anything added must displace something of comparable size from the locked scope. Price does not move. The ship date does not move. What moves is the contents. This is the mechanic that makes fixed price honest. A change freeze pretends founders learn nothing during the build. Unbounded change control pretends the date is real when it is not.
4. Prototype in weeks 1–3, Forge in weeks 4–10, Harden in weeks 11–13. The prototype is clickable and fake — real screens, no backend — and it goes in front of five to eight target users before real code starts. Roughly a third of the time it changes the workflow materially. Finding that in week two costs three days. Finding it in week nine costs the window. The final two weeks are reserved for hardening: load behaviour, error states, the empty state, password reset, the emails, the things that make a product feel real and that always get squeezed when hardening is not ring-fenced in the plan.
Architecture
The architecture is deliberately boring. Novelty in the stack spends the window that should be spent on the product.
flowchart LR
U["User browser"] --> W["Next.js app<br/>SSR + React"]
W --> API["Application API<br/>typed endpoints"]
W --> AUTH["Hosted auth provider<br/>email + OAuth"]
API --> DB[("Postgres<br/>single tenant-scoped schema")]
API --> Q["Background job queue"]
Q --> W1["Worker: emails"]
Q --> W2["Worker: exports + webhooks"]
API --> OBJ[("Object storage<br/>user uploads")]
W --> PAY["Hosted checkout<br/>subscription billing"]
PAY -.->|"webhook"| API
API --> EV["Event pipeline"]
W --> EV
EV --> AN[("Analytics store<br/>activation funnel")]
API -.-> LOG[("Structured logs<br/>+ error tracking")]
Q -.-> LOGWhy each choice. One application, one database, one queue. Tenancy is a column and a scoped query, not a schema per customer — that decision is reversible later and unrecoverable if made early. Auth and billing are bought, because both are undifferentiated and both are where MVPs bleed weeks. The event pipeline is first-class, not an afterthought, because activation measurement is the deliverable.
What is deliberately absent. No microservices. No Kubernetes. No event-sourced core. No custom permissions engine. Each of those is a defensible choice for a product with traction and a catastrophic one for a product looking for it.
How we evaluated it
An MVP is evaluated on evidence produced, not on features shipped.
The metric that mattered: activation rate. Defined before code, instrumented during the build, measured from the day the first external user signs in. We report it weekly with the funnel underneath — signup, first meaningful action, workflow completion — so the drop-off is visible at the step, not just in aggregate.
The eval set. For an MVP the eval set is a written list of 20–40 end-to-end user journeys, each with a defined correct outcome, run before every release. Signup on mobile Safari. Upload a malformed file. Abandon at step three and return the next day. Invite a teammate who already has an account. These are the paths that break, and they are the paths a demo never covers.
Latency where it is felt. We hold p95 on the three interactions that sit inside the core workflow — page load, the primary save, and any operation the user waits on. Everything else is measured but not gated. Gating everything means gating nothing.
Failure modes and what happens when the system is wrong. Three named ones:
*A background job fails silently.* Containment: every job is idempotent, retried with backoff, and a terminal failure raises an alert and surfaces a visible state to the user rather than a silent nothing.
*A webhook from the payment provider is missed or replayed.* Containment: webhooks are idempotent on event ID, and subscription state is reconciled from the provider on a schedule rather than trusted from a single delivery.
*A user hits an unhandled error mid-workflow.* Containment: errors are tracked with the user and the workflow step attached, and the user gets a recoverable state with their input preserved — never a blank page.
How we measured. Activation and funnel figures on any real engagement come from the client's own event pipeline and analytics store, reported over a stated window against the first cohort. No modelling, no extrapolation.
What we are not claiming. Nothing on this page is a client outcome. We do not claim a conversion rate, an activation percentage or a revenue figure for this scenario, because activation depends on the market and the product idea, not on the build. What the build controls is whether the number exists at all and whether it can be trusted.
What a 90-day build cannot include
This list matters more than the feature list. A SaaS MVP development agency that will not tell you what falls outside the window is selling you the argument you will have in week ten.
SOC 2 or ISO 27001 certification. The controls can be designed in; the audit period cannot be compressed.
A native mobile app alongside the web product. Responsive web, yes. Two more platforms, no.
Enterprise SSO and SCIM provisioning. Weeks of work each, and no early customer blocks on them.
A configurable workflow engine. See the rejected alternative above.
More than one deep third-party integration. The second one is always three times the estimate, because the first one taught you nothing about the second one's API.
A full admin back office. Early operations run on database access and a handful of internal scripts. This is unglamorous and correct.
Multi-region deployment or data residency guarantees.
Migration of historical data from an existing system. That is its own project with its own window.
If two or more of these are genuinely non-negotiable for the first customer, the honest answer is that this is not a 90-day build, and we say so in Blueprint rather than discovering it in week eleven. We wrote the longer version of this question up in fixed-price vs hourly software development.
What we would do differently
We would put real users in front of the clickable prototype earlier and with less polish. Founders resist showing something rough. The rough version gets more honest feedback, because users critique a sketch and defer to a finished screen.
We would cut the second integration on sight. Every build where we allowed two integrations ended up trading something real away in week nine to keep the date. The one-in-one-out swap saved the window, but the swap should never have been needed.
We would set the activation metric with a target attached, not just a definition. Defining the number without agreeing what would count as success means the founder receives a figure after launch with no frame for judging it. A stated hypothesis — "we think a viable product activates above X" — makes the result actionable instead of merely interesting.
We would push back harder on custom design systems. A styled component library plus real attention to the three screens in the core workflow beats a bespoke design system every time in a 90-day window, and the design system is what founders keep asking for.
What is still running
The MVP is the start of the engagement, not the end. Typical post-launch work runs in shorter fixed windows: closing the largest activation drop-off, adding the second integration a paying customer has now actually named, and the security and access work that becomes real when the first enterprise buyer arrives. Retainers are for roadmap ownership, not for maintenance drift.