Custom software vs Off-the-shelf software

The strongest argument for custom software is fit. A system built for one organisation does exactly what that organisation does, in its own vocabulary, with its exceptions handled as proper cases rather than workarounds. Nobody has to remember that the "notes" field is really where the delivery window goes, or export to a spreadsheet to do the one step the product cannot. Where fit matters, that is worth a great deal.

The weakness is the same property seen from the other side. Custom software encodes your process as it is, faithfully, including the steps that exist only because of a constraint that disappeared years ago, a person who has since left, or a limitation of the system being replaced. Requirements workshops rarely question those steps. They record them, and the build then preserves them at considerable expense.

Off-the-shelf products carry a default process, and that default is not arbitrary. It reflects what worked across a large number of customers, refined over years of support requests and feature feedback. Implementations that adapt the organisation to the product tend to go smoothly. Implementations that try to bend the product into a replica of the old system tend to go badly, piling up customisation that turns every upgrade into a risk and leaves the organisation with an expensive, fragile copy of what it had before.

The test we would apply to every gap between your process and a product is simple: would a customer, a regulator or a partner notice if you did it the product’s way? If the answer is no, the difference is habit, and habit is cheaper to change than to build software around. If the answer is yes, because the difference is part of why customers choose you or a rule you are obliged to follow, then the gap is real and it is a candidate for building.

Walking through a process this way usually shows that most steps are standard and a small number are genuinely yours. That result is useful whatever you then decide. It tells you which product categories to shortlist, which gaps to probe hard during a trial and, if building does turn out to be right, how small the custom part can be.

Any page that quotes you a figure for this is guessing. Build costs, subscription prices and staff costs vary by market, product, scale and scope, and they change. What does not change is the structure of the two commitments, and comparing the structures honestly gets you most of the way to a decision.

Custom software front-loads its cost. Discovery and design, then the build, then testing and rollout, are all paid for before the benefit arrives. After launch the spending falls but never stops: hosting and environments, monitoring, security patches, upgrades to frameworks and libraries as they move on, fixes, and the continuing development any well-used system attracts. Skip the maintenance to save money and the cost does not go away. It accumulates as technical debt and comes back later as a system that is slow and risky to change. A business case that stops at the build price is not a business case.

Off-the-shelf software spreads its cost over time, and the subscription is only the visible part of it. Implementation and configuration, often by a paid partner for larger platforms, data migration, integration with your other systems, training, add-ons, a higher tier bought for one specific feature, and the time of whoever ends up as the system’s administrator all belong in the comparison. So do the renewal terms. A price agreed for the first year says very little about the fifth.

The fair comparison runs every option over the same horizon, five years being a sensible default, with people costs included on both sides and your expected growth built in. Growth matters more than most models allow for. Under per-seat pricing the subscription rises with every hire, while under ownership more users mostly means a little more hosting. A tool that is cheap for twenty people can become the largest software line in the budget at five hundred, and a bespoke system that looked extravagant at twenty can look entirely reasonable at that size.

Two costs rarely make it into the spreadsheet and often decide the answer. The first is exit: what it would cost to leave the product, or to replace the custom system, if you ever had to. The second is attention. Engineering capacity spent maintaining a bespoke version of a commodity tool is capacity not spent on the work that sets you apart, and for most organisations that opportunity cost is larger than any line in the comparison.

Every product you adopt creates lock-in, and it is worth being precise about what it consists of. Your data sits in the vendor’s schema. Your configuration, automations and reports exist only inside the product. Your integrations are written against its API, and your staff have learned its screens. None of that is a problem while the product suits you, and all of it becomes the cost of leaving if it stops suiting you. It deepens every year, which is exactly why it is easier to address at signature than at renewal.

Price changes are a normal part of buying software rather than a scandal. Vendors reprice at renewal, move features from one tier to another, introduce minimum seat counts, change what counts as a billable user and retire older plans. Products get acquired, and new owners rethink the pricing or the target market. A vendor serving both small and large customers may gradually build for the large ones. Any of these can turn a good purchase into an expensive one without anything about your own needs having changed.

The defences are partly commercial and partly architectural. Negotiate renewal protections and notice periods at the start, while the vendor still wants your signature. Test the data export before you depend on it, rather than discovering its gaps while you are trying to leave. Keep heavy customisation out of the product where you reasonably can, because each customisation is something to rebuild elsewhere. And route integrations through a layer you own, so that replacing one product means rewriting one connection rather than every system that touches it.

Custom software has lock-in of its own, and pretending otherwise would be dishonest. You depend on the codebase, its technology choices and, above all, the people who understand it. A bespoke system that only one developer can change is at least as locked in as any subscription. The protections are to keep the source code in repositories you own, run it in infrastructure accounts in your name, insist on documentation as the work happens, and decide deliberately who will maintain it, which is a choice with trade-offs of its own, covered in in-house versus outsourced development.

Reputable software contracts state that your data belongs to you. That is necessary and nowhere near sufficient. The questions that matter are practical: in what form you can get the data out, how complete the export is, how quickly you can have it, and what happens to it once the contract ends.

Exports tend to include the core records and tend to lose the things you only miss later. Change history, audit trails, attachments, comments, the relationships between records, and the configuration that gave the data its meaning may be partial, separate or missing altogether. An API that looks comprehensive may be rate-limited, or available only on a higher plan. Before you commit, export a realistic sample, load it somewhere else and see what survived. Then get in writing how long data is kept after termination and in what format it will be handed over, because those clauses are easy to agree at the start and hard to negotiate at the end.

Access matters while you are still a customer, too. If you want to analyse operational data alongside data from your other systems, you need a dependable way to move it into a warehouse or reporting tool. Some products make that easy. Others treat it as a premium feature or offer only fixed reports. If your business depends on understanding its own data, the product’s data access deserves as much scrutiny as its interface.

With custom software, the data sits in a database you control, in a schema you designed, queryable however you want and hosted wherever you decide. That is genuine ownership, and it arrives with genuine responsibility. Backups, restore testing, encryption, access control and compliance with whatever data protection law applies to you are all yours to provide and to evidence, and a vendor may already hold certifications that would take you real effort to match. Owning the data is an advantage only if you are prepared to look after it properly.

For most organisations of any size, the right answer is neither option in pure form. It is a set of bought products doing the commodity work, plus a small amount of custom software doing the two jobs products cannot: joining them into one coherent system, and carrying the workflow that makes the business distinctive.

The joining layer is the less glamorous of the two and often the more valuable. Each bought product holds part of the picture: customers in one, orders in another, stock in a third, money in a fourth. Without something connecting them, the connection is a person copying data between screens, or a spreadsheet nobody trusts. An integration service you own, built through proper API development, keeps the records consistent, enforces the business rules that span systems, and gives you one place to change when a product changes. It is also your best defence against lock-in, because each product sits behind an adapter you control.

The differentiating workflow is the second job. If your advantage is a particular way of quoting, scheduling, matching or serving customers, build that piece as an application you own and let it read from and write to the platforms around it. That keeps the bespoke part small enough to maintain properly, and lets the bought products stay close to their standard configuration, which is where they are cheapest to run and easiest to upgrade.

There is a real choice about where custom logic lives. Most serious platforms can be extended from the inside with custom objects, scripts, workflow rules and apps built on the platform itself, as on Salesforce. Light configuration inside the platform is sensible and is what it is designed for. Heavy custom code inside the platform is a different matter: it is written within the vendor’s constraints, paid for under the vendor’s licences and exposed to every vendor release. As a working rule, configure inside, and build complex differentiating logic outside, in software you own, talking to the platform through its API.

This is how we approach ERP development and CRM development: select and integrate a bought platform, extend it where needed, and recommend a full bespoke build only when the evaluation shows nothing on the market handles the core of the job. The hybrid has its own failure mode, which is accumulating products without anyone owning the whole, so that every team runs its own tool and nothing agrees with anything else. A named owner for the overall architecture prevents most of that.

Start by writing down the job rather than the solution. List the workflows the software must support, who carries out each one, how often, with what data, and what happens when it goes wrong. Leave product names and technology out of it. A clear description of the job is the most useful document in this decision, and the one most often skipped.

Then classify each workflow honestly. Commodity work is what most organisations do in much the same way. Differentiating work is where your approach is part of why customers choose you. Constrained work is shaped by regulation, contracts or data rules that may narrow your options. Most lists turn out to be largely commodity, with a short list of differentiators and a few constraints, and that balance is the best single indicator of where you will end up.

For the commodity work, shortlist products and trial them with real data and the people who will use them every day, rather than relying on a demonstration run by the vendor. Check the API and the export as carefully as the interface. Price each option at the headcount and usage you expect in three to five years, and read the renewal and termination terms. For the differentiating work, ask whether a product could handle it through configuration and, if not, how small a custom piece could close the gap.

Model the total cost of each realistic option over the same horizon, the hybrid included, with people costs on both sides. Then answer the ownership question directly: who will maintain any custom software for its whole life, and is that commitment funded? If nobody will, buy, and treat the gaps as process changes. If someone will, and the differentiating gap is real, build the smallest thing that closes it.

Finally, revisit the decision at sensible intervals. A renewal, a large change in headcount, your vendor being acquired, or a strong new product arriving in your category are all reasons to look again. The right answer at fifty people is often the wrong one at five hundred, in either direction, and the organisations that handle this well treat it as a decision they review rather than one they made once.

Organisations move both ways. Some outgrow a product and decide to build; others retire an ageing bespoke system in favour of a product that has matured since it was written. Both are larger projects than they look, and for the same reason in each direction: the data and the undocumented rules carry most of the risk.

Moving from a product to custom software works best incrementally. Export and examine the data first, because what you can get out shapes everything that follows. Then build one workflow at a time, run it alongside the product, and move users across as each part proves itself, keeping the product for whatever it still does well. A single cutover from a mature platform to a brand new system carries a lot of risk, and it is rarely necessary.

Moving from custom software to a product is mostly about the business rules that live only in code. A bespoke system that has run for years has accumulated exceptions, special cases and calculations nobody wrote down, and the product will not reproduce them unless someone finds them first. Read the code for rules as carefully as the database for data, and decide for each rule whether to configure it in the product, build it beside the product or retire it. Expect a period of process change, and support people through it rather than announcing it.

In both directions, plan for data cleansing, mapping, reconciliation and a period of parallel running, and keep the old system readable for a while after cutover for reference and audit. Before starting either, check that the problem really is the software rather than the implementation. A product that was badly configured, poorly understood or never properly adopted, and a custom system that was never maintained, both look like reasons to switch. Sometimes fixing the implementation is the cheaper and better answer, and it is worth ruling out before committing to a migration.