Ship it at sixty percent

I once spent five weeks on a settings page. Timezone handling, granular notification preferences, an audit log of who changed what. It was good work.

In the eighteen months after launch, four people opened that page. Two of them were me.

Meanwhile the thing every single customer asked for in the first fortnight — being able to forward submissions to a second email address — took two hours and I had not thought of it once.

The part people get wrong about “ship early”

The advice usually arrives as a slogan about perfectionism, which makes it easy to dismiss and easy to misapply. The actual claim is narrower and more useful:

You cannot know which forty percent matters until real people use the first sixty.

It is not that polish is bad. It is that polish applied before you know where the pressure falls is polish applied to the wrong surfaces. I did not build the wrong settings page badly. I built the wrong settings page beautifully.

What the sixty percent has to include

This is where the slogan does damage if you stop reading. Sixty percent does not mean sixty percent of the quality. It means sixty percent of the scope, at full quality.

Non-negotiable, always:

• It does the main thing correctly. Not most of the time. If your product’s one job is receiving form submissions, losing one is fatal in a way that a missing settings page never is.
• It does not lose data. Ever. This is the one failure people do not forgive and do not come back from.
• It is secure. Auth, rate limits, no injectable inputs. “We will harden it later” is how you get an incident post to write instead of a product.
• You can tell when it breaks. Errors reach you, not the customer’s imagination.
• Someone can pay you. A thing nobody can buy teaches you much less than you think.

Everything outside that list is negotiable and most of it should be negotiated away for version one.

What I now cut by default

Settings. Pick a sensible default. Every setting is a fork in your support answers, your tests, and your future self’s understanding of the code. Add one when three customers ask for it, and not on the second.

Onboarding flows. Before you have users, you do not know where they get stuck. Ship the product and answer the emails; those emails are the onboarding spec, written by the people who needed it.

Admin panels. A database client and a few SQL snippets will do for a long time. I have built admin interfaces for products that never reached a hundred customers, and the interface took longer than the product.

Integrations beyond the first. Build the one integration your first ten customers name. The rest are a roadmap item, not version one.

Anything with the word “advanced” in the label. It is a reliable marker for a feature built from imagination rather than from a request.

The habit that makes this work

Shipping at sixty percent only works if you actually close the loop. Otherwise it is just shipping less.

What I do: every time a customer asks for something, it goes in a single file with the date and their name. No triage, no board, no estimates. Just the list.

Once a fortnight I read it. The thing that appears four times is the next thing I build. The thing I was personally excited about, that nobody has mentioned, waits — and about half the time I quietly stop wanting it, which is information too.

That file is the best product tool I have ever used, and it is a text file.

The counter-argument, which is real

This does not apply to everything, and pretending otherwise is how people get hurt.

Client work is different. A client is paying for a specification, and “I shipped sixty percent and I will learn the rest” is not a thing you can invoice. What transfers is the shape: ship the core early, show it, let them tell you what the remaining forty is.

Anything that has to be right the first time. Payments, payroll, health, anything regulated, anything where a bad first impression is permanent. Some products only get one launch.

Established products. Sixty percent works when the alternative is nothing. When customers already rely on a thing that works, half-finished changes are not learning, they are a regression.

What five weeks of settings page taught me

Not that I should work faster. I work at about the same speed.

It taught me to ask, before starting anything that will take more than a couple of days: who asked for this, and what happens if I ship without it?

If the honest answer is “nobody” and “nothing”, that is not a feature. It is a way of avoiding the part of the job where you have to show something to a stranger and find out what they think.

That part is uncomfortable, it is the only part that generates real information, and no amount of good work on a settings page is a substitute for it.