Software Development & Bespoke Business Applications

When should you build software rather than buy it?

Rarely, and the honest test is whether the thing you want is genuinely how you compete or merely how you have always done it. Almost every requirement that arrives described as a software project turns out to be one of four things, and only the last is a build.

The strongest signal for a real build is that the process is specific to how you make money and you have already tried to buy it twice. The strongest signal against is that a product does most of it and the objection is a compromise on the edges, because the cost of avoiding that compromise is not the build, it is owning the result for the next decade.

We will say which of the four we think it is at the end of the first conversation, and we say it before anyone is quoted, because a supplier who only ever finds reasons to build is not giving you advice.

Why can our systems not produce the report we need?

Usually because the data is fine and the reporting layer is not, which is why the answer is rarely to replace the system. Business applications are designed around entering and processing records rather than answering questions across them, and their reporting tends to be a fixed set of views the vendor thought of.

The second reason is that the question spans systems. The report somebody actually wants joins the finance system to the CRM to the job scheduler, and no single product has all three, so a person becomes the join and does it by hand in a spreadsheet every Monday.

The fix is to get the data out on a schedule, put it somewhere designed to be queried, and build the reporting on that rather than fighting the source system. That also removes the risk of reporting queries slowing down the thing people use to do their jobs.

The part that decides the cost is extraction. A system with a documented API is straightforward. A system with a supported database connection is fine. A system where the only route out is a screen, and a vendor who charges for exports, is a different project, and it is worth finding out which you have before anyone designs a dashboard.

How do you replace a CRM without losing the history?

By treating the data migration as the project and the new CRM as the easy part, because the reason CRM replacements go badly is almost never the new product.

The first job is deciding what actually comes across. Years of records include duplicates, contacts who have left, opportunities that were never closed and fields that three different people used for three different purposes. Migrating that faithfully means paying to move a mess into somewhere new and then distrusting the new system within a year, so the cleaning happens before the move rather than as a tidy-up afterwards.

A frequent and cheaper answer is that the CRM is fine and the way it has been set up is not. If the objection is that it has become the wrong shape, it is worth an hour establishing whether the shape is the product or a decade of accumulated configuration, before paying to move.

What does AI actually do inside a service desk?

The useful work is unglamorous: reading a ticket as it arrives, working out what it is about, routing it, drafting a first response from material that already exists, and pulling together the context an engineer would otherwise spend five minutes gathering.

That is where the time goes on a busy desk, and it suits automation because the volume is high, the shapes repeat, and a human still reviews the output before it reaches the customer.

What matters is the boundary. An AI step should draft rather than send, suggest a category rather than silently close, and be measured on whether an engineer accepted its suggestion. The moment it acts unreviewed on a customer-facing channel, the failure mode stops being a wasted minute and becomes a wrong answer sent under your name.

It also has to answer from your material rather than in general, because a drafted reply is only worth having if it is grounded in your documented fixes and the customer's actual configuration. That is a retrieval problem before it is an AI one. Where that grounding is the substance of the project rather than one component of it, it is engineering in its own right, and the AI engineering page covers it properly.

What happens to bespoke software after it is built?

This is the question worth asking every supplier, including us, and it is the one that decides whether the investment survives. Most bespoke software does not fail during the build. It works, it is handed over, and then eighteen months later nobody knows how to change it, the person who commissioned it has moved on, and it is quietly worked around.

Our answer is that you own the code, it runs on infrastructure you own or we manage transparently, and it is built to be handed to someone else, because software you cannot leave is not an asset. It is also why we would rather build something small that survives than something impressive that becomes a liability.

How do you keep a bespoke build from overrunning?

By making the first commitment small and the first delivery real. The pattern that fails is a long build against a specification agreed at the start, because that specification was written when everyone understood the problem least, and nobody finds out it was wrong until the end.

So the first stage is scoping, priced as its own fixed piece of work, and its output is a written scope of the problem separated from the solution somebody had already imagined. That is deliberately small: it is where you find out whether the data comes out, whether an existing product would do, and what the real effort is, before there is any pressure to keep going.

After that, the smallest genuinely useful version goes to real users in production. Not a prototype and not a demonstration, because neither tells you anything reliable. People use software differently from how they describe using it, and the first fortnight of real use changes more requirements than any workshop.

The cost driver, almost always, is integration rather than the application itself. Screens are predictable. Getting clean data out of a system that was never designed to give it up is not, which is why we try to prove the hardest extraction first rather than leaving it until the end when the budget is spent.