Custom Software vs Off-the-Shelf: 8 Questions That Decide It
Custom software vs off the shelf: 8 questions and a 3-5 year cost model in EUR, so you can run your own numbers and see whether to build or buy.

Freelance full-stack developer
- Published
- Reading time
- 14 min
In this post8
Custom software vs off the shelf comes down to one question: which option costs less and works better for your business over the next three to five years, not just the first? Off-the-shelf software wins when your process looks like everyone else's and the subscription plus the workarounds cost less than owning a system. Custom software (bespoke software, if you're in the UK) wins when the process is how you beat competitors, or when seat fees, add-ons and duplicate work grow faster than revenue.
I'm a freelance developer based in Denmark and I build custom software for a living, so weigh my view accordingly. That's why this post gives you a cost model to run with your own numbers, plus a section on when you shouldn't build anything at all.
The short answer
By off-the-shelf I mean a ready-made product you subscribe to or license, which today usually means SaaS. Custom software is built for your business, and you own the code. Here are the eight questions and which way each answer usually points.
| Points to off-the-shelf | Points to custom | |
|---|---|---|
| 1. Is the process your competitive edge? | No, it just has to work | Yes, it's why customers pick you |
| 2. How much does the product cover? | Your key workflows, without workarounds | Only part of it, the rest lives in spreadsheets and email |
| 3. How much will your needs change? | Very little, the process is stable | A lot, and the vendor sets the pace |
| 4. What does buying cost over 3-5 years? | Few users, few add-ons, small workarounds | Many seats, paid add-ons and hours of workarounds |
| 5. What does building cost over 3-5 years? | More than it saves | Less than seats and workarounds combined |
| 6. Who will run it? | Nobody on your side wants that job | You have a developer or a support agreement |
| 7. How locked in will you be? | You can switch without losing much | Your data and processes are stuck |
| 8. How soon do you need it? | Within a few weeks | You can wait a few months for the right fit |
My rule of thumb: if most answers land in the off-the-shelf column, buy and spend the money elsewhere. If question 1 or question 4 lands in the custom column, run the numbers in the cost section before deciding. Those two are the ones that most often flip the decision.
If what you're planning will be used by customers or members, such as a marketplace or a client portal, start with my guide to building your own platform. It also covers no-code as a third route. This post is the general build-vs-buy framework.
Questions about your business
1. Is the process your competitive edge?
Sort your workflows into two piles. The first is the stuff that just has to work: accounting, payroll, email, calendars, invoicing. Every company does these roughly the same way, and no customer chooses you because your bookkeeping is unusual. The second pile is what customers actually pay for: how you schedule jobs, build quotes, match clients with staff or follow up after a sale.
The first pile should almost always be bought. The second is where off-the-shelf software can cost more than its price tag, because it nudges you into working exactly like your competitors.
My take: Write down the three things customers specifically choose you for. If none of them live in the product you're considering, buy it. If one of them does and the product can't handle it your way, that's where custom software starts to earn its keep.
2. How much of the need does the product really cover?
No product fits 100%. The question is what the last stretch costs. You have three ways to close the gap: configure the product, add a plugin or integration, or change your own process. That last one is often the cheapest, and sometimes the healthiest, because a widely used product reflects how many other companies handle the same job.
Test it properly. List your ten most important workflows and run them through two or three products during the free trial, using real data. For each workflow, note whether it works, works with a workaround, or doesn't work at all.
My take: If the product handles the key workflows and the gaps are about convenience, buy it. If the gaps sit in your core flow, or force daily workarounds, the product costs more than its pricing page suggests. Many workarounds end up in a spreadsheet next to the system. If that sounds familiar, check the signs it's time to replace Excel with custom software.
3. How much will your needs change in the next 3-5 years?
With off-the-shelf software, the vendor decides what the product does next year. The feature you're missing might ship next year or never, and existing features sometimes move to a pricier tier. If you expect new products, new markets, an acquisition or a new business model, that's a real constraint.
Custom software changes whenever you want, but every change costs developer hours. The flexibility isn't free. You just pay for it yourself.
My take: If your process is stable and similar to the rest of your industry, the vendor's roadmap works in your favor, since every customer shares the cost of improvements. If you expect big changes, pick a product with an open API (a documented way for other software to read and write its data). That keeps the door open to building around it later.
Questions about cost
This is where many build-vs-buy decisions go wrong: the first year's subscription gets compared with a development quote, and the subscription wins. The fair comparison is total cost of ownership over three to five years: everything you pay, including your own team's time.
4. What does off-the-shelf really cost over 3-5 years?
Count every line, not just the subscription:
- Seats: per-user, per-transaction or usage-based pricing. Multiply by the headcount you expect in three years, not today's.
- Price rises: procurement company Vertice puts current SaaS inflation at 13.2% in its SaaS Inflation Index 2026 report, almost five times the general inflation rate across G7 countries. That's an average across many products, so check what your contract says about price changes.
- Setup and training: onboarding fees, a consultant or implementation partner, and your team's hours.
- Add-ons: extra modules, a higher tier just to get API access, and glue tools like Zapier or Make.
- Workarounds: double entry, exports to Excel and manual checks. Put hours and an internal hourly cost on them.
- Switching later: getting your data out and migrating it if you change products in a few years.
The formula: seat price × users × 12 × years + setup + add-ons + workarounds (hours per week × internal hourly cost × 46 working weeks × years).
My take: Workarounds are the line people most often leave out, and the one that most often decides the outcome. Ask the people who use the system every day, not the person who signed the contract.
5. What does custom software really cost over 3-5 years?
The quote is only part of it:
- Development: hours times rate. Lancebase puts freelance full-stack developers in Western Europe at around €75-120 an hour. Denmark sits higher: LønRadar lists DKK 800-1,200 (roughly €105-160) an hour excl. VAT for senior freelance IT consultants in 2026. In my estimate, a business system with several workflows and one to three integrations often takes 200-500 hours. I break down custom software cost from small tool to full system in a separate guide.
- Discovery: a scoping phase before the build, so the scope is clear before anyone commits to a price.
- Your team's time: workshops, testing and cleaning up the data you'll migrate.
- Maintenance: framework and package updates, security patches, small fixes. Budget roughly 15-20% of the build cost per year.
- Hosting: for a smaller system, often well under €100 a month.
- New features: whatever you'll want once people start using it. Budget for that separately.
My take: Custom software doesn't get cheaper over time on its own. It only beats off-the-shelf when your seat count grows, or when it removes work you're currently paying for in hours.
Worked example: 10 and 25 users over 3 and 5 years
These numbers are chosen for illustration and exclude VAT. A company with 10 users is looking at a product priced at €35 per user per month. Setup and training cost €2,500, add-ons and an integration tool €50 a month, and staff spend 2 hours a week in total on workarounds, costed at €40 an hour over 46 working weeks. The alternative is a custom system built in 250 hours at €100 an hour, with 15% a year for maintenance and €50 a month for hosting.
| Off-the-shelf | Custom | |
|---|---|---|
| Upfront | €2,500 for setup and training | €25,000 (250 hours at €100) |
| Seats or hosting per year | €4,200 (10 users at €35 a month) | €600 for hosting |
| Add-ons per year | €600 | Built in from the start |
| Maintenance per year | Included in the subscription | €3,750 (15% of the build cost) |
| Workarounds per year | €3,680 (2 hours a week) | €0, if the system removes them |
| Total over 3 years | €27,940 | €38,050 |
| Total over 5 years | €44,900 | €46,750 |
With 10 users, off-the-shelf wins clearly over three years and the two are close to even over five. At 25 users the picture changes. Seat fees rise to €10,500 a year, putting off-the-shelf at about €46,840 over three years and €76,400 over five, while the custom system costs roughly the same as before and now comes out cheaper within three years.
Two assumptions move the result most. Remove the workarounds and the off-the-shelf total for 10 users drops to €26,500 over five years, at which point there's no financial case for building. Add a 10% price rise each year, and the €21,000 in seat fees over five years becomes about €25,600.
The example only counts costs. If a custom system can bring in new revenue, say by letting customers order on their own, add that too, but be honest about how uncertain it is.
Questions about running it
6. Who will own and run it?
With off-the-shelf software, the vendor handles hosting, security patches, backups and uptime. You handle configuration, users and data. With custom software, all of that is yours: framework and package updates, backups, monitoring, and someone to call when something breaks. You don't need a developer on payroll, but you do need an arrangement, usually a support agreement with whoever built the system.
GDPR applies either way. If an off-the-shelf product processes personal data for you, you need a data processing agreement (DPA) with the vendor. Many popular SaaS products are American, so also check where your data is stored and whether an EU hosting option exists. With custom software you need a DPA with your hosting provider, and with the developer if they can access live data. This isn't legal advice, so talk to an adviser if you handle sensitive data.
My take: If nobody on your side wants the responsibility and you won't pay for a support agreement, buy. A custom system without an owner decays faster than most people expect.
7. How locked in will you be?
Both routes create dependency. An off-the-shelf vendor controls the price and the roadmap, and can be acquired or retire the product. So check whether you can export all your data in a usable format, and what the contract says about notice for price changes.
With custom software you depend on the developer. You can make that risk small: the code should live in your own repository from day one, the system should be built on a mainstream framework other developers know, and there should be a short written overview of how it fits together. My clients own their code from day one, and you should insist on that whoever you hire.
My take: Lock-in isn't an argument for either side. What matters is whether you have a way out. If you can take your data with you from the vendor, and you own the code to the custom system, the risk is manageable.
8. How soon do you need it, and what does waiting cost?
An off-the-shelf product can often be running within days or a few weeks. A custom business system usually takes a few months from scoping to first version. Both have a price. Wait three months for the right system and the problem keeps costing you in the meantime. Start fast on a standard tool and switch later, and you pay for data migration and for retraining your team.
My take: If it's urgent, start on off-the-shelf and use it to learn exactly what you're missing. That list makes a later custom build smaller and cheaper. Just expect the eventual move of data and habits to take time.
The hybrid option most teams overlook
Many companies end up best served somewhere in between. The accounting system, CRM or booking tool stays, and only the missing piece gets built:
- an integration that syncs data between two systems, so nobody types the same thing twice
- a small internal tool for the one workflow the product can't handle
- a client portal that pulls data from several systems into one view
- an automated report that replaces the one someone assembles by hand every month
You avoid running the generic parts yourself and only pay for code where your business is actually different. I've covered the hybrid route for specific cases in my comparisons of custom booking systems vs off-the-shelf, custom vs white-label customer portals and building vs buying an intranet.
Before you go this way, check three things about the product's API. Can it write data, not just read it? Is it documented? Is it included in your plan, or only on a higher tier? And remember that your integration will need updating if the vendor changes its API.
When each option is the wrong call
Off-the-shelf is the wrong call when
- the product forces you to drop the very thing customers choose you for
- per-seat or per-transaction fees grow faster than revenue
- your team spends several hours a week on workarounds, and the hours keep climbing
- you can't get your data out, and the vendor alone sets the price
Custom software is the wrong call when
- a standard product covers your key workflows and the gaps can be closed by changing the process
- you have few users and small workarounds
- the process still changes week to week, so you'd be building for something that won't exist in three months
- nobody on your side has time to make decisions and test along the way
- the budget covers the build but not maintenance and hosting
If any of that second list describes you, you shouldn't hire someone like me. Your money is better spent choosing the right product and setting it up properly.
Next steps
Go through the eight questions with one or two people who use your systems every day. Run the model with your own numbers over three and five years, and trial two or three products against your ten key workflows. If the answers still point to custom software, you already have what a developer needs for a useful estimate: the workflows, the gaps and what they cost you today.
My page on web apps and platforms explains how I work. You deal directly with me, and I'm also the one writing the code. Larger projects start with a paid, fixed-price discovery phase, so you know the scope and the price before anything gets built, and the code is yours from day one.
Frequently asked questions
Can I customize off-the-shelf software instead of building from scratch?
Yes, many products can be extended through settings, plugins or code that talks to their API. Be careful with heavy customization inside the product itself. It can make every upgrade expensive, because the changes need testing and sometimes rework whenever the vendor ships a new version. Where possible, keep customizations outside the product, in an integration that uses its API.
Is SaaS the same as off-the-shelf software?
Mostly. SaaS is off-the-shelf software you rent on a subscription and use in the browser, with the vendor running it. Off-the-shelf can also mean software you license and have installed, such as an ERP system (the software that runs finance, inventory and orders) set up by an implementation partner. The cost model works for both, but installed systems usually carry a bigger implementation bill.
How long does custom software last?
A system built on a mainstream framework can typically run for many years, as long as it's kept up to date. Frameworks release new versions regularly, and each version only gets security fixes for a limited period, so plan for regular upgrades. Skip them and the system gradually becomes more expensive to change and harder to find a developer for.
Is no-code a third option?
In a sense, yes. No-code tools sit between the two routes: you build it yourself without writing code, but you rent the platform. They work well for prototypes and internal tools with few users, and you can make changes the same day. Pricing usually grows with usage, and if you leave, you can typically take your data but not the app itself.