How we ship a production MVP in 7 days without cutting corners.

Most of the "build an MVP in a weekend" content is aspirational at best and dishonest at worst. What lands on production is usually a front-end demo wired to a database, a ten-minute tutorial scaled up, or a prototype that breaks the moment anyone who isn't the founder touches it.

We build something different. A 7-day MVP sprint, for us, ends with a live application on a domain the founder owns, with real user auth, a real payment flow if the product needs one, real emails going out, a deploy pipeline, a staging environment, and documentation good enough that a second engineer can extend it without calling us. That's the bar. We hit it in a week because we've been deliberate about what the week does and doesn't include, and because AI-paired development genuinely compresses the parts of the work that used to dominate the timeline.

What we mean by "production-ready"

Before we talk about the timeline, the definition matters. "Production-ready" is doing a lot of work in that sentence, and the marketing version of it is often nonsense. Here's what we mean, specifically:

The application is deployed to a provider the founder controls, on a domain the founder owns. Not a subdomain on our infrastructure.
Authentication works end to end. Sign-up, sign-in, password reset, session handling. Real hashing, real rate limits, real email verification if the spec calls for it.
Payments, if part of the spec, are integrated with a real processor in live mode with keys ready to swap. We leave test keys in the build; the founder swaps them on the day they open it up.
Transactional emails send from a real sender with SPF and DKIM set up on the founder's domain.
There is a staging environment. It mirrors production. You can break it without breaking anything paying customers touch.
Errors go somewhere a human can read — Sentry or equivalent — with source maps uploaded.
A handover doc exists. It names the stack, lists the environment variables, explains how to deploy, explains how to add a feature. A second engineer can pick it up cold.

What's not included is equally important: we don't try to build the roadmap. We build the thing that lets the founder start learning from real users. Everything else is a second sprint.

Day 0 — the locked spec

The sprint doesn't start on day one. It starts on day zero, which happens before the clock does. Day zero is the end of a discovery sprint — usually three days, often less if the founder came in prepared — and the output is a spec that both sides agree is locked for the 7 days.

"Locked" is the word that does the most work in the whole engagement. It means: this is what gets built. Scope changes during the sprint become sprint-two work. There's nothing adversarial about it — we'd rather finish strong on a smaller thing than drift on a bigger one — but the lock is what makes the timeline honest.

The spec names the user types, the core objects, the key flows, the integrations, the stack, and the non-goals. It also names the two or three decisions we know we're deferring: things the founder hasn't decided yet that aren't blocking, and that we've agreed to ship a reasonable default for.

Day 1 — Lock

The first day is the one it's most tempting to skimp on. We don't.

Day one is project setup and the foundation that everything else stands on. A repo, the framework scaffold, a hosting target, a database, a CI pipeline, a staging deploy, a production deploy with a holding page, error monitoring, analytics, and the data model and auth scaffolding. The stack is standard across our sprints — Next.js on Vercel, Postgres on Neon or Supabase, Stripe, Resend, Sentry, PostHog — and that standardisation, plus AI-paired scaffolding, is a big chunk of why a day is enough where it used to be three.

By end of day one there is a deploy pipeline, a green CI, a staging URL, a production URL behind a holding page, the user table, the auth flows, and the protected routes. The thing that gets rushed in most "fast MVPs" and causes two months of pain later — auth done right — is in by close of day one. We've learned not to defer it.

Day 2 — Frame

Day two is the first real surface. We build the primary user flow end to end on staging — sign up, sign in, create the first object, see it on a dashboard. By close of day two the founder is clicking through their product on a staging URL, not a Figma file.

The point isn't the feature. The point is to prove the stack works end to end, surface the first interaction questions, and give the founder something concrete to react to before the deep build starts. A founder who's clicked through the real thing on day two writes much better feedback for days three to five than a founder who's still reading specs.

Days 3–5 — Build

This is the longest stretch, and it looks like normal software engineering. We work through the spec one flow at a time, two or three flows per day, with a nightly deploy to staging.

The pattern we follow is: a flow isn't done until the happy path works, the three obvious error states are handled, there's a test covering the flow, and it's been deployed to staging. We don't batch testing at the end. A day that ends with "everything is built, we'll test next week" is the sign of a sprint that's about to miss.

The founder is looped in every day. A five-minute Loom at the end of the day, a shared staging link, and a list of "things I'd like you to click on before tomorrow." The daily loop is the other reason 7 days works — because a question that shows up on day three and sits for two days is half the sprint of rework.

Day 6 — Harden

By end of day five, every flow in the spec exists in some form on staging. Day six is where we turn a working app into a shippable one.

That includes: empty states, loading states, error states that a human wrote the copy for, a mobile pass, a keyboard pass, a screen-reader pass on the two or three flows that matter most, transactional email polish, payment edge cases, rate limiting on the sign-up and password-reset endpoints, logs that someone on call can actually read, and a review of the database indexes.

This is also where the integrations that were stubbed get wired up properly. Webhooks with idempotency. Retry logic. Timeouts. Secrets rotated out of the repo and into the platform's secret manager. The kind of work that's invisible from the outside and makes all the difference when the founder turns traffic on.

Day 7 — Ship

The last day is deliberately unglamorous. Day seven is handover and the production deploy: writing the docs, walking the founder through the admin surfaces, rotating any shared credentials out to founder-owned accounts, a paired production deploy, and a structured review of what's in, what's out, what we'd recommend for sprint two. There's always a small buffer in the day for the inevitable last-mile finding.

We close the sprint with the founder owning every piece of infrastructure in their own name. Their GitHub, their Vercel, their Stripe, their domain, their database. We hand over the keys. No lock-in is a product decision, not a pricing one: it's what makes a founder trust us with the second sprint.

The things we don't cut

The way we hit the timeline isn't by speed-running the work; it's by being strict about what's in scope. The things we refuse to cut, even when the spec feels tight:

Auth done right. Rushed auth is a re-platform later.
A test per critical flow. Not full coverage. The handful that stop a billing bug or a lost-session bug reaching a real user.
Deploys from day one. If you can't deploy on day one, you can't deploy on day seven, and you'll find out the wrong way.
Error monitoring. Shipping without it is how the founder finds out about an outage from a customer.
A real handover. The day-seven doc is non-negotiable. It's what makes the sprint a thing the founder owns, not something they rent from us.

The three things that always blow up the timeline

After enough sprints, the failure modes are predictable. We design around them explicitly.

One: scope drift. The founder sees the staging app, gets excited, and asks for "one small thing." The small thing is almost never small. The locked spec exists because of this. We say yes with a ticket in sprint two — always — and keep the current sprint honest.

Two: third-party accounts. Stripe approval. Custom domain DNS. An email provider that flags sending from a domain with no history. These have calendar time baked in that doesn't care about your sprint. We kick them off on day zero, not day six.

Three: a decision that wasn't made. "We'll figure out the pricing model during the sprint" is the most expensive sentence in software. Any decision we're still making during the build is a pause in the build. Discovery is where decisions happen, so that building is just building.

When 7 days is the wrong answer

A 7-day MVP sprint is the right shape for a specific kind of project: a focused product with a clear user, a clear core loop, and a founder who knows what the first version needs to prove. It is not the right shape for a project that's still figuring out what it is.

If you're still learning what you're building, a week of engineering won't help you. Two days of discovery might. We'd rather tell you that on a call than sell you a sprint that won't land.

But if you know what the first version looks like, and you're tired of the tools-first conversations that agencies keep opening with — a week is more than enough. It's what we do. It's all we do.