Most off-the-shelf software will do most of what your business needs. That's why it sells. The trouble sits in the last stretch: the approval step your finance team actually follows, the commission rule your sales team was promised, the report the board asks for every month. When the software can't do those things, people work around it with spreadsheets, chat groups and copy-paste, and the process bends to fit the tool rather than the other way round.
That doesn't mean you should build everything yourself. Custom software is a serious commitment, and building something a £20-a-month product already does well is vanity, not strategy. The right answer depends on how much of your advantage lives in that last stretch, and what each option really costs over three to five years.
This guide gives you a three-way framework (buy, configure a platform, or build), a comparison table, and an illustrative total cost of ownership (TCO) model you can adapt with your own numbers.
Key Takeaways
- There are three options, not two: buy off-the-shelf SaaS, configure or extend a platform such as Microsoft Dynamics 365 or Power Apps, or build custom software.
- Buy for commodity processes (email, payroll calculation, accounting ledgers). Build only where the process is a genuine differentiator or nothing on the market fits.
- Compare costs over three to five years, not year one. Per-seat licences, renewal price rises, integrations and workarounds often outweigh the sticker price.
- SaaS costs are less predictable than they look: Zylo's 2026 SaaS Management Index found 78% of IT leaders hit unexpected charges from consumption or AI pricing.
- Most organisations end up hybrid: packaged tools for the standard work, custom software for the processes that set them apart, joined by integrations.
The real choice is buy, configure or build
The old framing of "custom vs off-the-shelf" hides the option many businesses should pick first. Here's how the three differ.
Buy (off-the-shelf SaaS or packaged software). You subscribe to a product built for thousands of customers. You get speed, a vendor-maintained roadmap and predictable onboarding. You accept the vendor's data model, workflows and pricing.
Configure or extend a platform. You license a platform such as Microsoft Dynamics 365 or the Power Platform and shape it to your processes with configuration, low-code apps and some custom code. You get a solid foundation (security, identity, reporting) plus room to fit your workflows. You still pay per-seat licences and live within the platform's limits.
Build (custom software). You commission software designed around your processes, data and users. You own the code and the roadmap. You also own the maintenance, hosting and security, and you carry the delivery risk.
The market is clearly tilted towards buying. In a 2024 forecast, Gartner projected that spending on cloud application services (SaaS) would grow from $250.8 billion in 2024 to $299.1 billion in 2025 (Gartner via CIO Dive, 2024). That's sensible for most standard functions. It doesn't follow that SaaS is right for every function.
When off-the-shelf software is the right call
Buy when the process is the same for you as for everyone else. Nobody wins customers because of how they run email, calculate statutory payroll deductions or post journal entries. For these, a mature product encodes years of best practice and regulatory updates you'd otherwise have to maintain yourself.
Off-the-shelf usually fits when:
- The process is commodity. Your workflow matches what the product assumes, or you're happy to adopt the vendor's way of working.
- You need it running in weeks. A subscription can be live in days. A custom build takes months.
- User numbers are small or stable. Per-seat pricing stays reasonable when seat counts don't climb sharply.
- Integration needs are light. The tool doesn't need to exchange much data with your other systems.
The warning sign is the workaround. If your team is already exporting data to spreadsheets to finish a job the software can't do, you're paying for software and for the manual labour that compensates for it.
When to configure a platform instead
Platforms sit in the middle, and for many mid-sized organisations they're the best value. If your needs are 70-80% standard (customer records, cases, approvals, reporting) with a distinctive layer on top, a configured platform gives you the standard parts for free and lets you build only the distinctive layer.
This route tends to fit when:
- You're already a Microsoft 365 organisation, so identity, security and licensing are partly in place.
- Your processes are structured (forms, approvals, records, dashboards) rather than consumer-facing or product-like.
- You want business users to adjust workflows over time without a full development cycle, which is where Power Apps is strongest.
- You need enterprise controls such as audit trails, role-based access and data residency options without designing them from scratch.
The limits are real, though. Licences are per user and add up as you scale. Heavy customisation can make upgrades painful. And if your product is customer-facing software that you sell, building it inside someone else's platform usually makes little sense.
When custom software earns its place
Build when the process is the business. If the way you quote, schedule, match, price or serve customers is what makes you different, forcing it into a generic tool erodes the very thing that sets you apart. Custom software also makes sense when nothing on the market fits a regulated, local or unusual workflow.
Custom tends to fit when:
- The workflow is a differentiator and you want to keep refining it without waiting for a vendor's roadmap.
- Seat counts are large or growing and per-user licences would scale faster than the value delivered.
- You need deep integration across several systems, with one data model you control.
- You're building a product to sell, in which case you're really in SaaS product development, not internal tooling.
A good example is a Dubai real-estate developer that was coordinating sales through WhatsApp groups and spreadsheets. We replaced that with a role-based CRM built around its sales process, so each team sees and does what its role requires. For a manufacturing client, we delivered a custom HR and payroll system designed around how the business runs its people operations. In both cases the reason to build wasn't novelty. It was fit.
The risk with custom is delivery. A McKinsey and University of Oxford study of more than 5,400 IT projects found that large ones (initial budgets above $15 million) ran 45% over budget and 7% over time on average, while delivering 56% less value than predicted. Smaller, phased projects carry less of that risk. That's a strong argument for starting with a tight first release rather than a two-year specification.
Comparison table: off-the-shelf vs configured platform vs custom
| Criterion | Off-the-shelf SaaS | Configured platform (e.g. Dynamics 365, Power Apps) | Custom software |
|---|---|---|---|
| Time to first use | Days to weeks | Weeks to a few months | Usually months for a first release |
| Upfront cost | Low | Medium (licences plus implementation) | High (design and build) |
| Ongoing cost | Per-seat subscription, rises with users and renewals | Per-seat licences plus partner support | Hosting, maintenance and support, largely flat per user |
| Fit to your process | You adapt to the tool | Good for structured processes | Built around your process |
| Integration | Limited to vendor APIs and connectors | Strong within the Microsoft ecosystem, possible elsewhere | Whatever you design |
| Control of roadmap | Vendor's | Shared: platform plus your extensions | Yours |
| Data ownership and exit | Depends on export tools and contract | Data in your tenant; customisations tied to platform | You own code and data |
| Main risk | Price rises, lock-in, workarounds | Licence creep, upgrade complexity | Delivery risk, maintenance burden |
| Best for | Commodity functions | Structured internal operations | Differentiating workflows and products |
Total cost of ownership: what to count over 3-5 years
Year-one comparisons nearly always favour buying. A fair comparison looks at three to five years and counts everything.
Costs people often miss with SaaS
- Per-seat growth. Licences scale with headcount, contractors and occasional users.
- Renewal increases. A Gartner analyst told CIO.com that subscription costs from several large SaaS vendors rose 10-20% in 2025, against IT budget growth projections of 2.8% (CIO.com, 2025).
- Unpredictable pricing. In Zylo's 2026 SaaS Management Index, 78% of IT leaders reported unexpected charges tied to consumption-based or AI pricing, and 61% said they'd had to cut projects because of unplanned SaaS cost increases.
- Unused licences. The same Zylo report found organisations leave 36% of their SaaS licences unused, with median SaaS spend of $9,455 per employee (Zylo, 2026).
- Workarounds. Staff time spent on spreadsheets and manual re-entry rarely appears in a software budget, but it's a cost.
Costs people often miss with custom builds
- Maintenance. Security patches, dependency updates and small changes. Plan for an annual maintenance budget from day one; a common rule of thumb is 15-20% of the build cost a year, but treat that as a planning assumption, not a benchmark.
- Hosting and monitoring. Cloud infrastructure, backups, logging and uptime alerts.
- Key-person risk. If one developer understands the system, you have a fragility problem. Insist on documentation and a handover plan.
- Opportunity cost. Months spent building are months your team waits for the tool.
Costs common to every option
Integration is the cost nobody escapes. MuleSoft's 2025 Connectivity Benchmark, a survey of 1,050 IT leaders, found the average organisation runs 897 applications and only 29% of them are integrated (Salesforce, 2025). Every new tool, bought or built, adds to that integration bill. Switching costs matter too: data migration, retraining and running two systems in parallel can be significant whichever direction you move.
An illustrative five-year TCO example
The figures below are illustrative only. They're round numbers chosen to show how the model works, not quotes, benchmarks or results from any client. Replace them with your own vendor quotes and estimates.
Scenario: a company with 60 users today, growing to 120 over five years, needs a sales and operations system.
| Cost line (5 years, illustrative) | Off-the-shelf SaaS | Configured platform | Custom build |
|---|---|---|---|
| Licences or subscription | £150,000 (avg. 90 users at ~£28/user/month, with renewal rises) | £130,000 (avg. 90 users at ~£24/user/month) | £0 |
| Implementation or build | £10,000 | £60,000 | £140,000 |
| Customisation and integrations | £25,000 | £30,000 | Included above |
| Hosting | Included | Included | £30,000 |
| Maintenance and support | £15,000 | £40,000 | £105,000 (~15% of build a year) |
| Workarounds and manual effort | £60,000 | £20,000 | £5,000 |
| Five-year total | £260,000 | £280,000 | £280,000 |
What the example shows isn't that one option always wins. It shows that the totals can converge once you count licences at scale, maintenance and workarounds, and that the decision then turns on fit, control and risk rather than headline price. Change the inputs (double the user count, halve the build scope, remove the workaround line) and the answer moves.
The hybrid approach most businesses end up with
In practice, the best setups are rarely pure. A sensible pattern looks like this:
- Buy the commodity layer: email, accounting, payroll calculation, document storage.
- Configure a platform for structured internal operations where it fits, such as service cases or approvals.
- Build the thin layer that makes you different: a customer portal, a pricing engine, a scheduling tool, a dashboard that joins your data.
- Integrate them deliberately, with one system as the source of truth for each type of data.
This keeps custom code small and focused, which lowers maintenance and delivery risk. It's also how most business applications projects should be scoped: start from the process, not the technology. If you're mapping the bigger picture first, our digital transformation guide covers how to sequence these decisions.
Risks of each option, and how to reduce them
Off-the-shelf. Lock-in and price rises. Reduce them by checking data export options before you sign, negotiating renewal caps, and reviewing licence usage every quarter.
Configured platform. Licence creep and over-customisation. Keep customisations in managed, documented packages, and resist rebuilding the platform's standard features.
Custom. Delivery and maintenance risk. Reduce it by scoping a small first release, owning the source code and infrastructure accounts, insisting on automated tests and documentation, and choosing a partner with a clear support model. Our guide on choosing a software development partner covers what to check.
Frequently asked questions
Is custom software always more expensive than off-the-shelf?
Upfront, almost always. Over three to five years, not necessarily. Per-seat licences, renewal increases and the cost of workarounds can bring the totals close together, especially as user numbers grow. Run a multi-year TCO model with your own figures.
How long does it take to build custom business software?
It depends on scope. A focused first release of an internal tool often takes a few months, while a large system with many integrations takes longer. Phasing the work, with a usable version early and improvements after, reduces risk and gets value to users sooner.
Can we start with off-the-shelf and move to custom later?
Yes, and it's often a sensible path. Using a packaged tool first teaches you what you actually need. Before you commit, confirm you can export your data in a usable format, because migration is the main switching cost.
When does Microsoft Dynamics 365 or Power Apps make more sense than a custom build?
When you're already on Microsoft 365, your processes are structured (records, approvals, reports), and you value built-in security and identity over full control. If the software is a product you sell, or per-user licences would scale badly, custom usually fits better.
Who should own the code if we build custom software?
You should. Your contract should assign the intellectual property to you, and source code and cloud accounts should sit in accounts you control.
Conclusion
Off-the-shelf software is the right answer for most commodity work, and a configured platform covers a lot of structured internal operations. Custom software earns its place where the last stretch is where your advantage lives, or where licences and workarounds cost more over time than owning the system would. Decide by process, count costs over five years, and keep the custom layer as small as it can be while still fitting how you operate.
If you'd like a second opinion on your own buy, configure or build decision, book a free 30-minute discovery session and we'll work through the options with you.