Buy SaaS or configure software you already own for anything that works the same way in most businesses: accounting, payroll, CRM, email, HR records. Build custom software only for the process that sets you apart from competitors, or where nothing on the market fits well enough and the gap costs you every day. If you already run an ERP such as Odoo, check first whether configuring it covers the need, because that often beats both a new SaaS tool and a custom build.
The question behind the question
"Build or buy" sounds like a cost comparison, but the useful question is: is this process part of what makes customers choose us?
If it isn't, and your invoicing, leave approvals or expense claims work like everyone else's, there is no advantage in owning the code. Buy it, accept its way of working, and spend your effort elsewhere. If it is, such as the way you quote complex jobs, schedule field teams or run a marketplace, then fitting it into someone else's product means working like your competitors. That is where building pays.
Most businesses have one or two processes like that, not ten. The common mistake is to treat every small difference as a competitive advantage and end up maintaining custom code for things a standard product already does well.
A decision framework
- Describe the process, not the software. Who does what, with what data, how often, and what goes wrong today. Tool names come later.
- Sort it: standard or differentiating? Be strict. "We do it slightly differently" usually means standard.
- Check what you already own. Your ERP, CRM or helpdesk may already do it once it is configured. This step is skipped surprisingly often.
- Check the market. Shortlist two or three products. Test them with your real cases, including the awkward ones.
- Map the integrations. Where does the data come from and where must it go? A tool that doesn't connect to your core systems creates manual work.
- Compare total cost of ownership over several years, using the drivers below, not the first-year price.
- Decide how you would leave. Before signing up or starting a build, know how you would get your data out.
What drives total cost of ownership
We won't put figures here, because they depend on scope, team and market. But the drivers are the same everywhere, and people tend to underestimate the same ones.
| Driver | Buying SaaS | Building custom |
|---|---|---|
| Up-front cost | Low: setup and onboarding | High: design, build, testing |
| Recurring cost | Subscriptions per user or usage, which grow with you and rise at renewal | Hosting, monitoring, security updates, bug fixes |
| Change | Free if the vendor builds it; impossible if they won't | Every change is paid development work |
| Integration | Limited to the vendor's API and its rate limits | You build and maintain every connection |
| People | An admin who knows the product | Developers who know your code, ideally more than one |
| Risk | Vendor price rises, feature removal, acquisition, shutdown | Key-person dependency, falling behind on security updates |
| Exit | Data export quality decides how painful leaving is | You own the code, but also its technical debt |
Two costs are missing from most comparisons. The first is the cost of working around the tool: spreadsheets on the side, copying data between systems, staff doing by hand what the software can't do. That is often larger than the licence. The second is the cost of many tools: each SaaS product is cheap on its own, but ten of them means ten logins, ten bills, and data that disagrees between systems.
Integration and lock-in
Lock-in isn't only a SaaS problem, but it looks different in each case.
With SaaS, you are locked in by your data and your processes. Before you commit, check that you can export all of your data, including history and attachments, in a usable format. Check what the API allows and how many calls it permits, and whether webhooks exist so other systems hear about changes. Read the terms on price changes at renewal. For Indian businesses, also check where the data is stored and whether GST invoices and e-invoicing are handled properly or left to you.
With custom software, you are locked in to whoever understands the code. Insist on owning the source code and the hosting accounts, on documentation and automated tests, and on a mainstream stack that other developers can pick up. Our post on choosing a web application stack covers that choice.
The cheapest system to leave is the one whose data you can export completely, whoever wrote it.
When configuring Odoo beats both
There is a third option that the build-or-buy framing hides: configure a platform you already run. Odoo 19 is a good example because it covers so much. The source has 1,385 modules across Community and Enterprise, covering sales, inventory, manufacturing, accounting, HR, projects, helpdesk and more, all on one database.
That matters because many "we need a new tool" requests are really integration problems. A separate SaaS for field service, subscriptions or approvals has to be connected to your customers, products and invoices, and kept in agreement. The same process inside Odoo uses the records that are already there.
Configuration covers more than people expect: Automation Rules (Community) handle "when this happens, do that" logic; Studio (Enterprise) adds fields, views and simple apps without code; and a small custom module is still much less work than a separate application. Our guide to Studio and customisation goes through where each fits.
Configuring Odoo is not the answer when the process is customer-facing and the experience is the product, when the users are outside your organisation in large numbers, or when the requirement fights Odoo's data model. Then build a separate application and connect it to Odoo through its API. For customer-facing work, our post on portals walks through that decision.
How we usually advise
- Standard back-office process: configure the ERP if you have one, otherwise buy.
- Standard process, specialist tool clearly better: buy, and budget for the integration.
- Differentiating process, internal users: extend the ERP first; build only if the data model doesn't fit.
- Differentiating process, customer-facing: build the experience, keep the records in the ERP.
Whichever way you go, write down why, so the decision can be checked in two years' time. If you want a view on a specific process, our Odoo work and our web application work cover both sides, or get in touch.
Questions we get asked
When should a business build custom software instead of buying SaaS?
Build custom software when the process is part of what makes customers choose you, and when no product on the market fits it without costly workarounds. For standard processes such as accounting, payroll, CRM and HR records, buying SaaS or configuring an ERP is almost always cheaper and less risky, because someone else maintains the software and keeps it up to date.
What costs are often missed when comparing build and buy?
The costs usually missed are yearly maintenance and security updates for custom software, subscription growth and renewal increases for SaaS, the integration work to connect either to your other systems, and the hidden cost of staff working around a tool with spreadsheets and manual copying. Compare them over several years, not only the first-year price.
How do you avoid vendor lock-in with SaaS?
Before signing, confirm that you can export all your data, including history and attachments, in a usable format, and test the export. Check the API limits and whether webhooks exist, read the renewal pricing terms, and keep a copy of important data in systems you control. The easier it is to leave, the less locked in you are.
Can Odoo replace several SaaS tools?
Often, yes. Odoo 19 covers sales, CRM, inventory, manufacturing, accounting, HR, projects, helpdesk and more on one database, so a process moved into Odoo uses the same customers, products and invoices without an integration. It fits less well when the users are large numbers of outside customers or the experience itself is the product.