Custom software vs SaaS: how to choose the right one for your company

This question comes up in almost every first conversation with a client, whether a startup or an established company just starting to digitize: should we subscribe to a ready-made app (SaaS), or build our own software?

The honest answer is "it depends," but choosing between custom software and SaaS doesn’t have to be confusing. Below is the framework we use, along with a worked cost example and a list of questions to ask vendors.

The short answer

Use SaaS for processes that look the same at every company. Accounting, payroll, email, document storage. There is no benefit to rebuilding something thousands of companies already do the same way.

Build your own for processes that differentiate your business, or processes that don’t fit generic tools without heavy workarounds. Think of how you schedule production, how your field team reports, or the product you actually sell to customers.

Five questions to decide

1. How distinctive is the process?

If your team has to change the very way of working that gives you an edge just to fit the app, that’s a sign SaaS isn’t a good fit. If the change is just a matter of habit, SaaS usually wins.

How to test it: write your core process in five to seven steps, then try running it in a trial version of the app. Flag any step that has to be worked around, e.g. tracked outside the app or done manually. If the step being worked around is the one that matters most to your business, consider custom.

2. What’s the cost over three years?

SaaS looks cheap in month one because it’s billed per user per month. Calculate for three years at your expected user count, not today’s count. The next section walks through a worked example.

3. What does it need to connect to?

An app that can’t talk to your other systems creates duplicate data-entry work. Check whether the SaaS has an open, documented API, and whether the integrations you need already exist or would need to be built.

4. Who owns the data, and how do you leave?

Ask how data is exported, in what format, and what it costs if you cancel. For custom software, make sure the code, access, and documentation are handed over to you, with ownership written into the contract.

5. Who maintains it?

SaaS is maintained by its provider, including security updates. Custom software needs upkeep: updates, fixes, and adjustments as the business changes. Without budget or a team for that, custom software ages faster than you’d expect.

A worked three-year cost example

The numbers below are illustrative, to show how to calculate, not market pricing or a quote. Replace them with figures from your own vendors.

Say a SaaS app costs Rp 250,000 per user per month. For comparison, say building a custom system costs Rp 250 million up front, plus Rp 5 million per month in maintenance.

The pattern is clear. With a small, stable user count, SaaS is cheaper. As the user count grows, SaaS cost keeps climbing while custom cost stays relatively flat. The break-even point differs for every company, and that’s exactly what you need to calculate before deciding.

Two things are often missed in this math. First, SaaS add-on modules and integration fees. Second, the time your team spends working around a poor fit, like re-typing data into a spreadsheet. That second cost never shows up on an invoice, but it’s real.

Three examples, three answers

Three hypothetical company profiles show how the five questions above lead to different answers.

• A distributor with 15 office staff. The process is generic: orders, invoices, stock. User count barely changes. The answer is SaaS, with close attention to data export.
• A factory with a distinctive production schedule. Accounting and payroll stay on SaaS. Production scheduling and shift reports are built custom, because that’s where this factory’s way of working differs from others.
• A startup selling an app to its customers. The product itself is custom software. Internal operations like email, finance, and documents run on SaaS, so the team can focus on building the product.

Vendor lock-in, and how to reduce it

Vendor lock-in happens when switching becomes too costly, either because the data is hard to get out, or because the entire process has been built around one app. This risk exists in both SaaS and custom software. With SaaS, you’re locked to the provider. With custom, you can end up locked to whichever vendor built it, if the code and documentation were never handed over.

Three habits reduce it: export your data regularly and keep a copy of your own, make sure the contract states your rights to the data and code, and keep a record of which integrations depend on which specific app.

Quick comparison

The middle path people often forget

The choice doesn’t have to be either/or. A pattern that often makes the most sense: SaaS for the common core, then a small custom layer on top. For example, keep using an accounting app, while a custom field-report form sends its data straight into that accounting app via an integration. The field team gets a tool that fits their work, and finance never has to re-type anything.

This middle path only works if the SaaS you choose has a decent API. So question three above often ends up being the deciding factor.

Questions to ask vendors before signing

For SaaS providers

• How does pricing change if the user count doubles?
• Is there an API, and what are its limits?
• How do we export all our data, and in what format?
• Where is the data stored, and is it used for anything else? If the service uses AI, these seven questions about AI policy apply here too.

For custom software vendors

• Who owns the code, design, and server access once the project is done?
• What documentation is handed over, and can another team pick it up later?
• Who responds to issue reports after launch, and how fast?
• How are future users involved before the system is built?

That last question is often treated as an afterthought. Yet custom software built without involving its users risks the same fate as software that gets bought and then never used.

Signs you chose wrong

• The team keeps a companion spreadsheet next to the app because some data doesn’t fit.
• Subscription cost keeps rising every time headcount grows, while feature usage stays the same.
• Custom software has never been updated since launch, and only one person understands how it works.
• Exporting data requires a support ticket and a multi-day wait.

Frequently asked questions

Should startups always start with SaaS?

For internal operations, almost always yes. For a product you sell to customers, that product itself is the custom software. The real decision is which parts you build yourself and which parts run on off-the-shelf services.

How long does it take to build simple custom software?

It depends on scope. An internal system with one core workflow can be usable within a few weeks if the scope is kept tight. Start with the single most-used workflow, not a full feature list.

What if we’re already stuck with a SaaS tool that doesn’t fit?

Start by exporting and cleaning up your data, then find the part of the process that most often forces your team out of the app. Often a single small custom layer on that part is enough, without abandoning the SaaS entirely.

Is custom software always more expensive?

Up front, yes. Over three years, not necessarily. The more users and the more distinctive the process, the more likely custom software ends up cheaper. Run the numbers with your own figures before deciding.