# You Don't Have an Idea Problem. You Have a Shipping Problem.

*The last 10% of any project takes 90% of the energy. It is killing your ship date.*

# You Don't Have an Idea Problem. You Have a Shipping Problem.

*The last 10% of any project takes 90% of the energy. It is killing your ship date.*

![[HERO] You Don't Have an Idea Problem. You Have a Shipping Problem.](https://cdn.marblism.com/o6oKDbhdOvQ.webp)

Look at your project right now.

The features list is mostly checked. The Figma file has stopped collecting comments. The codebase is at the point where you've started saying "it's basically done." The landing page exists, even if you haven't written the headline yet. You can describe what the thing is and who it's for in two sentences without having to think.

You've been "two weeks away from launching" for nine weeks.

It's not the work. The work is mostly done. It's the last 10%.

You don't have an idea problem. You don't have a capacity problem. You have a shipping problem, and the shipping problem is the most studied, best-named, oldest disease in software, and the only reason it's still killing you is that nobody told you it was a real thing with a real name.

## Tom Cargill named it in 1985

In September of 1985, Bell Labs programmer Tom Cargill said something to his colleague Jon Bentley that Bentley wrote down and published in his "Programming Pearls" column in *Communications of the ACM*.

It went like this.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."

Read that twice. The math doesn't work, and that's the whole joke. The first 90% of the work takes 90% of the time. The last 10% takes 90% *more* time. The total project always ends up running 180% of what you originally estimated.

Cargill's law has held up for 40 years across every codebase, every product launch, every renovation, every dissertation, every album, every novel, and every side project. The reason isn't that programmers are bad at estimating. The reason is that the last 10% is structurally different work than the first 90%.

The first 90% is creative work. You're building. You're inventing. The work generates its own momentum because every step adds a thing to the pile.

The last 10% is finishing work. You're testing. You're polishing. You're choosing between two almost-identical buttons. You're writing the help docs nobody will read. You're handling the eight edge cases nobody warned you about. The work has no momentum because every step removes ambiguity instead of adding output, and removing ambiguity feels like nothing.

You're not stalling because you're undisciplined.

You're stalling because the last 10% feels like nothing while it costs everything.

## Hofstadter's Law makes it worse

Six years before Cargill, in 1979, Douglas Hofstadter published *Gödel, Escher, Bach: An Eternal Golden Braid*. It won the Pulitzer. Buried inside chapter five is a self-referential aside that the software industry quietly adopted as gospel.

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

The recursive trap. Even when you know about the trap, you still fall in. You estimate three weeks. You remind yourself that estimates are usually wrong. You add a buffer. You estimate five weeks. It takes nine.

The reason isn't a discipline failure. It's that human brains are wired to estimate the work they can imagine and to ignore the work they can't. The last 10% is mostly work you can't imagine in advance. It's the bug you find at 11pm. It's the integration that breaks because your auth provider changed an endpoint. It's the customer who tries something nobody planned for. You can't budget for the work you don't know about, and the last 10% is mostly that work.

You don't need a better Gantt chart.

You need a different relationship with the last 10%.

![Minimalist stick figure pushing a project toward a drifting finish line, illustrating a shipping problem.](https://cdn.marblism.com/yyveMzpffns.webp)

## What Toyota figured out

In 1948, a Toyota plant manager named Taiichi Ohno started developing what became the Toyota Production System. By the 1960s, the system was the most copied operating model in industrial history. By 1988 Ohno had written the book that finally explained it in English.

The most famous part of the system is a piece of physical infrastructure called the andon cord. It runs along the assembly line, within reach of every worker. When something goes wrong — a bolt that won't seat, a part that arrived warped, a defect a worker can see but not yet name — any worker can pull the cord. The line stops. A team gathers. The defect is fixed at the source. Then the line restarts.

The genius of the andon cord wasn't the cord. It was the rule that made the cord work. At a Toyota plant, you cannot move a defect to the next station. You cannot promise to fix it later. You cannot patch it after the fact. The defect has to be fixed where it shows up, in the workflow that produced it, while the line is stopped.

In every other car factory in the world, defects flowed downstream. Workers found problems and didn't say anything because stopping the line cost the line manager money. The defects accumulated at the end of the line, in a giant rework pen, where finishing a single car took longer than building it had taken in the first place.

Sound familiar.

You are running a non-Toyota assembly line on your project. You're letting defects flow downstream. The half-broken Stripe webhook. The broken email confirmation. The button that does nothing in Safari. The pricing page that says "$49" in one place and "$48" in another. They've all been "fix later" for weeks because, individually, they don't feel urgent. Collectively, they're the last 10%.

You don't have a focus problem. You have an andon-cord problem. There's no rule in your operating model that says "stop the line and fix it where it lives." So everything piles up at the end and you wonder why finishing feels impossible.

## Three moves that actually solve a shipping problem

You don't fix this with motivation. You fix it with infrastructure that takes the last 10% seriously.

**1. Build a launch-blocker list, not a feature list.** Most founders are still tracking what they want to add. They should be tracking what's blocking shipping. Open a doc. Write down only the things that, if not fixed, would make you not ship. There are usually 8-15. Most are smaller than they feel. The list itself drops 30% of the work because half of what's "blocking you" turns out to be polish you don't actually need.

**2. Apply scope lock at the 90% mark.** This is the move most founders skip. When the project hits 90% complete, the rule should be: nothing new gets added. Not by you. Not by your designer. Not by your wife who has a great idea on Saturday morning. The Scope Guillotine doesn't just exist for week one. It exists doubly for the last 10%. New ideas don't go in the project. They go on a separate doc called "V1.1." This isn't being rigid. This is being shippable.

**3. Schedule a launch date that's earlier than feels comfortable.** Pick a date 3-4 weeks out. Tell three people. Put it in your calendar. Watch what happens. The last 10% expands to fill whatever time you give it. If you give it six months, it takes six months. If you give it 21 days, it takes 21 days, because you cut the polish you didn't actually need. This is Reid Hoffman's old line — if you're not embarrassed by your first version, you launched too late — applied to the calendar instead of the feature list.

If you can't tell which of those three is the move you need, that's actually useful diagnostic data. [Take the quiz.](https://www.unstuckwithmolly.com/quiz) The four stuck patterns it surfaces — Overcommitter, Perfectionist, Burnout Cycler, Scattered Starter — each map to a different last-10% failure mode. Knowing which one you're running is half the work.

![Forklift lifting strategic intent while clearing away talk, representing technical strategy delivery.](https://cdn.marblism.com/3JiSybWsltH.webp)

## What a build partnership actually solves

You can do all three of those moves alone. Most senior founders won't, and the reason isn't laziness.

The reason is that the last 10% is the part of the work where there is no positive feedback loop. The first 90% generated dopamine — features got built, things got prettier, the demo got better. The last 10% generates almost no dopamine. Edge cases don't feel like progress. Polish feels like wheel-spinning. The launch-blocker list shrinks slowly and then suddenly, and the slowly part is where most projects die.

A build partnership exists for that part. The job is to be the second voice that pulls the andon cord. To say "this is a defect, fix it at source, don't pass it downstream." To say "no, that idea is V1.1, don't add it." To say "the launch date is two weeks from Friday, write it down, tell three people."

That's [The Build Partnership](https://www.unstuckwithmolly.com/work-with-me/build-partnership).

It is not coaching. It is not a productivity system. It is the operating discipline of an assembly line, applied for six weeks, to the project you've been "almost done" with for nine.

## The reframe

You don't have an idea problem.

You don't have a capacity problem.

You don't have a discipline problem.

You have a last-10% problem, and the last 10% has been a documented disease since 1985, and the only thing that ever solves it is operating infrastructure that treats finishing as a different category of work than building.

Pick the launch date. Build the launch-blocker list. Stop adding. Pull the cord on the next defect that shows up.

Ship the worse version. Update it on Monday.

That's how it ends.

![Transition from chaotic yarn to a clean spool, symbolizing strategic delivery and clarity.](https://cdn.marblism.com/QcFWN-k97pA.webp)

## Sources

- [Jon Bentley, "Programming Pearls: Bumper-Sticker Computer Science" (Communications of the ACM, Sept 1985)](https://dl.acm.org/doi/10.1145/4284.315122) — the original printing of Tom Cargill's 90-90 rule
- [Douglas Hofstadter, *Gödel, Escher, Bach: An Eternal Golden Braid* (1979)](https://www.basicbooks.com/titles/douglas-r-hofstadter/godel-escher-bach/9780465026562/) — chapter 5, Hofstadter's Law in its original context
- [Taiichi Ohno, *Toyota Production System: Beyond Large-Scale Production* (1988)](https://www.routledge.com/Toyota-Production-System-Beyond-Large-Scale-Production/Ohno/p/book/9780915299140) — the andon cord and the stop-the-line principle, in Ohno's own words

## About the Author

Molly Shelestak is a Build Partner for Side-Project Shippers. With 20+ years in tech — from Google to Heap to Contentsquare — she helps senior tech employees stop tinkering and actually ship their side projects in 6 weeks.

## Related

- [The V1 Manifesto](https://www.unstuckwithmolly.com/writing/v1-manifesto)
- [The Embarrassment Test](https://www.unstuckwithmolly.com/writing/embarrassment-test)
- [Decision Debt Is Why You're Tired](https://www.unstuckwithmolly.com/writing/decision-debt)
- [Work With Me](https://www.unstuckwithmolly.com/work-with-me)