AI Can Build It in a Week

If someone tells you they built something in a week, ask what they were doing for the two years before that.

I am not being sour about it. Both answers are true at once, and the gap between them is the most useful thing to understand if you are about to commission software with AI mentioned anywhere in the pitch.

For our own product, the first working version took about a month. The product took a couple of years after that, and it is somewhere north of forty thousand lines of code and several hundred rounds of changes. Those two facts describe the same project.

The first 80% did get faster

Building the obvious version of something is much quicker than it was. The groundwork, the parts that every piece of software needs and nobody enjoys writing, the connections between one system and another: all of that has compressed enormously, and anybody telling you otherwise has not been paying attention.

If your idea is a normal thing done normally, you can have a working version fast. What Bespoke Actually Means covers where that stops being enough. That part of the pitch is not a lie.

The last 20% did not move at all

Here is what took the time, and none of it is the part anybody demos.

The work is not making it do the thing. It is making it know when the thing would be wrong.

Three examples from our own build, all of which sound trivial and none of which were.

The hotel that never ended. With back-to-back meetings at one venue, the system worked out there was no travel between them, and then concluded there was no drive home either. The first half of that is right. The second half meant a customer could be booked into a hotel forever, and no one spotted it until one person's Tuesday looked wrong.

The three-week conference in Poole. Two separate monthly visits to the same place got merged into one continuous stay, because the logic that grouped related trips did not know that a gap of four weeks means "twice" rather than "a very long time".

The week that vanished. Sometimes an outside system gives you the wrong answer. Microsoft hands over a long diary in batches rather than all at once, and the way it did that did not match its own instructions. Nothing to do with our software, entirely our problem to solve, and impossible to find except by somebody noticing that one particular week had gone missing.

None of those are hard problems intellectually. All of them are invisible until a real person with a real diary hits them, and every one had to be found, understood, fixed and then guarded against so it could not come back.

Why AI does not compress that half

You can only generate a solution to a problem someone has articulated. The last 20% of software is almost entirely made of problems nobody has articulated yet, because they emerge from real use by real people doing things you did not anticipate.

AI is good at "write me the code that groups related trips". It cannot tell you that your definition of related is wrong for a customer in Poole, because it does not know that customer exists.

That is not a limitation that gets solved by a better model. It is what it means for software to meet the world.

What this means if you are commissioning something

Be pleased when someone shows you a working version quickly. It lowers the cost of finding out whether the idea is any good.

Then ask the different question: what happens between that version and one people can rely on? If the answer is "not much, it is basically done", either the thing is simple, or no one has thought about it yet.

And expect the timeline to be back to front from what feels natural. The part that looks like most of the work takes weeks. The part that looks like tidying up takes months, and it is the part that determines whether anybody trusts the thing in a year.

The boring 20% is the product. The rest is a demo, and the same gap shows up in automation.

If you are weighing up a software project and want a straight read on where the time will go, that is a conversation to have before anybody quotes. Get in touch.