MVP & launch mechanics

An MVP isn't a tiny version of everything — it's the one thing worth shipping, done well enough that someone would pay or come back. Scope it ruthlessly, then actually get it out the door, because an unlaunched app teaches you nothing.

Find the one thing

Write your product idea as a single sentence: "It helps [who] do [what]." The MVP is the shortest path to delivering that core promise — everything else is later.

• Cut to the spine. Settings pages, dark mode, onboarding tours, team accounts, integrations — none of it matters if the core isn't useful. Build the core; fake or defer the rest.
• One persona, one job. Serving "everyone" means serving no one well. Pick the user you understand best.
• The 80/20 of features. Most value comes from one or two features. Ship those; leave the rest as a list.

A useful gut check fitting this product's doctrine: is it fun/valuable with 10 users? If your MVP only works once you have thousands of people, it's not an MVP — it's a bet you can't yet afford.

Fake the hard parts

You don't have to build everything you ship. Early on, the goal is learning, not engineering elegance.

• Manual back end ("Wizard of Oz"). Do the work by hand behind a clean front end. If users love the result, then automate it.
• No-code glue. A form + a spreadsheet + an email can stand in for a feature until demand proves it's worth real code.
• Hardcode before you generalize. One hardcoded example beats a configurable system nobody's asked for yet.

Set a launch deadline and defend it

Scope creep is the number one reason indie apps never launch. The fix is a hard date plus a frozen list.

1. Write the MVP feature list. Then delete a third of it.
2. Put everything you cut into a "later" list — this kills the urge to sneak it back in.
3. Pick a launch date two to four weeks out and treat it as real.
4. When a new idea appears mid-build, it goes on the "later" list, not into this build.

"Done" means a user can complete the core job end to end. It does not mean perfect.

Get it out the door

Launching isn't one big event — it's a sequence, and you can do several:

• Soft launch: ship to a small group (a Discord, a few beta users, a private channel) and watch real usage before you make noise.
• Public launch: then post where your users are — communities, the success feed, relevant forums, Product Hunt if it fits.
• Have the basics live: a privacy policy, a way to pay (if paid), a way to contact you, and analytics so you can see what happens.

Don't wait for a "big" launch. Tell people now, fix fast, launch again. Repeat launches beat one perfect launch.

Instrument from day one

You launched to learn, so make sure you can. Before you ship:

• Wire up product analytics (PostHog or similar) for signup, activation, and the core action.
• Define activation — the moment a user first gets value — and watch how many reach it.
• Add an error tracker so you hear about crashes from logs, not angry users.

If you can't see whether people reach the core action, you're flying blind.

After launch: listen, then iterate

• Talk to your first ten users directly. Their confusion is your roadmap.
• Watch where people drop off and fix that one step.
• Resist building the cut features until usage data — not your gut — asks for them.

Ship-ready when

• You can state the core promise in one sentence.
• The build delivers that promise end to end for one persona.
• A third of the original scope is on a "later" list, not in this build.
• A launch date is set and defended.
• Analytics, error tracking, privacy policy, and (if paid) payments are live.
• You know your activation moment and can measure it.