Custom software or off the shelf: how to decide

Start with the right question

Before comparing custom software with packaged software, ask which problem you are trying to solve and what you risk by solving it with a tool built for everyone else. Many leaders compare prices or feature lists before checking whether the process they want to support looks like every other company in their sector, or whether it is actually what sets them apart.

Asking this question first avoids a common trap: picking the tool before you have properly described the process you are trying to improve. A feature comparison chart between two competing products says nothing about the question that actually matters, namely whether the process itself deserves a dedicated tool or can live with something shared across an entire sector. Asking this question first often changes the conclusion.

When packaged software is the right call

A standard process, shared by hundreds of companies in the same sector, is rarely good ground for custom work. Invoicing, payroll, stock management in their most common form: these needs have long been covered by vendors who refined their product across thousands of customers. Building a tool to do the same thing, with less experience behind it, costs more and gives you no competitive edge. If your team describes its need in generic terms (bill a client, track stock, schedule a crew) without adding "but we do it differently because...", the market probably already has your answer.

A quick way to check

A simple test is to ask three people to describe the same process, independently of one another. If the three descriptions look alike and could apply to any company in the sector, that is a strong signal the process is standard. If each one adds different exceptions, edge cases tied to a specific client, a region, or an old internal habit, that is already a sign the process is more specific than it first appears, and that packaged software will struggle to absorb it without awkward workarounds.

When building makes sense

A few signals point the other way. The process you want to support is part of what makes you different: a production method, a way of qualifying a file, a sequence of checks that exists only at your company. The trade is poorly served by generalist software: vocabulary, units, regulatory constraints that standard vendors ignore or bolt on as a poorly fitted option. Or the team is already working around the purchased tool all the time, with parallel spreadsheets, copy-paste between two systems, fields filled in any old way because the form does not match the real work. Those permanent workarounds are a more reliable signal than a personal taste for building.

Other signs worth watching

A few other clues deserve to be taken seriously, even if they are less obvious at first glance:

• The packaged software imposes vocabulary that does not match yours, forcing your teams to mentally translate every screen they open.
• The vendor's support consistently replies that your request falls outside the standard scope, without ever proposing a product change.
• The process you want to support evolves quickly, at the pace of your business, while packaged software changes slowly, at the pace of a roadmap shared across every customer.
• You have already tried heavily customising an existing package, and that customisation now costs almost as much as a dedicated build, without belonging to you either way.

The costs you don't see right away

Both options carry hidden costs, different but real. Packaged software comes with a per-user price that climbs as your team grows, and initial configuration often takes longer than planned. More importantly, your work bends to fit the tool: teams change their habits to fit the categories the vendor designed, a human cost that rarely shows up on an invoice.

A custom tool costs money to build, then to maintain over time: security updates, changes in the business, the day the person who wrote it leaves. That last point is often underestimated: a custom tool with no documentation and no continuity becomes technical debt the moment its author moves on.

A way to compare over time

To compare the two options honestly, look past the first quote. Packaged software has a low entry cost but one that grows with the team and with the time spent working around what it cannot do. A custom tool has a higher entry cost, but a usage cost that stays stable, as long as it is properly maintained. The right comparison, then, is not a quote against a subscription, but a cost trajectory over several years, factoring in the time lost by teams in both scenarios.

Reversibility and data ownership

Before signing anything, ask a simple question: if I change my mind in two years, what do I get to keep? With packaged software, the answer depends entirely on the contract and the export format the vendor is willing to offer. With a well built custom tool, the data and the code belong to you, and you can change provider without rebuilding everything. Reversibility decides whether you can revisit this choice later, and it is negotiated before you sign.

Questions to ask before signing

A few concrete questions help clarify reversibility, whichever side you lean towards:

• If I leave, can I get back all of my data, in a format I can reuse elsewhere, or only a partial export?
• Does the source code belong to me, or does it remain the property of the provider who wrote it?
• Is there enough documentation for another provider to pick up the tool without starting from scratch?
• What actually happens if the vendor or the provider goes out of business?

An evasive answer to any of these questions is useful information in itself, even before you compare prices.

The hybrid option

Between the two extremes, a third path often exists: keep the packaged software for what it does well, and connect a custom tool to it for the part that sets you apart. A standard ERP for accounting, an agent that reads your specific documents and structures them before feeding the ERP. This approach limits the risk: you are not replacing a tool that works, you are only adding what it lacks. It is often the most reasonable path, and the one a diagnostic can identify before any development starts.

What a hybrid approach looks like in practice

Concretely, this can take the shape of an AI agent that reads documents your current package cannot interpret, or an automation that connects two off the shelf tools together so nobody has to re enter the same information twice. In cases where the need goes beyond a simple connection between two tools, a dedicated full application covering the specific part of the business can coexist durably with the packaged software, each one remaining responsible for what it is best suited to. Concrete use cases, drawn from projects already delivered, show what this kind of arrangement looks like once it is in place.

Questions to ask a provider, whichever side you lean towards

Whether you are leaning towards packaged software or a custom build, the quality of the answers you get upfront often tells you more than any sales deck. Here are a few questions that help separate a real partner from a simple vendor.

On the packaged software side

• How many of your customisation requests have already been turned down in the past, and for what reason?
• What actually happens when a product update changes a behaviour your teams depend on every day?
• How long does it typically take to get a support answer on a case that falls outside the standard scope?

On the custom build side

• Did the provider spend time observing the real process before proposing an architecture, or did they price the work straight from a specification written without them?
• Who, on the team that will build the tool, remains available once the first version ships?
• What happens if the business process changes mid build, which happens on almost every project that runs several months?

None of these questions has one universal right answer, but the absence of a clear answer, in either direction, is itself a signal worth paying attention to. Write the answers down and revisit them once the contract is actually signed. It is a simple habit, and it is surprisingly rare, yet it turns a vague impression gathered during a sales conversation into something you can hold a provider to later, once the pressure of the decision itself has passed.

Deciding without guessing

The right move, before any quote, is to map your processes and ask which ones are genuinely specific to your business. If the list is short, the market likely already has what you need. If it reveals a process that makes your difference, or a team already working around the tool in place, custom software becomes defensible. An outside diagnostic, run before any pricing, helps you decide without relying on intuition or on the sales pitch of whoever is selling the solution.

Common mistakes to avoid

A few traps come up again and again in this kind of decision. The first is letting the packaged software vendor judge for themselves whether your need is standard or specific, when they have an obvious interest in saying their product fits. The second is launching a custom build without having mapped the process first, which often ends up rebuilding, at a higher cost, a tool that looks a lot like what the market already offered. The third is ignoring the question of reversibility until the day you want to switch solutions, which is exactly the moment it is too late to negotiate. An upfront diagnostic, independent of any vendor or development provider, remains the best way to avoid all three traps at once.

Frequently asked questions

How do I know if my need is genuinely specific to my business?

Check whether you describe the need in generic terms shared across your sector, or whether you keep adding "but we do it differently". If the process looks the same as everyone else's, the market probably already has your answer.

Is custom software always more expensive than packaged software?

Not necessarily, it depends on usage. Packaged software licenses climb with the number of users and configuration has its own cost, while custom software costs money to build and then to maintain over time. The right comparison looks at several years, not just the starting price.

What happens if I want to switch solutions later?

It depends on what the contract says about reversibility and data export. With a well built custom tool, the code and the data belong to you, which makes it easier to change provider without rebuilding everything.

Can I combine packaged software and a custom tool?

Yes, and it is often the most reasonable option. You keep the packaged software for standard processes and connect a custom tool for the part that makes your business different.