Startup MVP

How We'd Run It

The same six steps, applied to this project

1. 1

   Diagnose

   We sit down with the founder to pressure-test the idea into one buildable core flow, and name the single metric (signups, activations, a completed key action) that decides if the MVP is working.

2. 2

   Pilot

   We build a thin, fixed-fee slice of that core flow first — enough to put in front of 5-10 real users — rather than a full feature set.

3. 3

   Review, Together

   We watch real users hit the pilot flow with you, walk through where they got stuck or delighted, and agree together whether it's worth building out.

4. 4

   Build

   We harden the pilot into a real product: proper auth, data model, hosting, and the supporting screens the core flow depends on.

5. 5

   Launch, With a Human on Every Send

   We ship to an initial cohort with a human watching signups and errors closely, rather than a silent public launch.

6. 6

   Operate & Improve

   We monitor usage and stability post-launch and hold a standing block of time to iterate on what the first real users do.

Typical Timeline

A rough phase-by-phase breakdown

A target shape for a project like this, not a narrated account of a specific past engagement — actual pacing depends on scope and how quickly decisions get made.

1. 1

   Diagnose & Scope

   Early Week 1

   Pressure-test the idea into one buildable core flow and agree on the single metric that decides if the MVP is working.

2. 2

   Pilot Build

   Week 1

   Build a thin, fixed-fee slice of the core flow to put in front of 5-10 real users.

3. 3

   Review Together

   End of Week 1

   Watch real users hit the pilot with you and agree whether it's worth building out.

4. 4

   Full Build

   Week 2

   Harden the pilot into a real product: proper auth, data model, hosting, and supporting screens.

5. 5

   Launch

   End of Week 2

   Ship to the first cohort with a human watching signups and errors closely, not a silent public release.

6. 6

   Operate

   Ongoing from Week 2

   Monitor usage and stability, and hold a standing block of time to iterate on what real users do.

What's Included

What an engagement like this covers

• Founder working sessions to pressure-test the idea into one buildable core flow

• A fixed-fee pilot slice of that flow, tested live with 5-10 real users

• Production-grade auth, data model, and hosting once the pilot earns it

• The supporting screens the core flow depends on, not just the happy path

• A monitored launch to a first user cohort, not a silent public release

• A standing block of post-launch time to iterate on real usage

Where Projects Like This Go Wrong

Common pitfalls, and how we handle them

• Trying to build every feature on the roadmap before anyone outside the founding team has touched the product

• Skipping real user testing in favor of internal opinion, so the first outside feedback arrives after launch instead of before

• Under-scoping auth, billing, and data ownership early, then having to retrofit them once real users sign up

Targets, Not Results

What we consider success

These are the targets we'd work toward on a project like this — not results we're claiming to have already achieved.

• A working product a first cohort of real users can sign up for and use without hand-holding

• A core flow (signup through the product's main action) that's been watched and tested with real users, not just demoed internally

• A codebase and infrastructure setup the founder can hand to a future hire without a rewrite