How We Ship a Core in 14 Days and Live in 28

Definition: MVP development timeline at Emiote is a Build Sprint — core usable on staging in 14 days, hardened live in 28. Days 0–14 ship one primary job a stranger can finish without a walkthrough; days 15–28 harden payments, five states, backups, and deploy so a user can pay and return.

Why wait six months to learn one thing? Most founders need two weeks to see if a stranger can finish the core job.

We run Build Sprints in two phases: core in 14 days, live in 28. The first half answers “does this work for a real user?” The second makes sure it stays working when money and trust are on the line.

BUILD SPRINT — CORE 14 → LIVE 28

Two phases. One hypothesis tested before you invest in the rest.

1. Week 1

   • Core job

   • auth
   • onboarding
   • primary job
   • happy path

2. Week 2

   • Core job
   • Usable slice demo

   • real user flow on staging

3. Week 3

   • Hardening
   • Payments
   • Telemetry

   • checkout
   • logs
   • empty/error states

4. Week 4

   • Hardening
   • Payments
   • Telemetry

   • backups
   • deploy
   • live on production

1. day 0 · kickoff
2. day 14 · core live
3. day 21 · payments
4. day 28 · live

Scope contract — written before code

mustShip vs deferred is agreed on day 0. A week-three “quick add” becomes a new product, not a tweak.

The problem we solve: waiting six months to learn one thing

A common path looks like this: plan for a month, build a full roadmap for three, polish for two, then show it to a user. If the core job is wrong, you paid for four months of detail before the first real test.

We flip that. We agree on one primary job, ship the thinnest slice that lets a stranger complete it, and learn on real infrastructure.

If you need three sentences to name the primary job, you have three products. That clarity is what makes 14 days possible.

We use the same scope contract from our MVP checklist — mustShip vs deferred — and we run it as a written decision, not a Slack thread.

---

Our 14/28 split — what each phase is for

Phase	Outcome	What we optimize for
Days 0–14 · Core	A usable slice on staging that a stranger can complete without a walkthrough	Learning — does the job map to real workflow?
Days 15–28 · Harden & Live	A product on production that handles money, errors, and return visits	Trust — will someone pay and come back?

Day 14 is not a Figma prototype. It is working software on staging with real auth and a real path through the core job.

Day 28 is not “add more features.” It is the same slice with the parts that make it production-ready.

We keep one product at a time and work principal-led so scope doesn’t quietly grow between demos.

---

Days 0–14: what we build in weeks 1–2

Weeks 1 and 2 are intentionally boring in the right way.

We build:

• One primary user and one primary job — named in a single sentence
• Auth and onboarding that lets us test retention (you cannot test return visits without identity)
• The shortest path that completes the job — not the admin surface, not the third CRM integration
• A usable slice demo at the end of week 2 that a stranger can finish

What we deliberately leave out of this window: custom roles, themes, subdomains, deep analytics, and AI that doesn’t change whether the core job gets finished.

This is the same discipline that shaped Ankik — we did not need every report on day one; we needed a ledger path people would use instead of the notebook.

If the core job is not complete on staging by day 14, the scope was too big. We cut, not add.

---

Days 15–28: hardening, payments, telemetry

This is where MVPs usually fail quietly. The demo works, but the first real user hits an empty state with no guidance, a payment retry with no clarity, or a backup story that was never tested.

We harden:

• Payments and checkout where money is involved — Stripe integration, receipts, and the paths for failure and retry
• Telemetry and admin so we can answer “what happened for this user?” without guessing
• Empty, loading, success, failure, and permission-denied states on every shipped path
• Backups, secrets, CI, and a deploy path that is not FTP — the short list we treat as non-optional

We also add logging enough to trace a single user’s journey and alerts that tell us if the core job breaks.

This is why our invisible engineering work matters more than animation budgets on secondary screens.

---

Why foundations are not optional

“We’ll harden it after we get users” sounds rational until the first users are the ones who find the holes.

We treat a short list as part of the MVP itself:

• Backups and a restore story we have practiced once
• Secrets out of the repo
• CI that runs on every change
• A deploy path we trust

These do not need a platform team. They need a decision to not call a fragile demo an MVP.

We use the same bar described in our scope pruning guide — if a state has no design, the feature is not ready to ship.

---

The scope contract — written before code

On day 0 we write the contract:

export const mvpScopeCutList = {
  mustShip: [
    "Auth and onboarding",
    "Primary job execution",
    "Checkout where money moves",
    "Telemetry and deploy health",
  ],
  deferredForV2: [
    "Complex roles",
    "Custom themes",
    "Subdomains",
    "Deep analytics",
  ],
} as const;

The contract has two owners and a renewal point at day 14. If someone wants to add scope in week two, the question is not “is this a good idea?” It is “what leaves the mustShip list to make room?”

This is how we keep a Build Sprint from becoming an agency timeline with AI hype added.

---

What you get at day 14 and day 28

At day 14 you have a slice you can test with a stranger. At day 28 you have a product a user can pay for and return to.

Both are built principal-led, AI-native in the seat (we use models where they remove real friction, not where they demo well), and measured by usable paths, not slide updates.

If you want to see how we price that scope, read our MVP cost breakdown. If you want the practical template, use the scope pruning guide.

FAQ — MVP development timeline

What is the MVP development timeline at Emiote? Core usable on staging in 14 days, hardened live in 28. Days 0–14 prove the primary job; days 15–28 harden payments, five states, backups, and deploy.

What do you ship by day 14? Working software on staging — real auth, the shortest path to complete the primary job, and a demo a stranger can finish without a walkthrough. Not a Figma prototype.

Why does hardening take another 14 days? The demo path fails where money and trust are on the line — empty states, payment retries, telemetry, and restore story. That is where MVPs quietly fail if skipped.

Ready to ship? Ship a Core Strangers Can Finish in 14 Days — we take one product at a time and keep accountability in the studio.