SolutionsOperate
Custom software is not a better version of off-the-shelf software. It is a different trade, and what you trade away is ongoing cost and responsibility.
Most businesses do not need a custom system. They need a small custom piece connected to standard ones — the accounting bought, the email bought, and the one thing that is genuinely theirs built properly.
That is the work: finding which part of the operation is actually yours, and keeping the surface you own small enough to afford maintaining.
01
There are a few situations where custom software pays for itself, and they have a recognisable shape.
02
Three reasons come up constantly and none of them survives a close look. "The software doesn't work the way we do" is often a sign the tool encodes a more sensible process than the one you are defending. "We want it to look like us" is a reason to configure, not to rebuild. And "it will be cheaper than the subscription" almost never holds once hosting, maintenance and the changes you will want in six months are counted.
03
The process is written down as it actually happens first, including the parts people work around. Then the smallest version that would be genuinely useful — not a demo, the thing people would open every day. It goes into real use, and it grows from what that teaches rather than from a specification written before anyone had used anything.
04
What happens to this if the person who built it is unavailable for six months? What does it cost to change, not to build? What are you replacing — and if the answer is "nothing, this is additional", why will anyone use it? A project that cannot answer those is not ready, however clear the requirements look.
Recognisable when
Questions we get
Honestly, it depends on scope — but the build is the smaller number. Hosting, maintenance and the changes you will want in six months are the part that decides whether it was worth it. We would rather scope something small that survives than something ambitious that becomes a burden.
The first genuinely useful version is usually weeks rather than months, because it is deliberately small. Anything that needs a year before anyone can use it has been scoped wrong.
Almost never, and we would argue against it. Buy the accounting, buy the email, buy the storage. Build the one thing that is genuinely yours and connect it to the rest. That keeps the surface you own small, which is what keeps it affordable.
You own the code and the infrastructure. We treat "what happens if we are not here" as a design question, not a contractual one — if a system only works while one party is available, it was built wrong.
Where to start
The first conversation is about understanding what is not working, not scoping a build. Sometimes the answer is much smaller than expected, and occasionally it is not software at all.
