Enterprise Systems, Data & Custom Software

Three reasons hold up. You have outgrown it — you bought it when the company was half this size. It genuinely cannot do what you need, and no amount of configuration changes that. Or you are far enough behind on versions that the upgrade has quietly become its own implementation. At that distance, upgrading and replacing stop being different sizes of decision. If one of the three is yours, you have a case you can take to a board. If none of them are, we'll tell you that, and it's the cheapest answer you'll get.

These projects go to whoever knows the system best, so they get designed from one seat — with a bias toward that department and a blind spot just past it. The result works exactly as intended. Then the teams on either side of it can give up as much ground as was gained, or more, to make room for it. Only one of those numbers ever reaches the business case. We start with the whole process and everyone in it, and we look for the root cause rather than the complaint. Done that way, one department's pain becomes several departments' gain.

A client's system was failing — data corruption they had worked around until they couldn't. They came to us to plan the upgrade. What they had not worked out was how big that upgrade had become: six years behind, on a base release without the patches added since, a different interface, different logic, and a warehouse bolt-on that had changed hands and would have meant new hardware on the floor. At that size an upgrade can cost what moving to another product costs, which makes it worth looking at both. We did. They stayed where they were, and it was the right call — but now an informed one, and a year later they could still say with confidence why.

A client asked us to build a bolt-on: a note that would appear when an invoice was issued, setting out that customer's tax rules. We asked why before we quoted it. That puts a person in the loop every single time, and a note that always appears is the first thing that gets ignored. We did some digging and learned they were already paying for a module that manages tax rules and applies them automatically. They no longer needed the bolt-on — and the manual review went with it, because the note was the only reason anyone opened an invoice before it went out. They had been paying for the module and for the people working around it.

A salary is not what a hire costs. There's the recruiting, the onboarding, the months before they are useful, and the time your own people spend getting them there — none of it on the offer letter, all of it real. The quote here works the same way: license, configuration and the build. At least a quarter of what the change actually costs sits outside all three — testing, training, the communication, hypercare, and the months after go-live when people are still learning. Much of that is your own people's time, which is why it can be missing from the estimate entirely. And it isn't a tail-end activity: you don't finish the system and then manage the change. On a program that finished two months early, we had doubled the time budgeted for testing and training — and it still wasn't enough.

Driving on the other side of the road is one thing to learn. But the controls are in different places, the signs are in another language, the intersection rules aren't the ones you know, and your judgment of distance is wrong. Any one of those you would absorb in an afternoon; together, on day one, they are what makes it dangerous. A new system arrives the same way — the vocabulary, the process, who tells whom, the rules the business runs by, and the logic behind a decision that used to be obvious. Count them all, plan for each, and by the third month the new way is just how the work gets done.

Few car companies make their own transmissions — one of the most complicated parts of the car. The same ZF eight-speed sits in a Jeep and in a Rolls-Royce. Each company specifies and tunes it for their own car, and that is the whole difference between the two. Software is no different: the runtime and the frameworks come from suppliers like Microsoft and sit underneath scores of businesses. What we build is everything between those and a working application, shaped to how your business runs. When a fault turns up in a supplied part, fixing it is the supplier's job, for everyone at once.

It is the architecture, and off-the-shelf software gets it wrong too — a front end talking straight to the database, nothing encrypted in transit or at rest, passwords stored as plain text. Ours is layered: the front end never touches the database. A security layer sits between them and is the only thing that does — the same one in every application we build. Identity runs through your own provider where you have one, Entra ID or its equivalent, and inside the application to the same standard where you don't. So what you're buying isn't a promise about our code — it's a structure someone else can inspect.

Anyone can say the right words in a meeting — layered, encrypted, single sign-on. The test is whether they will show you. Ask to see the architecture and the security design, not a description of them. Then ask what you would be holding if they walked away tomorrow. A builder who has good answers hands both over without being pushed; one who doesn't will explain why you don't need them.

Most mid-market companies are already running something custom — a quoting tool, a scheduler, something bridging two systems that were never meant to talk. If whoever built it has gone and there's no documentation, a change that should take a week takes a quarter, because only one party can make it. What we build ends differently. You get all of it — the source, the architecture and security design, the specification and the documentation, produced as the work happens rather than written up at the end. No subscription, because there is nothing to license. Whoever you choose can maintain it, including us if you want.