Ship It Broken

The audit tool that now powers my Local Growth Fix offer — the thing that tears down a local business website, writes the teardown, and generates a branded PDF — I built the first version in a single night.

It was ugly. The PDF formatting was janky. The AI teardown sometimes hallucinated sections. The intake page had no styling. I showed it to exactly one person, got the feedback, fixed the worst parts, and put up a public intake link the next day.

Within a week it had generated real teardowns for real prospects. Within two weeks it had a payment link attached. The version running now looks nothing like that first night's build — but that first night's build is the reason any of it exists.

Speed is a strategy. Not a personality trait. A strategy.

---

Here's what people get wrong about shipping fast. They think it means shipping sloppy. It doesn't. It means shipping narrow.

The first version of the audit tool did exactly one thing: take a URL, run deterministic checks, and produce a readable teardown. It didn't have user accounts. It didn't have a prospect database. It didn't have outreach sequencing — that came later, in the second build session. It did the one thing that proved the concept, and it did it in public where I could watch what broke.

Sloppy is shipping something you don't understand. Narrow is shipping the smallest thing you fully understand and letting reality tell you what's next.

Most people do the opposite. They build the whole system in private — auth, database, admin panel, twelve features — and then discover in week six that the core assumption was wrong. They spent a month building scaffolding around a thing nobody wanted.

I've watched this movie too many times. The planning phase feels like progress. It's usually procrastination with a Gantt chart.

---

The rule I actually follow:

Build the smallest version that can fail in public. Not fail catastrophically — fail informatively. You want the kind of failure that teaches you something: the teardown format nobody reads, the intake page nobody finishes, the feature nobody clicks.

Then fix only what the failure taught you. Not what you imagined might break. What actually broke, in front of real users, with real evidence.

This is the opposite of "move fast and break things." That slogan was always stupid. The real version is: move fast and learn things. Breaking is just the tuition.

---

What this looks like in practice.

When I built the Muse Vault — 98 templates, submission form, trending, ratings — the first version was a static page with copy buttons. That's it. No accounts. No submissions. No ratings. Just: here's the thing, copy what you want.

People used it. Then they asked for collections. Then submissions. Each feature came from someone asking, not from me imagining. The roadmap wrote itself because the thing was alive in public instead of perfect in private.

Same with the outreach sequencing on the audit tool. I didn't build "Generate first-touch draft" on day one. I built the teardown, watched myself manually writing follow-ups from teardowns, and realized the pattern was automatable. The feature emerged from the workflow. That's always the order: workflow first, automation second. Automating something you haven't done manually is how you build expensive garbage.

---

The objection I always hear:

"But what about quality? What about your reputation?"

Here's the truth: nobody remembers your v1. They remember whether you kept going. The people who judge you for shipping something rough aren't your users — they're spectators. Your users are too busy using the thing to care that the PDF margins were off in week one.

And "reputation" from never shipping is worth exactly nothing. A portfolio of shipped, imperfect, real things beats a portfolio of perfect ideas every time. I've hired people. I've been hired. Nobody ever asked me about the thing I almost built.

---

The line.

Shipping fast doesn't mean shipping things that don't work. It means shipping things that work narrowly and expanding based on evidence. The discipline isn't in the speed — it's in the scope. Ruthless scope. One thing, working, in public.

If you're sitting on something right now — a tool, a post, a product, an offer — and the reason it isn't live is that it's not ready: ask yourself what "ready" actually means. Usually it means "I'm afraid of what happens when real people see it."

Ship it broken. Fix it live. That's not a compromise. That's the whole game.