The office manager opens the CRM on Monday, exports a CSV, and pastes three columns into a spreadsheet she keeps in a folder called Actual. That folder is where the business really runs. The CRM is where it pretends to.
You will not have called a meeting about this. Nobody flagged it. A workaround grew in the shape of the gap between what the tool does and what the team needs, and the team, being sensible, went around it.
I hear it in tone first. When a client talks about a tool they have outgrown, the words are polite and the voice is not. Dismay, mostly. Sentences that start with “ideally we would” and end with “but it won’t let us”. That is the signal. Long before a spreadsheet is built, someone has stopped enjoying the software.
The tell is in the language, not the licence
Listen for three shapes.
“We wish it could do X.” “We’re on the mid-tier because of one feature.” “Someone re-keys the settlement dates on Friday afternoons because the two systems don’t talk.” Any of those, and something has drifted. You are paying twice: once in subscription, once in the labour of a person becoming the integration.
Workarounds do not show up on the P&L. They show up in a loan processor who stays back on Thursday because Wednesday’s export did not match, and in the invoice that goes out with the wrong number and gets queried three weeks later by a client who now trusts you a little less. Four people losing an hour a day each is most of a part-time role, spent on work nobody would advertise for.
When staying with the SaaS is the right call
Most of the time, honestly, it is.
A lot of build questions have a cheaper answer. Sometimes it is a different plan on the same tool. Sometimes it is a small automation between two systems the team already pays for, which I have written about separately in the manual processes worth automating first. Sometimes the workflow itself is a habit dressed up as a requirement, and the honest move is to change the habit and keep the tool.
Custom becomes the right answer when the SaaS options have genuinely been tried and none of them fits, when the workflow is a point of difference rather than a preference, when the monthly cost of the current tool plus workarounds is already inside striking distance of a one-off build, or when the thing the business needs is simply not sold, because the business is unusual in a way that matters to its clients. If none of those is true, custom is a vanity project and I will say so.
What “custom” actually means in 2026
Not a twelve-month enterprise programme. That era is over for small businesses and it should be.
What I build now is small. A focused internal tool that one team uses, scoped to two or three jobs, sitting on infrastructure the client owns.
Take the most common one I run into. Someone starts pasting client financial detail into a public generative AI model to summarise it, because the summaries are genuinely useful and the alternative is reading the whole document. It is a privacy problem nobody has thought about yet, because a confident answer on screen feels like help rather than exposure. What I build to replace that is a locally hosted language model, ephemeral by design: it runs on a machine here in Victoria, retains nothing once the session ends, is never backed up, and is not used to train anything. Connect it to the firm’s own documents through a retrieval layer and the answers get more accurate as well as more private. The data never crosses a border.
That is what the shape looks like now. One specific thing, done better than the generic market does it, owned outright.
Start with the smallest version that pays for itself
The worst way to commission a custom tool is to scope the five-year vision, price it, get frightened, and build nothing. I have watched that happen more than once. I have also, earlier in my career, over-scoped a build myself and had to walk it back, which is why I bang on about this.
The better move is to pick the smallest version that would pay for itself inside six months, build that, and use it long enough to find out what you actually need, which is almost never what you predicted on day one. When I was leading the automation team at CSIRO, that same discipline, sizing the thing properly before committing to it, avoided about $280,000 of infrastructure we turned out not to need. The arithmetic is the same at your scale, with smaller numbers.
One thing you can do before Friday, at no cost. Ask your team to list the spreadsheets they keep alongside the official tool. Not the ones sanctioned. The private ones. That list is the map.
If you want a second pair of eyes on that map, book a free audit and I will tell you honestly whether a build is warranted. Often it is not.