Build the Ugly Version First

Every stalled internal project started the same way. Somebody scoped the proper version, the one that handles every case and looks the way it should, and nine months later it is at eighty percent and has been at eighty percent since October.

The alternative is not lowering your standards. It is changing the order.

Why the complete version fails

MIT’s Project NANDA published The GenAI Divide in July 2025, reviewing over 300 disclosed AI initiatives. Against an estimated $30 to $40 billion of investment, roughly 95% of generative AI projects produced no measurable return.

Their study covers large organisations rather than businesses your size, and no measurable return frequently means nobody built a way to measure. Both caveats matter. What the number tells you is that failure clusters before anything reaches real work, not in the technology.

A build scoped to handle everything guarantees a long gap between starting and anybody using it, and everything that kills projects lives in that gap. Priorities move, the person who wanted it leaves, a budget cycle turns, and the requirements that were agreed in March stop describing the business by November.

The ugly version has one job

It handles the most common case, badly, in production, with real work going through it.

No interface to speak of. No handling of the awkward exceptions. No configuration screen. It does the thing that happens forty times a day and refuses everything else, loudly, to a named person.

That is not a prototype and it is not a pilot. Real work goes through it and the old route gets switched off for the cases it covers. The distinction matters, because a demonstration teaches you nothing and a system in use teaches you everything.

What three weeks of live use tells you

Things no specification meeting ever produces.

Which exceptions are actually common. Everybody in the scoping meeting names the dramatic edge case. Almost nobody mentions the boring variation that turns out to be a third of the volume, because it is so normal that it does not register as an exception.

Where people go around it. The most valuable signal available, and it is invisible in any process map. If somebody quietly reverts to the old way on Thursdays, that is a finding worth more than a month of analysis.

Whether the problem was worth solving. Occasionally the honest answer after three weeks is that the process should have been removed rather than automated. Finding that out for three weeks of effort instead of nine months is an excellent outcome, though nobody ever presents it as one.

What good looks like here. Accuracy targets set in advance are guesses. Three weeks of live disagreements between the system and the person tell you where the line actually needs to be.

What ugly is not allowed to mean

This is where the approach gets misused, so the boundaries are worth stating.

Ugly means missing features, a plain interface and a narrow scope. It does not mean wrong answers, silent failures or no record of what happened. Those are not shortcuts, they are the things that make people distrust the whole idea, and one bad incident sets a business back a year.

Three things are non negotiable even in the first version. It writes into the system where the work actually happens, so nobody carries data by hand. It fails loudly to a named person rather than quietly. And it records what it did, so a disputed result can be reconstructed rather than argued about.

Everything else can wait.

The objection, and the honest answer

The reasonable worry is that ugly becomes permanent. It happens, and the reason is always the same: nothing was scheduled to follow it.

The fix is to book the second phase before the first one ships, with a date and a named owner, and to treat the three weeks of live use as its specification rather than as a decision point about whether to continue.

There is a version of permanent that is fine, though. If the ugly one covers eighty percent of the volume, saves the hours, and nobody minds how it looks, leaving it alone is a legitimate outcome. The failure is not that it stayed simple. It is when the remaining twenty percent quietly stays manual forever and nobody ever decided that.

How to sell this internally

The approach fails politically more often than technically, because a three week ugly build is easy to characterise as not taking the problem seriously.

Two framings that work. Call it the first phase rather than a trial, with the second phase already dated, so nobody hears it as a hedge. And be explicit that the three weeks of live use is how you find out what the full version should contain, which is true and which most people accept immediately once it is said out loud.

Avoid the word pilot entirely. It signals reversibility, and reversibility is what makes people build it half connected to nothing, which is the failure this whole approach exists to avoid.

Why AI makes this cheaper than it used to be

Three weeks was not a realistic scope for a useful system until fairly recently, and the reason is worth understanding.

Most of what took time in a small build was handling variation in the input: every format a document might arrive in, every way a person might phrase a request, every layout a supplier might use. That was rules, and rules for messy input are effectively unbounded work.

An AI step absorbs the variation directly, so a build that once needed months of edge case handling before it could touch real work now needs a fraction of it. That is what makes the ugly version genuinely useful on day one rather than a toy.

How to scope one

• Pick the single most common case and write it in one sentence. If that sentence needs an and, the scope is already too big.

• Cap it at three weeks. The cap is the design constraint, not an estimate. Anything that will not fit gets cut rather than extended.

• Write down the one number it should move, and record where that number stands today.

• Name who it escalates to when it refuses. A system with no named person behind it will be abandoned the first time it stops.

• Book the review for week four, in the diary, before anybody starts building.

Businesses that work this way tend to have four or five systems running within a year. Businesses that scope the complete version tend to have one at eighty percent, and have concluded from that experience that this sort of thing does not work for them.

Sources

• Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, MIT Project NANDA, July 2025.

AI Optimize builds the narrow version that goes into real work in weeks, then uses what it learns to scope the rest. That work sits under Custom Software.