Why asking for one thing at a time costs more

If you have a budget and no appetite for a big project, the sensible thing to do is ask for the first piece, see how it goes, and add the next thing once you know you need it. That is how most of us buy most things, and most of the time it works fine. Nobody starts a software project by handing over a five-year wish list, and nobody should.

I want to tell you about a project where that instinct, followed by several genuinely reasonable people in a row, quietly made the whole thing cost more than it needed to. It is not a story about anyone being careless.

How it actually went

The work began as a security upgrade to an ageing website for a youth sports club (the system it became is described in the club platform case study). Straightforward enough: bring an old site up to date, close the obvious holes, move on.

Partway in, an existing admin panel came to light, a small one, hand-built, that nobody had thought to mention because it had always just been there. Then a handful of further pages turned out to have been built the same way, one at a time, over the years, by the club's own founder, solving whatever the immediate problem had been at the time.

Once the people taking over running the club got involved, more needs arrived, gradually. Each one was presented as the last one. Each one genuinely was meant that way, by someone trying hard not to overrun their budget or overwhelm the person doing the work. Nobody was stringing anyone along. Everyone involved was being careful, in exactly the way you would want them to be.

What actually happened

Nobody was careless, and nobody was wrong about what they asked for at the time they asked for it. But every early decision was made against a picture of the job that turned out to be a fraction of the real thing. The tools and shortcuts that are the right call for a small security fix are the wrong call for a full membership, payments and scheduling platform, and by the time that was obvious, a fair amount of the system had already been built around the smaller picture.

The result worked. It did what it was supposed to do. But it was harder to maintain, harder to test and harder to reason about than the same effort would have bought if the full shape of the job had been visible from the start. That is my regret to own, not the client's. I should have found out what the whole job looked like sooner than I did.

Why this happens to nearly everyone

Nobody withholds requirements on purpose. People genuinely do not know what they have until someone asks them directly, because the processes that "everyone just knows" are invisible to the person who runs them every day. A club's own founder does not think to mention the admin panel he built himself years ago, because to him it was never a feature, it was just how things worked.

And being careful with money produces exactly the drip-feed that makes the work cost more in the end. That is the uncomfortable part.

The instinct that feels responsible, ask for less, see how it goes, is the same instinct that hides the full shape of the job until it is too late to design around it cheaply.

What to do instead

Seeing the whole shape of a job before committing to build any of it is a piece of work in its own right, and a small one compared with the cost of getting it wrong. It does not commit you to building everything you find. If anything it is the opposite: it tells you plainly what you do not need to build, which is usually most of it.

That is the whole case for starting with an audit rather than a brief: not to sell you more, but to see the job whole before anyone starts cutting code to fit a picture that is still missing pieces. If that sounds like where you are, the Admin Automation Audit is built to answer exactly that question first.