Custom software or off-the-shelf: how do you decide?

Most organisations should buy, not build. If a mature product already covers the great majority of what you need, buying it is almost always faster, cheaper and safer than commissioning software, and you should only build custom when the process in question is genuinely a competitive differentiator, when no product fits without distorting how you work, or when regulation, integration or local conditions make the available products unusable. The honest answer for most buyers is a mix: buy for the commodity work, configure a platform for the middle, and build only the narrow part that is actually yours.

This guide is for business owners, association executives, operations managers and public-sector decision makers in Jamaica and the wider Caribbean weighing a software purchase against a software project. It covers the options, the criteria that decide between them, five-year cost of ownership, the two traps that catch buyers most often, what to do when a foreign product assumes a tax regime that is not ours, and how to de-risk a custom build.

The three options, and the fourth one most organisations end up with

The choice is usually framed as buy or build. It is really a spectrum with four positions.

Buy off the shelf. You licence a finished product and use it broadly as designed. You get maturity, other people’s bug fixes, a documented upgrade path and a support line. You give up control of the roadmap and accept the product’s assumptions about how your work should be done.

Configure a platform. You take a product built to be shaped: an ERP, a CRM, a case management system, a low-code business platform. You configure objects, workflows, roles and reports rather than writing an application. This is the middle ground, and where a large share of sensible answers sit.

Build custom. You commission software and application development that exists only for you. You own the behaviour, the data model and the roadmap. You also own every future decision about hosting, security, upgrades and the people who maintain it.

The hybrid. Most mature answers are a portfolio. Accounting, payroll and email are bought. The CRM or membership platform is configured. One thin custom layer sits in the middle doing the thing no product does: a portal joining the bought systems, a pricing engine, an approvals workflow, a reporting layer that reconciles three sources. The custom piece is deliberately small, which is exactly why it survives.

Start with one question: differentiator or commodity?

Before any feature comparison, classify the process. Would your customers or members notice if you did this better than everyone else, or is it administrative work that simply has to happen correctly? Payroll is a commodity, as are general ledger accounting, email, file storage, helpdesk ticketing and most document signing. Nobody chooses your organisation because your payroll run is unusual. Buy these; building them is a pure cost with no upside.

The differentiator is narrower than people expect. For a professional association it might be how members are verified, how continuing education credits are tracked and how renewals run, because that is the association’s actual product. For a distributor it might be order pricing across customer tiers and credit terms. For a clinic it may be nothing at all in software terms, in which case buy everything and spend the money on service. Write down the two or three processes that, done exceptionally, would change your market position. Those are the only candidates for custom.

The eighty per cent rule, and the true cost of the last twenty

The working test is whether a mature product covers at least eighty per cent of the requirement without modification. If it does, the question becomes what the remaining twenty per cent actually costs, and that is where most buyers reason badly.

There are only four things you can do with the gap: change your process to match the product, buy an add-on, build an extension alongside the product, or do the work manually forever. Price all four honestly. A gap that costs one person four hours a week to bridge by hand is not small: over five years that is roughly a quarter of a full-time post, plus re-keying errors. Equally, a gap that sounds alarming in a workshop often turns out to affect eleven transactions a year, in which case a spreadsheet and a named owner is the correct answer.

The dangerous version is the gap you close by customising the product itself. That gives you the worst of both models: you pay licence fees and carry a maintenance burden, and every vendor upgrade becomes a project because your changes must be retested and often rewritten. This accumulated liability is customisation debt, and it is the most common reason organisations end up trapped on an unsupported version of software they are still paying for.

How much would you change your process, and is that change an improvement?

Every product encodes opinions about how work should be done, and adopting it means adopting those opinions. That is not automatically bad: a well-built product reflects the accumulated practice of thousands of organisations, and the friction in implementation is sometimes your own bad habit meeting a better default.

So ask the harder question. If we changed our process to fit this product, would it be worse, or merely different? Different but defensible should change. A process that exists because of a legal obligation, a board requirement or a real operational constraint should not be bent to suit a product. Our digital ecosystem assessment work usually finds much of the “we are unique” content in a brief is inherited habit nobody has questioned in a decade. Separating that from the real constraints before you shortlist is the highest-value hour in the exercise.

Constraints that can decide the answer for you

Some criteria are not trade-offs. They are pass or fail, and they should be tested before you fall in love with a demo.

• Regulatory obligations. Data protection duties under Jamaican law, sector rules, audit trails and retention periods. Ask how the product supports them, not whether the salesperson says it is compliant. Our compliance and organisational support work exists largely because this gets asked after signature.
• Data residency and access. Where the data sits, who can reach it, and what happens to it if you leave. Public-sector and healthcare buyers often have hard constraints here that remove most of the market immediately.
• Integration requirements. What this must talk to, in which direction, and how often. A documented, stable API is a different proposition from a nightly file drop. If the systems you must connect to are ones you do not control, price that as a risk.
• Connectivity tolerance. If users work at sites with unreliable connectivity, a product that assumes constant broadband is not a candidate, however good it looks.

Licence maths over five years

Per-user subscription pricing is excellent at small scale and punishing at large scale, and almost nobody does the maths before signing. Take the per-user price, multiply by the number of users you will have in year three rather than today, then by twelve, then by five. Add the annual uplift the contract permits, which compounds. Add the tiers: many products push you up a price band when you cross a user count, a record count or a feature line, and the jump is rarely proportionate.

For fifteen users a subscription almost always wins. For two hundred and fifty users doing something narrow and repetitive, the five-year subscription total can exceed the cost of building and running a purpose-built system, and that deserves a real comparison rather than an assumption.

Scoring the three options against your criteria

The table below is a scoring frame, not a verdict. Weight the rows that matter to you, score each option from one to five against your actual situation, and let the totals inform the discussion rather than settle it.

Criterion	Buy off the shelf	Configure a platform	Build custom
Speed to first value	Fastest: weeks	Moderate: weeks to months	Slowest: months
Initial cost	Lowest	Moderate	Highest
Fit to an unusual process	Poor	Good within the platform’s model	Exact
Fit to a commodity process	Excellent	Good but over-engineered	Wasteful
Control of the roadmap	None	Partial	Complete
Maturity and bug exposure	Highest maturity	Platform mature, configuration is yours	All defects are yours to find
Integration flexibility	Limited to the published API	Good	Unlimited, and unlimited to pay for
Cost behaviour as users grow	Rises with every seat	Rises with seats and tiers	Largely flat after build
Internal capability required	Low: an owner and an admin	Medium: needs a steward	High: you own a codebase
Regulatory and data residency control	Whatever the vendor offers	Depends on hosting model	Your choice
Exit difficulty	Moderate: export and migrate	High: configuration rarely ports	Low if you own the code and data
Risk of abandonment	Vendor discontinues the product	Platform pricing or strategy changes	Nobody left who can maintain it

Total cost of ownership over five years

Compare on five-year total cost, never on purchase price. The table sets out the structure of that calculation. Fill it in with real quotes for your own situation; the point is the completeness of the line items, because the omitted lines are where budgets fail.

Cost line	Buy off the shelf	Configure a platform	Build custom
Licence or subscription, five years	Per user per month, compounded with uplift and tier jumps	Platform licence plus connector and storage charges	None, or a small set of third-party components
Implementation and configuration	Small to moderate	Often larger than the first year of licences	The bulk of year one
Data migration from legacy systems	Charged separately, routinely underestimated	Charged separately	Charged separately
Integration build and upkeep	Per connector, plus rework when the vendor changes the API	Per connector	Per integration, yours to maintain
Training and change management	Recurring as staff turn over	Recurring	Recurring, plus documentation you must write
Hosting, backup and monitoring	Included in the subscription	Usually included	Your cost, every month, forever
Support and incident response	Vendor service level agreement	Vendor plus partner	A retainer or an internal team
Upgrades and version currency	Vendor handles it	Vendor handles the platform, you retest configuration	Yours: dependency updates and security patching
Customisation debt	Grows with every modification	Grows with every bespoke extension	Not applicable, but technical debt is
Enhancements after launch	Wait for the roadmap or pay for an add-on	Configuration effort	Budget an annual enhancement allowance
Exit and switching cost	Export, remap, retrain	Configuration is usually lost	Low if code, data and documentation are yours

A reasonable planning assumption for any custom system is annual running cost of fifteen to twenty-five per cent of the build cost, covering hosting, monitoring, patching, support and a modest allowance for change. If nobody has budgeted that line, the organisation has not decided to build; it has decided to build once and then let the system decay.

Two traps that catch buyers most often

The cheap subscription that becomes expensive at scale

A product priced at a few US dollars per user per month is irresistible at twelve users. At a hundred and eighty users, after three annual uplifts and a forced move to the tier containing the reporting module you were told was standard, it is a recurring line nobody has authority to cut, because the whole operation now runs on it. The trap is not the price; it is that the decision was made at a scale that no longer exists and was never revisited. Re-run the licence maths at every growth step.

The custom build nobody can maintain

The mirror image: a system that works beautifully, built by one developer, with no documentation, an unusual framework choice, credentials held by one person and nobody else who can safely change it. Four years on, a dependency reaches end of life or the person becomes unavailable, and the organisation faces an unplanned rebuild at the worst possible moment. This is a governance failure, not a technical one, and it is entirely preventable.

When the product assumes a country that is not yours

This is a routine problem in Jamaica and across the Caribbean, and it deserves to be a first-class criterion rather than a late discovery. Much of the best business software is built for the United States, Canada, the United Kingdom or the European Union, and quietly assumes those tax, payroll and regulatory regimes.

The usual failure points are payroll statutory deductions and their filing formats, general consumption tax treatment, locally required invoice and receipt formats, address and telephone validation that rejects valid local formats, date formats, public holiday calendars, payment rails, and reporting templates shaped for a regulator that is not yours.

Work through the options in order. Check whether the product has a genuine Jamaican localisation rather than a generic international setting; some do. Check whether a local partner or add-on has already solved it, because paying for someone else’s solved problem is cheap. Then consider splitting the system: keep the foreign product for country-neutral work such as CRM, and use a local or custom component for payroll and statutory reporting. Only if all three fail should you treat the gap as a custom build requirement, and then price it properly, because it needs maintaining every time the rules change. Do not accept an assurance that localisation is on the roadmap. Buy the product for what it does today.

Do you have the capacity to own a custom system?

Custom software is not a purchase; it is an ongoing commitment, and the honest question is whether your organisation can carry it. You need a named internal owner with authority to decide, a maintenance budget line that survives a bad year, a development partner who will still be there in three years, and enough technical literacy on the management side to tell a real problem from an invented one.

If you cannot point to those four things, buy. That is not a failure of ambition; it is an accurate reading of your operating capacity. Organisations not ready to own a codebase are better served by digitising the process on a platform they can administer, or by a managed arrangement where someone else carries technical ownership.

How to de-risk a custom build if you choose one

If the analysis genuinely points to building, the difference between a good outcome and an expensive lesson is almost entirely in how the project is set up. Work through these in order.

1. Run a paid discovery before committing to a build budget. Map the process as it actually runs, agree the first release scope, and produce a data model, screens and a costed plan. A supplier who quotes a fixed price for a complex system without discovery is either padding heavily or has not understood the problem.
2. Cut the first release down hard. Deliver the narrowest version a real user can do real work in, then extend. Trying to replace everything at once is the classic way to spend a year and launch nothing.
3. Deliver in phases, with working software at each step. Payment tied to usable increments keeps both sides honest and gives you the option to stop.
4. Settle code ownership in the contract before work starts. You should own the source code, the repository and the data, with escrow where the supplier retains rights to a component.
5. Hold the credentials yourself. Domain, hosting, database, repository, payment gateway and third-party accounts in your organisation’s name, with the supplier given access rather than ownership.
6. Require documentation as a deliverable. Architecture overview, environment setup, deployment procedure, data dictionary, integration notes and an administrator guide. Make final payment contingent on it.
7. Insist on automated tests and a staging environment. They are what let a second developer change the system later without breaking it, which is the whole point of owning code.
8. Plan the handover as a phase with a date. A walkthrough with whoever will maintain the system, supervised support for a period, and a written runbook for common failures.
9. Sign a maintenance agreement before launch, not after the first outage. Name response times, cover security patching and dependency updates explicitly, and include an hours allowance for small changes. Pair it with managed hosting so backups, monitoring and recovery are somebody’s job.
10. Diarise a review at twelve and thirty-six months. Confirm the system is still worth running, still patched and still the right answer. Sometimes the right outcome is to retire it and buy a product that has since matured.

What this means for your organisation

Default to buying. Make the person arguing for custom software carry the burden of proof, and require them to answer three questions: which competitive differentiator this serves, why no product covers eighty per cent of it, and who will own it for the next five years. If any answer is weak, buy or configure instead.

Practically: list your processes and mark each as differentiator or commodity. Shortlist products for the commodities and run a structured trial with your own data, not a vendor demo. For anything left over, price all four options over five years using the cost lines above, and test the localisation question early. If a custom build survives that analysis, start with discovery and a deliberately small first release.

Most organisations that come to us convinced they need bespoke software leave with a smaller custom footprint than they expected. Where custom genuinely is the answer, it tends to be a focused system for associations and professional bodies, MSMEs or public-sector teams whose core process really is unlike anyone else’s, and there the investment repays itself for years.

Frequently asked questions

Is custom software always better than off-the-shelf?

No. For most processes an off-the-shelf product is the better decision, because it is mature, already debugged, supported by a vendor and available immediately. Custom software is the right answer only when the process is a genuine competitive differentiator, when no product covers around eighty per cent of the requirement, or when regulatory, data residency or local tax constraints rule the available products out.

How do I know if an off-the-shelf product fits well enough?

Use the eighty per cent test. Run a structured trial with your own data and your own staff, not a vendor demo, and record every point where the product cannot do what you need. Then price the gap four ways: change your process, buy an add-on, build an extension alongside it, or handle it manually. If closing the gap requires deep modification of the product itself, treat that as a warning.

What is customisation debt and why does it matter?

Customisation debt is the accumulated liability created by modifying a bought product. Each modification must be retested, and often rewritten, every time the vendor releases an upgrade. Over a few years this makes upgrades expensive enough that organisations stop applying them, which leaves them on an unsupported version they are still paying licence fees for. It is the worst of buying and building at once.

What happens when software does not support Jamaican tax or payroll rules?

This is common, because most business software assumes a North American or European regime. Check first for a genuine Jamaican localisation rather than a generic international setting, then for a local partner or add-on that has already solved it. If neither exists, split the system: keep the foreign product for country-neutral work such as CRM, and use a local or custom component for payroll and statutory reporting. Do not rely on a vendor roadmap promise.

What is a fair annual budget for running custom software?

Plan for fifteen to twenty-five per cent of the original build cost every year. That covers hosting, monitoring, backups, security patching, dependency updates, support and a modest allowance for small enhancements. If that line is not in the budget, the organisation has not really decided to build a system; it has decided to build one and then let it decay until an unplanned rebuild becomes urgent.

How do I protect my organisation if we commission a custom build?

Start with a paid discovery phase, keep the first release narrow, and pay against working increments. Put code and data ownership in the contract before work begins, with source code escrow where the supplier retains rights. Hold all credentials in your organisation's name, require documentation and automated tests as deliverables, plan a handover with a date, and sign a maintenance agreement before launch.