Launching to your first client is not the same as using something yourself. I had a tool finished, tested and ready to hand over this week, and I held it back. Not because it was broken in any way I could point at on a screen. Because of a fault I had been living with quite happily for two weeks.
That gap — between what I tolerate and what a customer would tolerate — is the whole lesson.
The fault I had been living with
The tool is simple. I send it a thought from my phone, it files that thought as an idea, and it asks me one question back so the idea has some meat on it.
It has a flaw. When I send several thoughts in a row, one of the later ones sometimes gets filed as an answer to the earlier question instead of getting a record of its own. Nothing is deleted. The words are still there, sitting inside the wrong record. But the part of the system that later reads those records never sees them, so the idea quietly ceases to exist.
I have known about this for two weeks. It has not cost me anything.
Why the same fault is not the same fault for a client
It has not cost me anything for one reason only: I know it happens, so I go and look.
The client I was about to hand this to is a manufacturer whose manager thinks out loud. He will drop five thoughts in one sitting — which is precisely the pattern that triggers the fault. And he will not go and look, because nobody tells a new tool's user to double-check its filing. He will assume it worked, because it will look like it worked. He will get a friendly reply either way.
So the same code produces two completely different products. For me it is a known quirk with a workaround. For him it is a machine that eats his best idea and smiles.
What does the first week actually decide?
Everything, in my experience. The first week is when a customer decides whether this thing is part of how they work or another app they stopped opening.
You do not get a second first week. If three of his ideas vanish in the first few days, he will not file a bug report — he will just use it less, and then not at all, and when you ask he will say he has been busy. You will never learn why, because the failure was silent on his end too.
That is what made the decision easy. The fix is not large. Waiting for it costs a week. Launching without it risks the only thing that matters.
Three questions before you hand anything to a customer
I now run these before any handover, and they take about ten minutes.
What fails quietly?
Not "what is broken" — what breaks without saying so. A loud error is a good day. Anything that fails while still looking successful is the real danger, because it is invisible to exactly the person who would report it.
Who would notice?
Be honest that you are not a fair test. You know the soft spots, you check the things worth checking, and you have a workaround for everything. Ask instead whether a busy person, using this for the first time, would spot the failure. If the answer is no, it is not a quirk. It is a defect.
What happens if week one goes badly?
Some faults cost an apology. Some cost the relationship. Sort them that way, rather than by how hard they are to fix, and the launch order stops being an argument.
Ship the boring parts while you wait
Holding the launch is not the same as doing nothing. Everything that did not depend on the fix got finished and checked this week: the client's details are loaded and verified, and the check for whether they loaded correctly is now a number I compare rather than a line I hope I notice in passing.
A check that depends on someone being alert is not a check. That was the other lesson of the week, and it cost nothing to fix once it was written down.
The gap between a tool you use and a product you hand over is not features. It is the faults you have quietly agreed to live with.