The phrase “custom software” has a bad reputation in mid-market construction. Most firms who've had it built once have a story about why they'd never do it again. The build that ran six months over. The developer who disappeared after launch. The system that worked on day one and was unusable by the end of the year. The “specification document” that grew to two hundred pages and still didn't describe what they actually needed.
The reputation is earned. Most custom software in construction has been delivered badly, by people who didn't understand the work and weren't around long enough to fix it.
But the failure mode isn't custom software itself. It's a specific way of doing custom software that breaks in predictable ways.
Here's what the broken version usually looks like.
A construction MD agrees that the spreadsheets and off-the-shelf tools aren't working. A development agency is brought in. They run a “discovery phase”. Three weeks of workshops, interviews, document gathering, then they produce a specification. The specification is detailed but already slightly wrong, because the agency doesn't know construction and the MD doesn't know software. Both parties agree to it anyway because that's how the process works.
The build begins. Three months in, the agency demos something. It looks roughly right but doesn't quite fit how the office team actually works. Changes are requested. Changes turn into extra charges. The extra charges extend the timeline and the bill. The build is now five months in, the spec is six months out of date, and nobody is sure what “done” looks like anymore.
Eventually, something gets delivered. The office team gets two days of training. The agency hands over the code, says thanks, and moves to the next project. Six weeks later, something stops working. The agency quotes an ongoing maintenance fee. The MD doesn't want to keep paying. The software starts to drift. By the end of the year, it's the new system that needs replacing.
That's what most firms mean when they say custom software didn't work. And they're right.
There's a different way to do it. It's not new and it's not clever. It's just rare.
Build less. The whole industry incentive in software is to build big, because bigger projects mean bigger invoices. But a small piece of software that does one thing well, delivered in three or four weeks, beats a six-month integrated build every time. You can actually finish it. The office team can actually adopt it. You can see whether it's working before you commit more money.
Build with the people who'll use it, not for them. The office team knows where the work actually leaks. They know which spreadsheet has the workaround in column G. They know which step in the process is the one nobody wants. If you build software based on what an MD describes in a workshop, you'll build the wrong thing. If you build it sitting next to the person who'll use it daily, you'll build something they'll defend.
Ship working software in days, not months. Not the whole product. A working piece of it. Something the office team can open and try. Then change it based on what they actually do, not what they said they'd do. Real software shipped in week two beats perfect software shipped in month six, because the office team's behaviour with real software is the only reliable signal of what actually needs to be built.
Make sure the firm owns it. The code, the data, the hosting, the documentation. Not “owns it” in the marketing sense where another company is still holding the keys. Actually owns it. The test is simple: if your developer disappeared tomorrow, could another developer pick this up and keep it running? If the answer is no, you don't own it. You're renting it from someone you can't see.
Plan for what happens after launch. Software drifts when nobody owns it. Office teams change. Business processes change. The thing that was right in March needs adjustment by October. Either there's a maintenance relationship that handles this, or the software will start to rot from the day it's delivered.
When custom software is done this way, it doesn't look like the traditional bespoke nightmare. It looks like a series of small wins. Three weeks of work, a tool that does one thing, another three weeks, another tool, until the firm has a small set of sharp tools that fit it precisely. The total time is shorter. The total cost is lower. The adoption is higher because the office team built it with you, not had it imposed on them.
I want to be clear about when this isn't right. If you don't know what you want, custom software will eat your budget while you figure it out. If you're not willing to give the office team time during the build to test things and give feedback, custom software will fail. If you want everything specified up front and signed off before any code is written, you'll get something that was right six months ago and isn't anymore.
But if you have a clear problem, an office team that's willing to be involved, and a tolerance for shipping something simple before shipping something complete, custom software works. Properly built, it's the closest thing in your business to a tool that actually fits your hand.
If your last attempt at custom software left a bad taste, the problem wasn't the idea. It was the delivery.
There's a better version. If you want to talk about what that looks like for your business, get in touch.