Finishing is a separate skill
AI made starting free. It did not make finishing any easier — so people start more and finish less. What actually raises the odds a project reaches real users.
Ask around and you will find the same pattern everywhere: folders full of projects that got to "almost". A working prototype. A repo that was exciting for eleven days. Something that only runs on one laptop.
This is not a discipline problem. It is what happens when the cost of starting collapses and the cost of finishing does not move at all.
Starting became free. Finishing did not.
An AI assistant will give you a working first screen in an afternoon. That is genuinely new, and it is wonderful.
But nothing about that makes the last stretch cheaper. Someone still has to decide what happens when a payment is declined. Someone still has to write the privacy page, buy the domain, set up the backups, and answer the first confused email. The assistant does not want that work either.
So the ratio shifts. You start five things in the time you used to start one, and you still only have the appetite to finish one. Four folders go quiet. It feels like failure. It is arithmetic.
The 90% that lies to you
Here is the trap specific to building this way: the feeling of progress arrives before the progress does.
In a day you have something that looks finished. Screens, navigation, plausible data. Your brain files the project under "nearly done" and quietly withdraws the motivation it was going to spend on the rest.
Then comes the actual remainder — empty states, error messages, the deploy, the domain, the thing that has to work when the network drops — and it takes weeks. Not because you are slow, but because that part was never the part AI compressed. I wrote separately about what lives in that last stretch technically, in going live is the hard part.
The demo is the appetiser. It is not evidence that dinner is nearly ready.
The end is boring by design
Be honest about why the last 10% stalls: it is the least interesting work in the project, and it arrives exactly when the novelty has worn off.
Nobody starts a project excited about cookie banners, transactional email, or checking that the backup restores. Those tasks are not hard. They are just charmless, and they have no dopamine attached. An assistant that made the fun part faster has, in effect, concentrated the boring part into a denser block at the end.
If you know that is coming, you can plan around it. If you do not, you will read it as losing interest and start something else.
What actually raises your completion rate
Six things, in the order I would apply them.
1. Deploy on day one, while it is still embarrassing. Put the empty shell on a real domain, over HTTPS, before it does anything useful. Then "finishing" stops being a cliff at the end and becomes something you already do every day. Projects that only ever run on localhost develop a kind of gravity — they never leave.
2. Write what "done" means in one sentence you can test. Not "a booking system". Rather: "a stranger can book a slot, pay, and get a confirmation email, without me touching anything." One sentence, verifiable, decided while you are still enthusiastic and honest.
3. One project on the runway at a time. Explore as many as you like — spikes are cheap and that is the point. But only one may be in the phase of going live. That phase needs sustained, unglamorous attention, and you only have one of those.
4. Keep a "not now" list, and put things on it with relief. Every good idea mid-build moves the finish line further away. Writing it down is not a rejection; it is how the current version gets to exist. With AI the danger is sharper than ever, because adding a feature is so cheap to ask for that you stop noticing you are pushing the ending away.
5. Count what is left in tasks, never in percent. "Eighty percent done" is a feeling. "Nine things left, here they are" is a plan. A percentage can sit at 90% for a month. A list of nine gets shorter.
6. Write the boring list at the start, not at the end. On day one, while the project is still fun, list everything unglamorous it will need to be real. Domain, certificate, legal pages, where the data lives, what happens when the form fails, who gets told when it breaks. You will not do it then — but when you arrive, it will be a list to work through rather than a wall of unpleasant surprises.
The list itself
That last one is worth making concrete, because "the boring stuff" is vague and vagueness is what stalls people. For anything that goes on the internet and takes messages or money, it is roughly this:
| Thing | Question it answers |
|---|---|
| Domain and certificate | Does it look like a real business? |
| Somewhere to run | Does it survive a reboot without you? |
| The form or checkout, tested when it fails | Does a message ever get silently lost? |
| Somebody told when a message arrives | Will you find out today, or in November? |
| Backups of what cannot be rebuilt | And has one ever been restored? |
| An alert when it stops answering | Or does a customer tell you? |
| Legal pages, if you are in the EU | Is this even allowed? |
| Indexing, analytics | Does anyone know it exists? |
Eight lines. None of it clever, all of it the difference between a project and a product. It is also, conveniently, a decent definition of done.
If someone else is building it for you
The same pattern shows up in paid work, wearing a suit. A build looks nearly complete for a long time, and the last stretch is where budgets quietly overrun and handovers get thin.
Two questions save a lot of grief at the start. What exactly will exist at the end, in one sentence? And which of these eight lines are included, and which are mine to sort out? If the answer to the second one is vague, that is not a detail to sort out later — that is the whole problem arriving early, where you can still do something about it.
Planning something and want it to actually reach users? Start with the indicative quote check, or tell me what you are building.