Should We Build It? The Question We Ask Before Writing Any Code

When an organisation approaches a software development company, the expectation is usually that the conversation will end in a proposal to build something: a new application, a replacement for an ageing system, a platform to join up disconnected processes. It's an understandable assumption, but it skips a question that should be answered before anyone talks about technology, budgets or delivery dates.

Should we actually build it?

At Libertas Software Research (LSR), we believe knowing whether to develop software matters as much as knowing how. Sometimes a bespoke application is exactly right. Sometimes an established SaaS platform meets the need perfectly well, or connecting the systems you already have delivers the outcome without the cost and disruption of replacing them. The goal is to improve how an organisation operates, not to add another application to an already complicated environment.

Start with the problem, not the solution

Organisations tend to describe the solution they think they need rather than the problem they have. "A reporting dashboard" or "an app to replace our spreadsheets" sounds well defined, but it says little about what prompted the request.

Take a monthly management report assembled by hand from several spreadsheets and systems. It takes days, and by the time it lands the data is already stale. The obvious conclusion is that you need reporting software. Look closer and the real issue is often disconnected data and inconsistent processes: a modest integration project, not a new application. And if the investigation shows you need specialist workflows or controls that no product supports, that's the moment a bespoke build earns its place.

When buying makes more sense

The commercial market is mature. CRM, accounting, scheduling, document management and business intelligence all have products with years of refinement behind them. If one meets your needs without unreasonable restrictions, a bespoke replacement adds little value.

But compare total cost of ownership, not subscription prices. A £500-a-month product is £30,000 over five years before you add configuration, integrations, extra licences or changes to your own processes. Check how pricing scales, whether you can export your data, and what happens if the vendor changes its model. And be wary of forcing the business to abandon activities that genuinely set it apart just because a product assumes otherwise.

Sometimes the answer is to connect what you already have

Most organisations accumulate systems over time: finance on one, operations on another, customer service on a third. Each works fine; they just don't talk to each other, so you get delays, duplicated effort and inconsistent information.

Replacing everything with one application is tempting, but it's risky. Existing platforms hold years of operational knowledge and hidden integrations. A carefully designed integration layer (connecting APIs, automating transfers, consolidating reporting from authoritative sources) can extend the life of those investments. It needs proper thought around authentication, data ownership, error handling and auditability, but recommending integration over replacement isn't lesser engineering. It's often the more considered architectural decision.

When bespoke is the right investment

Some requirements genuinely don't fit mainstream products: specialist operations, unusual security or data needs, or software that is itself a competitive advantage. Here, custom software lets the architecture follow how the business actually works.

That flexibility comes with a long-term responsibility for maintenance, security, testing and support. A system can meet its original specification and still be a poor investment if it's hard to maintain or can't adapt. Bespoke development is justified when the benefits of a purpose-built solution outweigh both the upfront cost and the ongoing commitment of owning it.

Not every problem needs more software

Sometimes the process is the problem. Approvals, reports and admin steps pile up over the years, long after the circumstances that created them have gone. Automating them exactly as they are just preserves the complexity.

If a document needs five approvals, don't ask how to automate five approvals, ask why each exists and what risk it covers. Software is excellent at applying consistent rules, but it can't tell you whether the process is sensible. Simplifying a workflow or clarifying ownership can deliver real gains without another system to learn and support.

Look beyond the initial cost

Bespoke projects carry a large upfront cost while SaaS spreads its cost over subscriptions, which makes the comparison look lopsided. A fair one covers the whole lifetime: implementation, licensing, hosting, support, maintenance, integration, training and future change.

Include the cost of doing nothing, too. An inefficient process eating 20 staff hours a week is around 1,040 hours a year. At an illustrative £35 an hour, that's about £36,400 annually, assuming the time can genuinely be recovered and redirected. Add poor data quality and slow decisions, which are harder to price but just as real. The best option isn't the cheapest; it's the one with the strongest mix of value, acceptable risk and long-term sustainability.

Why would a software company recommend not building software?

It's a fair question. If we recommend a product or a small integration, that's less development work on paper.

But there's a difference between providing development capacity and acting as a software research and architecture partner. Our work begins before the specification exists: understanding the problem, weighing the options, and helping you decide where to invest. That has value whatever the outcome, and there's usually still analysis, architecture, planning and integration work to do even when a custom build isn't the answer.

Recommending development you don't need is counterproductive. A project delivered on time and to spec still fails if it wasn't the right solution. Helping a client avoid unnecessary spend builds the kind of trust that lasts.

Being able to build isn't a reason to build

AI and modern tooling are making code faster and cheaper to produce. That's useful, but it makes the upfront thinking more important, not less, because the effort that once forced people to ask "do we really need this?" is disappearing. It's entirely possible to build something technically excellent, deliver it efficiently, and discover it was the wrong answer.

Before development begins, we want clear answers on the business problem, the cost of leaving it unresolved, which requirements existing products can't meet, how success will be measured (processing time, accuracy, visibility, compliance, not feature counts), and who will run and support the solution afterwards.

There will be projects where bespoke software is clearly right, others where integration is better value, and others where an off-the-shelf platform does the job. What matters is that the recommendation follows from understanding your organisation, not from an assumption about what a software company wants to sell.

Before asking how we should build something, it's worth establishing whether we should build it at all.

Libertas Software Research works with organisations to research, evaluate, architect and develop software solutions, with a focus on long-term maintainability, operational value and informed technology investment.