Most MVPs die in planning, not in code
· Cash Maddock
The invoicing system drafts the week's invoices every Friday. I approve them. Nobody types anything. It's one of the smallest things I've shipped and one of the few I use every week, and that's because I cut everything else out of it. No client portal. No PDF theme editor. No multi-currency. One job, on a schedule, with a human approving the send.
I've shipped around 50 products: a mobile-detailing booking platform, a Chrome ad blocker, a lead-generation engine, client MVPs, and FlowDeck, the order flow terminal I trade on. Writing the code never decided whether any of them went live.
The ones that died, died in a document
Feature lists. User personas. A database schema for a product nobody had used yet. Planning feels like work and produces nothing you can open in a browser. Something broken on screen tells you more than any doc does.
The plan is one sentence now: what this does, for whom, on the first day it's live. The invoicing system was "draft this week's invoices Friday so I approve instead of write." The booking platform was "a customer picks a time and pays without calling anyone." If the sentence needs an "and," that's two products and I build one of them.
Cut until it hurts, then ship it ugly
Every feature sounds reasonable on its own, which is why lists only grow. The question that kills features isn't "is this good?" It's "does the first customer hit this on day one?" Almost nothing does.
The detailing booking platform went live without an admin dashboard, without a rebooking flow, and with email templates I would not show anyone. It had a calendar, a price, and a payment. Real bookings came through it. The two weeks of polish I would have done before launch, I did after. Most of that list I never built at all, because nobody asked for it.
You can restyle a working product in an afternoon. You can't get back the month you spent polishing something that never took a payment.
The demo is the easy 80 percent
Billing, auth, and error states are the other 20 percent, and they eat most of the calendar.
FlowDeck is the clearest example I have. The heatmap DOM and footprint charts looked finished fast on replayed data. Closed beta meant something else: connecting live accounts through Rithmic and Tradovate, deciding what the tape shows when a feed drops mid-session, handling the reconnect, gating the waitlist. None of that is in the screenshot. All of it is why anyone can actually use the thing. I trade ES and NQ on it every morning, so I hit those failures before a beta user does.
When I tell a client the MVP ships in weeks, most of those weeks are that half.
AI compresses the build loop, not the decisions
Claude Code is my development team. That's how one person ships an ad blocker, a lead-generation engine, and a futures terminal without hiring anyone. It collapses the distance between "I should try this" and watching it run, so I throw away three approaches in the time it used to take to commit to one.
It won't tell me what to cut. It'll build the client portal the invoicing system doesn't need, and build it well. The old failure mode was building the wrong thing slowly. The new one is building more of the wrong thing fast. The scope call is still mine, and it's still what decides whether the project ships.
That's why I take two build clients a month. Two is the number where each one still ships in weeks, because that pace needs cut decisions daily and no context-switching across five projects.
What I'd change
Cut one more feature than feels safe. Every time I've done it, the launch came sooner and the removed feature turned out to be optional. Every time I kept it, I was protecting the part that made the product impressive to me, not the part that made it useful to somebody else.
Ship the ugly version. Charge for it. Then decide what's next from what people do with it, not from what a planning doc predicted they'd do.
Building something and want it live in weeks instead of quarters? Book a call.