Blog Process
The Most Expensive Part of Software Isn't Building It
Most people assume the expensive part of software is writing the code.
Almost every project I've worked on has told me otherwise.
The real bill arrives after you ship.
Launch day gets the champagne. The next five years get almost none of the attention and they're the part that actually costs money.
A handful of questions usually decide which way things go:
- How painful is the next update, really?
- Would a different developer understand this without asking you?
- What breaks the moment the requirements shift?
- Ten users become ten thousand. Does anything fall over?
- Can you add one feature without rebuilding three others?
Answer those honestly and you'll know pretty quickly whether you're sitting on an asset or quietly stacking up debt.
I've watched a version of this play out more times than I can count. Picture two businesses, each putting down £2,000 for a new website.
Website A
Up in a weekend. A plugin for everything, a shortcut behind every button.
A year on: something's on fire after every update.
Website B
Takes a bit longer. Somebody actually thought about what happens after launch.
A year on: new features land without anyone panicking.
Same invoice on day one.
A very different one twelve months later.
The rule of thumb I keep coming back to is a plain one:
Software should get easier to extend, not harder.
In practice, that's rarely one big decision. It's a pile of small ones:
- Structure someone else could predict
- Names that mean what they say, nothing cuter
- Less cleverness than you could technically get away with
- A note next to the decision that isn't obvious in hindsight
- Code a stranger could read without wanting to swear
None of that shows up in a screenshot or a demo.
It's still what quietly decides whether the thing lasts — or gets replaced eighteen months in.
Most small businesses don't need the newest framework, and they definitely don't need the trendiest layout on the block.
What they need is something that keeps working while nobody's watching it.
- Next year A booking system, probably
- The year after A customer portal
- Once volume shows up Automation, finally worth the effort
Solid foundations make all of that boring, in the good way. Weak ones turn every one of those requests into a small rebuild.
Tools change every year. The boring principles underneath them mostly don't.
When I build something, I'm not only aiming at launch day. I'm thinking about whoever opens the project three years from now — often that's me, mildly annoyed at a decision past-me made in a hurry.
If that person can find their bearings quickly, change things without flinching, and actually trust what's underneath, the software did more than solve today's problem.
It left room for tomorrow's.