Most businesses that ask this question aren't ready yet. That's not a sales pitch dressed up as honesty. It's actually the answer.
Custom software is a real commitment. Done properly, it costs money, it takes weeks or months, and it requires your office team to be involved during the build. Done badly, it can create more chaos than it removes. The firms that get the most out of it are the ones who arrive at the conversation already knowing exactly what they need. The firms that get the least out of it are the ones who arrive hoping somebody will tell them.
So before you spend money finding out which kind you are, here's a way to tell from where you sit.
You're probably ready if
You can name a specific recurring problem. “We spend two days every month chasing subcontractor compliance documents” is a problem custom software can solve. “We need to be more digital” is not. The more specifically you can describe what's eating your office team's time and money, the more likely it is custom software will help.
You've tried the obvious off-the-shelf options and you can say what was wrong with them. Not “we didn't like it.” Something like: “we tried the project management tool, the team adopted it for three weeks, and then dropped it because it didn't handle the way we actually handle extra work.” That kind of specific failure is the strongest signal that you've hit the edge of what generic tools can do for you.
There's someone in the office who'd champion the build. Not the MD. The MD's job is to authorise it. The champion is the person who actually does the work the software will change. If you can't name the person internally who'll sit through the audit, give feedback on early versions, and push for adoption, the project will struggle. With them in place, it will succeed.
You understand that custom software needs ongoing care. If your mental model is “we pay a developer, they build a thing, we use it for ten years and it never needs touching,” custom software will frustrate you. The right model is “we build a tool, it earns its cost, and we adjust it as the business changes.” Same as any other tool the business depends on.
You're probably not ready if
You haven't tried the obvious tools yet. This sounds counterintuitive coming from someone who builds custom software, but the truth is most operational problems in mid-market construction can be partly solved with the right off-the-shelf tool. Custom software is for what's left over after the off-the-shelf tools have done what they can. If you haven't tried the off-the-shelf tools properly, you don't yet know what's left over.
Your business or the problem keeps changing. “We need a system to track...” and then a month later, the thing being tracked is different, and the month after that it's different again. Or there's a bigger change in the works: a pending acquisition, a major partner change, a shift in the kind of work you're taking on. Anything that means the business will look different in six months means the software you build now is software you'll be replacing in twelve. Settle the process first. Then build the tool.
The people who'd use the software don't want it. If the MD wants custom software and the office team doesn't, custom software will fail. Office teams who feel things imposed on them will route around them, sometimes deliberately. The build needs the people who'll use it on board from the start. If they're not, the time is to find out why before you commit to a build that won't get adopted.
You want it cheap, fast, and exactly right. Pick two. The firms that get good custom software accept that one of those three is negotiable. The firms that insist on all three end up with software that doesn't work properly, delivered late, that they overpaid for anyway.
If you're not ready yet
Not ready doesn't mean never ready. Most firms that aren't ready now will be in six or twelve months, often after they've tried the off-the-shelf tools and discovered exactly what's left over.
If you're not sure whether you're ready, the cheapest thing you can do is have a conversation with someone who builds this stuff for a living, and trust that they'll tell you honestly when you're not. The right developer would rather pass on a project that isn't ready than build something that doesn't work and damage their reputation in the process.
The wrong developer will tell you you're ready regardless. That's also useful information.
If you want an honest read on where you are, get in touch.