Most businesses reach this question the same way. A spreadsheet has outgrown itself, a subscription tool is being bent into a job it was not designed for, or a quote for custom software has landed and someone has asked, "Can't we just buy something?" Both instincts are reasonable. The wrong choice in either direction is expensive, and the cost usually shows up a year or two later rather than on day one.

This guide gives you a way to decide between three options: buying a ready-made product, configuring a platform, or commissioning custom software. It covers the factors that actually move the decision, a decision table, the mistakes made on both sides, and the hybrid approach that most growing companies end up with.

Quick answer

Buy off-the-shelf software when the process is common to most businesses and doing it the standard way costs you nothing competitively. Accounting, payroll, email, video calls and basic CRM fall into this group for most companies.

Commission custom software when the process is how you win or keep customers, when no product fits without heavy workarounds, or when you need control over the data, the roadmap and the integrations.

Configure a platform when your needs are mostly standard but your data model, workflows or approval rules are not.

In practice the answer is rarely one option for the whole business. It is a decision you make per process: buy the commodity parts, build the part that differentiates you, and connect them through APIs.

The three options, defined

1. Off-the-shelf software (usually SaaS)

A finished product sold to many customers, normally as a subscription. You get the vendor's features, the vendor's roadmap and the vendor's release schedule. The NIST definition of cloud computing lists Software as a Service as one of three cloud service models, alongside platform and infrastructure services. The practical point for a buyer: you use the application, and the vendor runs everything underneath it.

2. A configurable platform

A product designed to be shaped: CRM platforms, ERP suites, e-commerce platforms, low-code tools and content management systems. You add custom objects, fields, workflows, extensions and sometimes custom code on top of the vendor's core. You get further than a fixed product allows, but you are still building on someone else's foundation and within their limits.

3. Custom software

An application designed and built for your organization, either by an in-house team or by a development partner. You decide what it does, how it stores data, what it connects to and when it changes. You also carry the responsibility for specifying it, funding it and maintaining it.

The eight factors that should drive the decision

1. Fit to your process

This is the factor that matters most and the one most often assessed badly. Walk through the process step by step with the people who do the work and ask of each step: does the product do this, do it with a workaround, or not do it at all?

A useful rule: if a product covers the process and the gaps are things you could happily change about how you work, buy it and adapt. If the gaps are in steps that customers notice or that give you an edge, the product is asking you to give up the thing that makes you different. That is a signal to configure or build.

Be honest about which is which. Many "unique" processes are just habits. Many others really are the business.

2. Total cost of ownership

Comparing a monthly subscription to a build quote is comparing the wrong numbers. Compare what each option costs over the period you expect to use it, typically three to five years. The figures depend entirely on your situation, so here are the drivers rather than invented averages.

Cost drivers for off-the-shelf and platforms:

• Pricing model: per user, per transaction, per record or per feature tier, and how each scales as you grow
• Features locked in higher tiers that you will need later (single sign-on, audit logs and API access are common examples)
• Implementation, configuration and data migration
• Paid add-ons and third-party connectors needed to close gaps
• Staff time spent on workarounds, double entry and manual exports
• Price changes at renewal, which you do not control
• For platforms: specialist consultants or administrators to configure and maintain it

Cost drivers for custom software:

• Scope: the number of user roles, screens, workflows and business rules
• The number and quality of systems it must integrate with
• Data migration from whatever you use today
• Security, compliance and audit requirements
• Hosting, monitoring and backups
• Ongoing maintenance: security patches, framework and dependency upgrades, bug fixes
• New features as the business changes
• Your own team's time for requirements, testing and decisions

The shape of the cost differs. Subscription software starts low and rises with headcount or usage indefinitely. Custom software has a high initial cost and a lower, steadier running cost that does not rise per user. Which line ends up lower depends on how many users you have, how long you use the system and how much the workarounds cost you. Work it out with your own numbers rather than trusting a rule of thumb.

3. Integration

Software that cannot exchange data with your other systems creates manual work that nobody budgets for. Before buying, check what the product's API actually exposes, whether API access is included in your pricing tier, what the rate limits are, and whether it supports webhooks (notifications sent to your systems when something changes). A logo on an "integrations" page tells you a connector exists, not that it syncs the fields you need in the direction you need.

Custom software can integrate with anything that has an interface, but each integration is work to build and to maintain when the other side changes.

4. Data ownership and portability

With custom software, the database is yours. With SaaS, your data lives in the vendor's systems and your access to it is defined by the contract and the export tools provided. Ask four questions before signing:

• Can we export all of our data, including attachments and history, in a usable format?
• Can we do that ourselves at any time, or only on request?
• What happens to our data when the contract ends?
• Where is the data stored, and which subcontractors can access it?

If the system holds personal data about people in the UK, the vendor is normally acting as your processor, and the ICO's guidance on controller-processor contracts sets out terms the contract must include, including deleting or returning the personal data at the end of the contract at your choice. Note that this concerns personal data, not all of your business data, so the contract still needs to cover the rest. In the US there is no single equivalent federal rule; requirements vary by state and by sector, so the contract terms carry even more weight. This is general information, not legal advice.

For UK buyers assessing a cloud vendor's security, the National Cyber Security Centre publishes 14 cloud security principles intended to help organizations choose a provider. They make a sound checklist for US buyers too.

5. Vendor lock-in

Lock-in is the cost of leaving. Every option has some; the question is what kind and whether you chose it knowingly.

• SaaS: you depend on the vendor's pricing, roadmap and continued existence. Products get acquired, repriced and retired.
• Platforms: lock-in is often deepest here. Every custom object, workflow and line of platform-specific code is an investment that only has value on that platform.
• Custom: the risk moves to whoever wrote the code. If only one developer or agency understands it, and it is undocumented or built on an obscure stack, you are locked in to them.

You reduce custom software lock-in with mainstream technologies, documentation, automated tests, and a contract that gives you the source code and the rights to it. Do not assume that paying for software means you own it. In the UK, the Intellectual Property Office states that the first owner of copyright in a commissioned work is the creator, not the commissioner, unless agreed otherwise in writing. In the US, the statutory definition of a "work made for hire" covers commissioned works only in a specific list of categories and only with a written agreement, which is why software contracts with outside developers typically include an explicit assignment of rights. Have a lawyer in your jurisdiction review the IP clause.

6. Speed

Off-the-shelf software is almost always faster to start using, and that advantage is real. If you need something working this quarter, buying is usually the only option. The comparison narrows when a purchase needs heavy configuration, data migration and staff retraining, and narrows further if a custom build is scoped as a small first release rather than the full wish list.

7. Risk

The risks are different in kind, not simply higher or lower.

• Buying: low delivery risk, because the product already exists. The risks are poor fit discovered after rollout, low adoption, and changes imposed by the vendor.
• Configuring: moderate delivery risk. Heavily customized platforms can become hard to upgrade, and the result is sometimes slower and more awkward than either alternative.
• Building: the highest delivery risk. Projects fail through unclear requirements, uncontrolled scope and a poor choice of partner. These are manageable with phased delivery and regular working demos, but they need active management from your side.

8. Capacity to own it

Custom software needs an owner inside your business: someone who decides priorities, answers the developers' questions and signs off releases. It also needs a maintenance budget for as long as it runs. If nobody can take that role, a product with a vendor behind it is the safer choice, even if the fit is imperfect.

Decision table

A quick test for each process

Ask these in order. Stop at the first clear answer.

1. Is this process a source of competitive advantage, or something every business does? If every business does it, buy.
2. Does a product cover the essential steps without workarounds in the parts that matter? If yes, buy.
3. Can a platform you already use, or would use anyway, be configured to cover it without fighting its design? If yes, configure.
4. Do you have an internal owner and a maintenance budget? If yes, build. If no, fix that first or accept an imperfect product.

The hybrid approach: buy the commodity, build the difference

Very few companies should build everything, and few growing companies can buy everything. The pattern that holds up is to treat standard functions as commodities and reserve custom development for the one or two processes that define the business.

Illustrative scenario (not a client case study): a regional equipment rental company buys its accounting, payroll, email and payment processing. None of those make it better than a competitor. What does is how it schedules deliveries, tracks the condition of each asset and prices long-term hires. No rental product handles its pricing rules without spreadsheets on the side. It commissions a custom booking and dispatch application for that process alone, which reads customers from the CRM and posts invoices to the accounting system through their APIs.

The result is a smaller custom system than a full replacement would have been, with less to build and maintain, and with standard products doing the standard work.

Two conditions make hybrid work. First, decide which system is the source of truth for each type of data (customers, products, invoices) so the systems do not disagree. Second, treat integrations as part of the product: they need monitoring, error handling and an owner, because vendors change their APIs.

Common mistakes on both sides

When buying or configuring

• Choosing from the demo. Demos show the product's best path. Test your own awkward cases in a trial with real data.
• Ignoring the cost of workarounds. A few minutes of double entry per order, across a team, for years, is a real cost that never appears on the invoice.
• Customizing a platform until it becomes custom software. You end up with the maintenance burden of a build and the constraints of a product.
• Leaving exit terms until you want to exit. Check export and termination terms before signing.
• Tool sprawl. A dozen subscriptions joined by fragile automations can be harder to maintain than one well-built system.

When building custom

• Rebuilding commodities. Writing your own invoicing, chat or authentication from scratch rarely pays off when mature products and services exist.
• Automating an undefined process. If people cannot agree how the process works today, software will not settle it.
• Building everything in version one. Start with the smallest release that replaces a real pain point and extend from evidence.
• Budgeting for the build but not for maintenance. Software that is not updated becomes a security and reliability problem.
• Not securing ownership. Source code access, IP assignment, documentation and credentials should be in the contract from the start.

For technical readers

• Evaluate the API before the UI. Read the vendor's API documentation for coverage of the objects you need, pagination, rate limits, webhook reliability and versioning policy. A bulk export endpoint is your exit route.
• Define systems of record. One owner per entity, with other systems holding references or read copies. Bidirectional sync of the same field is where hybrid architectures break.
• Isolate vendors behind an adapter. Keep third-party API calls in one integration layer so replacing a vendor does not touch business logic.
• Design integrations to fail safely. Queue outbound calls, make handlers idempotent, retry with backoff and alert on failures.
• Keep platform customization upgrade-safe. Prefer supported extension points over modifying core behavior, and keep customizations in version control.
• Choose a mainstream stack for custom work. Widely used frameworks with long-term support make it easier to hire for, or hand over, the codebase.

Frequently asked questions

Is custom software always more expensive than off-the-shelf software?

It is almost always more expensive at the start. Over several years the comparison depends on user numbers, subscription pricing, add-ons and the staff time lost to workarounds. Per-user subscriptions rise as you grow; custom software costs do not scale per user. Model both over three to five years with your own figures.

When should a small business choose custom software?

When one specific process is central to how the business earns money and no product handles it without significant manual work. Small businesses should build narrowly: one process, a small first release, and bought products for everything else.

Is low-code or a configured platform a good middle option?

Often, yes, particularly for internal tools and for workflows that sit close to data already in the platform. It becomes a poor option when you need complex logic, unusual user interfaces or high volumes, or when the customization grows so large that upgrades become risky.

Who owns custom software once it is built?

Whoever the contract says. Do not assume payment transfers ownership. Both UK and US copyright rules can leave rights with the developer unless a written agreement assigns them, so make sure the contract covers IP assignment, source code delivery and third-party components. This is not legal advice; have the clause reviewed by a lawyer.

Can we start with off-the-shelf software and move to custom later?

Yes, and it is often the sensible sequence. Using a product first teaches you what you actually need. Make it possible by choosing a product with full data export and a usable API, and by keeping your own records of how the process works.

How do we avoid vendor lock-in?

You cannot remove it, only manage it. For SaaS, confirm export and termination terms before signing. For platforms, limit customization to what you need. For custom software, own the code, use mainstream technology and insist on documentation.

Conclusion and next step

The decision between custom software and off-the-shelf software is not about which is better in general. It is about each process: how closely a product fits it, what the gaps cost you over time, how much control you need over data and change, and whether you have the capacity to own what you build. Standard processes belong on standard products. The processes that set you apart deserve software shaped around them.

A practical next step is to list your core processes, mark each as commodity or differentiating, and note where staff currently rely on workarounds. That one page will tell you where buying is enough and where a build might pay for itself.

If a custom build looks likely and you plan to use an outside team, our guide to outsourcing software development from the US or UK covers contracts, IP and how to assess a partner. Entrant Technologies builds web applications, mobile apps and custom software, and also works on platforms such as Salesforce. You can see the range on our services page, or request a quote if you would like a second opinion on whether your case calls for a build at all.