Shipping an MVP in 90 days without painting yourself into a corner

Ninety days is enough time to ship a real product. It is not enough time to recover from the wrong data model, an architecture that fights the domain, or a team that confuses a demo with software. Most MVPs that fail in our experience do not fail because the team was slow — they fail because speed was bought with decisions that came due the moment the product got traction.

This is the playbook we run inside product engineering engagements, and the one we used on our own products first. The premise: the 90-day constraint is a feature. It forces a scope honesty and an architectural restraint that better-funded, slower projects routinely skip. But the constraint only works if you know which corners are safe to cut and which ones quietly schedule a rewrite for month six.

Define the MVP so the deadline is winnable

Three artifacts get called "MVP," and conflating them is the first failure mode.

• A prototype validates desirability. It is allowed to be smoke and mirrors, and it must be thrown away. Its job is to die.
• An MVP validates the business. It does load-bearing work: real users, real data, real consequences when it breaks. The core must be production-grade because you will not get to throw it away.
• A v1 is what the MVP becomes after the market has voted — broader surface, second persona, the settings pages.

The expensive mistake is shipping prototype-quality code to paying customers. Once revenue flows through it, you cannot discard it; you are now refactoring with the engine running, which is the slowest way to build anything. The 90-day target is achievable precisely because the scope is brutal, not because the engineering is casual.

Four scope rules make the deadline realistic:

• One primary user type. Every additional persona roughly doubles the surface area: different permissions, different screens, different onboarding. Pick the persona whose money or attention validates the business, and serve only them.
• One core loop, end to end. Sign up, do the valuable thing, pay or come back. The loop must work completely before anything adjacent exists. A product that does one workflow reliably beats a product that does five workflows partially — and it ships months earlier.
• One platform. Responsive web first, unless the product is camera-, offline-, or notification-shaped — in which case a single Flutter codebase covers both stores, which is why it anchors our mobile app development practice for 0→1 builds.
• Manual behind the curtain. Anything the user cannot see can be a human and a spreadsheet for now: onboarding done by hand, ops run from an admin query. Automate the loop, not the company.

The decisions that paint you into the corner

Some choices cost nothing in week one and dominate month six. These are the ones worth slowing down for:

• The data model. Schema is foundation; UI is paint. A day spent whiteboarding entities, ownership, and how you represent money, time, and state pays back more than any framework decision you will make. Migrating a wrong model under live traffic is the single most expensive correction in software.
• Tenancy. Decide on day one whether this is a single-tenant tool or a multi-tenant platform, even if you launch with one tenant. Retrofitting tenancy means touching every query, every index, and every authorization path simultaneously.
• Authorization boundaries. Role checks belong at the API boundary from the first endpoint. Retrofitting permissions is an audit of everything you have ever shipped.
• Vendor coupling. Payment, auth, and messaging SDK calls scattered through domain logic — with vendor types leaking into your model — convert every future pricing change or acquisition into your refactoring problem.
• No deployment pipeline. "We will set up CI/CD after launch" means launch day is your first integration test, performed in public.

None of these decisions slow down week one. All of them decide whether month six is roadmap or rework.

Architecture: boring, modular, reversible

The right MVP architecture is the least interesting one that keeps your options open.

A modular monolith on one database

One deployable, strict internal module boundaries, PostgreSQL with disciplined migrations. Microservices at 0→1 buy you distributed-systems costs before you have distributed-systems problems: network failure modes, deployment orchestration, and debugging across service boundaries, all before a single user has validated the domain decomposition. Modules give you the same seams for free — and when real traffic later shows you where the hot boundary actually is, you extract a service along a line production has proven, not one a whiteboard guessed.

Buy the edges, behind adapters

Auth, payments, transactional email, file storage, observability: buy all of it. Your 90 days are for the differentiating core, and the build vs. buy calculus is lopsided for commodity infrastructure at this stage. The discipline that keeps the buys cheap later is the adapter: every vendor sits behind an interface your code owns, so outgrowing a provider means rewriting one module instead of auditing a codebase.

A stack your next five hires already know

The best MVP stack is the one the market can staff. TypeScript end to end — Next.js on the front, Node services behind it, Postgres underneath — is the default we reach for in web application development, and the reasoning is the same one we laid out for Next.js in enterprise applications: hiring pool, library maturity, and one language across the boundary. Novel languages and exotic infrastructure are a staffing tax you start paying exactly when traction demands you hire fast.

The security floor

There is a set of controls that cost little in week one and multiples when retrofitted: TLS everywhere, credentials delegated to the auth provider rather than hand-rolled, role checks enforced at the API rather than hidden in the UI, encryption at rest, and logs structured well enough to audit. That floor is non-negotiable in everything we ship — our security architecture describes the full baseline. And if your domain is compliance-shaped — payments, health data, GCC data residency — surface those requirements in discovery, not at the first enterprise security review.

The 90-day cadence

The calendar matters as much as the architecture. Here is the shape that works.

What to cut — and what never to cut

Safe to cut, with the seams to un-cut them later:

• Admin polish. Internal tools can be ugly. Ship raw tables and a query console.
• The second platform. Web or mobile, not both. The API you built is the product; another client can come later.
• Microservices, Kubernetes, multi-region. One region, one managed platform. Scale problems are good problems, and you will solve them with data you do not have yet.
• SSO and SAML. Wait for the enterprise deal that demands it; your auth adapter is the seam that makes it a feature, not a rewrite.
• A custom design system. Take a mature component library, apply your tokens, move on.
• Configurability. Hard-code the defaults. Settings pages are a v1 problem.

Never cut, at any deadline:

• CI/CD with a one-command deploy and a tested rollback
• Database migrations as versioned code
• Authorization checks at the API boundary
• Backups that have survived a restore drill
• Error tracking with alerting
• Correctness on the money path — idempotency keys, webhook signature verification, double-submit protection

The honest cost factors

Team shape beats team size. For 0→1, a small senior team — two product engineers, design front-loaded in the first month, architecture and DevOps as part-time senior involvement — outperforms a larger mixed team. Every person added to a 90-day plan adds coordination cost immediately and capacity later, which is exactly the wrong trade at this horizon.

Staff augmentation vs. dedicated team. Staff augmentation drops senior hands into your existing process — which presumes you have one. A dedicated team brings the delivery process with it: scoping discipline, the cadence above, and accountability for the outcome rather than the hours. For a first product, or for an in-house team already stretched across a running business, the dedicated team is usually the right call; augmentation earns its place after product-market fit, when the bottleneck is bandwidth rather than judgment.

Where budgets actually blow up. Rarely on the engineering line. The recurring culprits:

• No empowered decision-maker — every choice queues for a committee, and weeks die in review.
• Scope churn disguised as feedback. Feedback adjusts the current scope; churn replaces it.
• Compliance discovered late, after the architecture is set.
• The "quick" integration with a legacy system that turns out to have no API and no documentation.
• Design exploration running during build weeks instead of before them.

A fixed deadline does not eliminate these risks. It makes them visible early, which is the next best thing.

Day 91: scaling past product-market fit

The real test of this playbook is not launch day — it is what the architecture lets you do when traction arrives.

• Extract along proven seams. The module that runs hot under real traffic becomes a service; everything else stays in the monolith where it is cheap to operate.
• Add the second platform without rework. The API was the contract all along; a mobile app is another client, not another backend.
• Swap the edges. Outgrow the auth provider or the payment processor, and you rewrite an adapter — not the codebase.
• Scale the team along module boundaries, so new engineers own real seams instead of colliding in a shared blast radius.

Scaling past product-market fit is its own discipline — performance work driven by production traffic, a deliberate hiring sequence, and paying down the scope debts you took on knowingly rather than the architectural debts you avoided. The point of the 90-day playbook is that you arrive at that stage holding options instead of obligations.

A decade of shipping products — for clients across our work and in our own product line — keeps teaching the same lesson: speed and durability are not a trade-off in the first 90 days. They come from the same three sources — ruthless scope, boring architecture, and a seam everywhere you might change your mind.