The Two-Week MVP That Isn't Throwaway Code

There are two kinds of MVP.

The first is a demo wearing a product's clothes. It gets funding, gets users, and then gets thrown away six months later because nothing in it can survive contact with real load, real data, or a second developer.

The second is a small, honest version of the real thing. Fewer features, same bones. It grows instead of getting replaced.

Two weeks is enough time to build the second kind. It is not enough time to build the second kind by accident. Here's what actually makes the difference.

Scope is the architecture decision

Everyone treats scope as a product conversation and architecture as an engineering one. They're the same conversation.

Every feature you keep in the two-week window forces structural choices. Every feature you cut buys you the ability to make those choices later, with better information. So the scoping question isn't "what's nice to have" — it's "what does this feature commit us to?"

Our rule: an MVP ships one loop. One user, one job, start to finish, working properly. Not five jobs done at 60%.

For a booking product, the loop is: customer finds a slot → books it → business sees it → both get confirmation. That's it. No staff management, no analytics dashboard, no loyalty tier. Those are real features. They're also the ones that quietly triple the data model.

The four things we never skip

Speed comes from cutting features, not from cutting foundations. Four things go in on day one, every time, because retrofitting them costs 5–10× more than including them:

1. A real data model. Not JSON blobs you'll "normalize later." Later never has a calendar slot. Get the entities and their relationships right; everything downstream inherits that decision.
2. Auth and permissions done properly. Bolting real authorization onto an app that assumed one trusted user is a rewrite, not a patch.
3. Deploys and environments. Preview deploys from day one. If shipping is a ceremony, you'll ship less, and the whole premise collapses.
4. Observability at the seams. Logs and error tracking on every external boundary — payments, messaging, third-party APIs. When something breaks at 2am in week three, this is the difference between a fix and a mystery.

None of these are visible in a demo. All of them decide whether the code survives.

The four things we deliberately skip

• Premature abstraction. No plugin systems, no config-driven everything, no "we might need multi-tenancy someday." Write the specific thing. Generalize on the second real use case, not the imagined one.
• Microservices. A well-organized single deployable beats a distributed system you now have to operate. Split later, when a real boundary makes itself obvious.
• Custom infrastructure. Managed database, managed auth, managed queue. Your differentiation is not your Postgres cluster.
• Design systems built up front. Use the tokens and the primitives; build the component library out of components you actually shipped, not the ones you predicted.

An MVP is not a small version of the product. It's the first honest version of the loop that matters.

What the two weeks actually look like

Roughly:

• Days 1–2 — decide. The loop, the data model, the stack, the non-goals. Written down, one page. Most of the risk in a fast build is ambiguity, not engineering difficulty.
• Days 3–9 — build in the open. Working software deployed at the end of every day. No hand-off, no "integration week." The client sees the real thing on a real URL from day three, which is when useful feedback starts.
• Days 10–12 — harden. Edge cases, error states, empty states, mobile, load. The 20% that separates "works in the demo" from "works on a Saturday night."
• Days 13–14 — ship and instrument. Real domain, real payments, analytics, monitoring. Then watch actual usage before deciding what's next.

Note what isn't in there: a discovery phase that produces a document nobody reads, and a hand-off between the people who decided and the people who build. Removing those two things is most of where the time comes from. That's the AI-native part of how we work — the spec and the build collapse into one loop.

The test for whether it was throwaway

Ask this in month six: when you added the next major feature, did you extend the codebase or fight it?

If the data model bent to accommodate the new thing, you built the real product small. If you had to run a migration that scared you, or fork the app, or start a rewrite branch "properly this time" — you built a demo and paid for it twice.

Two weeks is a constraint. Constraints improve products. What they never justify is code you'll have to apologize for.

Building something and want the two-week version done right? Tell us what you're building — or see how we work.