Sooner or later every business outgrows spreadsheets and notebooks. Accounting, inventory, appointment booking, customer management or online sales: eventually you need software. And the same question comes up every time: do we build it ourselves, buy an off-the-shelf product, or subscribe to a SaaS service?
The right answer depends on the type of business, the budget and, above all, on what role that software plays in how you compete. This article is a simple framework for making that decision.
Short answer: For generic functions like accounting, payroll, email and project management, a SaaS subscription or off-the-shelf software is almost always the more sensible choice for a small business. Custom software is only justified for the part that is your competitive core and that ready-made tools don't support. Either way, calculate the total cost over three years and test how to get your data out before you sign.
What the three options actually mean
Build: you, or a contractor, write software specifically for your business. The code is yours, you have full control, and you carry full responsibility.
Buy: you purchase a perpetual license for ready-made software and install it on your own server or computers. Installed accounting and inventory packages are the typical example. There is usually a separate annual fee for support or updates.
Subscribe (SaaS): the software runs on the vendor's servers, you use it through a browser or app, and you pay monthly or yearly. Installation and maintenance are the vendor's job, but your data lives on their servers too.
The boundaries aren't always sharp. Sometimes a SaaS product is combined with a few custom extensions, or open-source software is installed on your own server and lightly customized. But for thinking the decision through, these three categories are enough.
The real cost: total cost over three years
The biggest mistake in this decision is comparing day-one prices. Custom software looks expensive on day one and a monthly subscription looks cheap, but the right decision comes from the total cost of ownership (TCO) over several years. Three years is a reasonable window: short enough to estimate, long enough for the hidden costs to show up.
List these items separately for each option:
| Cost item | Build | Buy | Subscribe |
|---|---|---|---|
| Upfront cost | Development, usually the largest figure | License | Usually low or zero |
| Recurring cost | Maintenance, bug fixes, changes | Annual support and updates | Monthly or yearly subscription, per user |
| Infrastructure | Server, domain, backups | Server or computers, backups | Usually included in the subscription |
| Setup | Testing and training | Installation, data migration, training | Data migration, configuration, training |
| Your own team's time | High: meetings, testing, decisions | Medium | Low to medium |
| Exit cost later | Low, the code is yours | Medium | Sometimes high, depending on data export |
A few things that usually get left out:
- Custom software isn't finished at handover. The operating system, the programming language and the libraries get updated, business needs change and bugs turn up. Budget for maintenance every year; putting zero in that row means the estimate is wrong.
- Subscriptions grow with you. Most services charge per user, per volume or per transaction. Price it for the size you'll be in three years, not today.
- Your own time is a cost too. Building custom software takes many hours from managers and staff: explaining requirements, testing and making decisions.
- Account for inflation and exchange rates. If a cost is tied to a foreign currency or to annual price increases, run the three-year estimate with a pessimistic scenario as well.
Vendor lock-in and getting your data out
Software can be replaced; data can't. The key question for any choice is: if we wanted to leave tomorrow, how, and in what format, would we get our data back?
- With SaaS, check whether there is a complete export in a standard format (CSV, Excel, JSON or API access) or only fragmented reports. An export that gives you the customer list but not the order history effectively keeps you locked in.
- With bought software, find out which database stores the data and whether it can be read without the vendor's software.
- With custom builds, the code and database are yours, but only if you actually receive them. State explicitly in the contract that the source code, server access and documentation are handed over to you.
A practical test: before signing, or during the trial period, do one full export and check that it's genuinely usable.
Who maintains it?
This question rarely comes up in the sales meeting and causes the most trouble later.
When you build
If a contractor built the software, who fixes bugs after handover? Do you have a support contract? If that contractor is no longer available, can another developer understand the code? Software built with mainstream technologies and at least minimal documentation greatly reduces this risk.
When you buy
Who installs the updates? Who looks after the server or computer the software runs on? Installed software that hasn't been updated in years is a risk both for security and for compatibility with newer operating systems.
When you subscribe
Technical maintenance belongs to the vendor, and that is the biggest advantage of this model for a small business. But configuration, users and permissions are still yours, and someone on the team has to own them.
Who is responsible for security and backups?
A simple rule: responsibility for security never fully transfers to the vendor. Even with the best SaaS service, weak passwords, a departed employee whose access was never removed, or one account shared among several people are your problem.
| Area | Build | Buy | Subscribe |
|---|---|---|---|
| Server security and updates | You or the contractor | You | Vendor |
| Application code security | Contractor | Vendor | Vendor |
| Users, passwords and permissions | You | You | You |
| Backups | You | You | Vendor, but an independent export is on you |
| Testing backup restores | You | You | Ask, and test yourself as far as you can |
Take one point about backups seriously: a backup whose restore has never been tested is just a hope. Every few months, test a restore in a separate environment. With SaaS too, even if the vendor takes backups, keep a periodic independent export of your data yourself.
When is custom software justified?
The general rule: don't build what every business does the same way. Accounting, payroll, email, file storage and project management are nearly identical for everyone, and mature off-the-shelf software exists for all of them. Rebuilding these usually means paying more for a worse result.
Custom software is justified when it is your competitive core, the thing that sets you apart from competitors:
- A pricing, scheduling or resource-allocation method that is specific to you and that off-the-shelf software doesn't support.
- The experience customers recognize you by and choose you for.
- A process that, if run on a generic tool, would force you to work the way your competitors do and lose your edge.
Even then, it's better to build only that core and connect everything else to ready-made tools. A custom booking system doesn't need its own accounting module.
Warning signs that building may not be the right choice:
- You can't say in one sentence why off-the-shelf tools don't work for you.
- You haven't written the problem down precisely yet (covered in write the problem down before you write the code).
- You have neither a budget nor a plan for maintenance after handover.
Decision table
| If… | Usually the right option |
|---|---|
| The function is generic and everyone does it the same way | Subscribe |
| You have no technical team and don't want to be responsible for a server | Subscribe |
| A legal or contractual requirement says the data must stay with you | Buy, or build on your own infrastructure |
| Your internet connection or access to external services isn't reliable | Buy and install locally |
| The software is your competitive core and ready-made tools don't support it | Build |
| Your needs are 80% generic and 20% specific | Subscribe or buy, plus custom development for that specific part |
| You're not yet sure your way of working will stay the same | Subscribe with a short commitment until your process settles |
Questions to ask every vendor
Whether it's a development contractor, a software vendor or a SaaS provider, bring this list and get the answers in writing:
- In what format, and how completely, can our data be exported? Can we try it right now?
- If the contract ends or you go out of business, what happens to our data, and for how long is it available?
- How does the price change with more users, more data or more transactions? How are annual price increases determined?
- How often are backups taken, where are they stored, and when was a restore last tested?
- If something goes wrong, through what channel and how quickly do you respond?
- Who on your side has access to our data?
- Is two-factor authentication available, and can we define permission levels for users?
- (For builds) Will the source code, server access and documentation be handed over at the end? What technology will it be built with?
- (For purchases) Until when will updates be provided, and what do they cost?
If a vendor won't give clear, written answers to these questions, that is your answer.
Frequently asked questions
What is SaaS, and how is it different from installed software?
SaaS is software that runs on the vendor's servers, which you use through a browser or app for a monthly or yearly fee. With installed software you buy a license and install it on your own server or computers, so maintenance and backups are your responsibility too.
Is a SaaS subscription cheaper than building software in the long run?
Not always. A subscription looks cheap on day one but is usually priced per user or per volume and grows with the business, while custom software carries annual maintenance costs after handover. The right comparison is total cost of ownership over three years, at the size you expect to be.
What happens to our data if the software vendor shuts down?
It depends on the contract and the export options. Before signing, ask in what format and for how long data can be exported, do a full export once to confirm it's usable, and with SaaS keep a periodic independent export of your data.
What should a custom software development contract include?
State explicitly that the source code, server access and documentation will be handed over to you, and who fixes bugs after handover and on what terms. Building on mainstream technologies also helps another developer take over if the contractor becomes unavailable.
Is security entirely the vendor's responsibility with SaaS?
No. Server and application security belong to the vendor, but users, passwords, two-factor authentication and removing access for employees who have left remain your responsibility.
Wrap-up
Choosing between building, buying and subscribing isn't a technical decision; it's a decision about cost, risk and responsibility. For generic functions, SaaS or off-the-shelf software is almost always the more sensible choice. Save building for the part that is your competitive core.
In all three cases, calculate the cost over three years rather than for day one, test how to get your data out before you sign, and make clear exactly who owns maintenance, security and backups. Those three questions expose most bad decisions before they become expensive.