Custom software vs SaaS: when to choose each
TL;DR: The costliest mistake in the 'custom vs SaaS' decision isn't choosing wrong: it's choosing late, once you already have three different SaaS tools glued together with Zapier and an Excel orchestrating everything. The right question isn't 'which is cheaper?', it's 'what percentage of my critical processes is really standard?'. If more than 80% is standard, SaaS wins almost always. If less than 60% is, custom wins when amortized over 5 years. Between 60% and 80% is the zone where the decision depends on subtler variables: data ownership, iteration speed, and vendor dependency.
The most frequent conversation with new clients starts like this: “we have five SaaS tools that no longer talk to each other, we pay 800 EUR/month, and at the end of the day there’s a central Excel orchestrating everything. What do we do?”. And, the same month at a different company, the opposite question: “we have custom software from 12 years ago that cost a fortune to maintain, and now there’s a SaaS that does almost the same for 30 EUR/user. Should we migrate?”. Both questions are legitimate. Both usually have counterintuitive answers.
We don’t defend either option on principle. We use both: custom with clients, SaaS in our own products. What follows is the matrix we apply when a client asks which one fits their case. The criteria that actually decide the outcome in practice, not the textbook ones.
The question that matters
It’s not “which is cheaper?”. Nor “which is more modern?”. It’s this: what percentage of my critical processes is really standard?
By “standard” we mean: the process is done the same way in another 100 companies in your sector, it’s described in management books, and SaaS tools cover it well.
- More than 80% standard: SaaS wins almost always. You pay for a ready-made product that thousands of companies use. The economies of scale are unbeatable.
- Less than 60%: custom wins over 5 years, even if the upfront investment is 5-10× higher. Any SaaS will force you to customize, integrate, or replace so much that the hidden cost eats up the savings.
- Between 60% and 80%: grey zone. There the subtle variables we look at near the end take over.
And the costliest mistake is usually choosing late, when you already have three SaaS tools glued together with Zapier and an Excel orchestrating everything. Migrating from there in any direction costs three times as much.
When SaaS wins
When these conditions hold together:
-
Your processes are your sector’s processes. You sell B2B with a typical commercial cycle, you keep accounts on a general chart, you track time under standard rules, you manage inventory with regular SKUs and warehouses. If your day-to-day looks like your competitors’, there’s a SaaS for it.
-
Small team (under 30-50 users). Per-user cost is the worst multiplier in the SaaS model. Up to a certain size it offsets the lack of upfront investment. Past 100 users, the math flips.
-
You have no technical team to maintain the system. Without in-house developers or a trusted partner, the hidden cost of custom software (patches, hosting, monitoring, evolution) eats the ROI.
-
You need to operate now. A SaaS launches in weeks. Custom takes months. If operational urgency weighs more than functional perfection, SaaS wins without discussion.
-
You have no operational differentiation to defend. If your edge comes from the commercial side, brand, or service, optimizing internal software doesn’t move the needle. SaaS gets the problem out of your way.
SaaS we recommend not fighting: CRM (HubSpot, Pipedrive), email marketing (Mailchimp, Brevo), basic accounting (Holded, Quipu, Xero), document management (DocuWare or Notion for simple cases), support (Intercom, Crisp).
When custom wins
When any of these scenarios shows up:
-
Specific processes that give you a competitive edge. If your way of manufacturing, distributing, installing, or serving is what differentiates you, locking it into a standard SaaS levels you with competitors who pay for the same product. We have clients where the installer scheduling algorithm or the quote-approval flow is the advantage. That doesn’t fit in a catalog SaaS.
-
Deep integrations with existing systems. If your ERP is 15 years old, integrating a SaaS usually ends in nightly CSV import/export. Custom reads and writes in real time, and that changes what’s operationally possible.
-
High user volume. When you pay 30 EUR/user × 200 users = 6,000 EUR/month = 72,000 EUR/year, the math flips. An upfront investment of 100,000-150,000 EUR pays off in 2-3 years just on license savings.
-
Workflows the SaaS doesn’t support and customizing is impossible or expensive. Some SaaS tools are extensible, others aren’t. If you need a new field, a non-standard calculation, or a different approval flow and the SaaS lets you do it in one click, perfect. If it pushes you into a pricey Enterprise plan or an add-on that costs the same again, custom starts to make sense.
-
Data ownership and strategic portability. If your data is the asset, depending on a foreign SaaS that stores it outside the EU can become an operational, legal (GDPR), or strategic (in a sale or M&A it matters) problem. Custom software with hosting you control removes that dependency.
-
Specific regulation the SaaS doesn’t cover. In the Spanish market: e-invoicing with sector-specific requirements, time-tracking with collective-agreement quirks, document retention by sector. Other EU markets have analogous statutes (Germany’s BAG ruling on time tracking, France’s Code du travail). If you need to guarantee compliance with local nuances, dedicated software does it better than any generic SaaS.
The most expensive trap: the “almost” SaaS
The costliest anti-pattern we see in SMBs is the SaaS that almost covers the process. It covers 80%. The remaining 20% gets solved like this:
- A parallel Excel that goes in and out of the SaaS via copy-paste.
- Or a free-text field where the team writes structured data that no one can later exploit.
- Or a custom integration that costs as much as half a custom system.
Three years later, you find yourself here:
- 4 different SaaS tools in your stack, all with monthly subscriptions growing.
- 8 Zapier flows orchestrating between them.
- 3 master Excels that “can’t be touched” because nobody remembers who built the formulas.
- IT spends more time maintaining integrations than improving processes.
- Real monthly cost is higher than amortizing a custom system would be.
Symptoms you’re in this trap:
- “We have a weekly call to reconcile discrepancies between SaaS A and SaaS B”.
- “That information is in the SaaS, but we pull it manually every month”.
- “The integration we built back then hasn’t worked since the last update and nobody knows how to fix it”.
- “When someone new joins, it takes them three weeks to learn all the tools”.
- “The data is here, but that report can’t be generated because the SaaS doesn’t allow it”.
If three or more sound familiar, the problem is structural, not vendor-specific. You need a custom core that orchestrates the rest. We cover the parallel decision in Modernizing a legacy ERP: when to migrate and when not to; it usually shows up next to this one.
The grey zone: between 60% and 80%
When processes sit in that range, the decision is settled by five subtle variables:
| Variable | Pushes toward SaaS | Pushes toward custom |
|---|---|---|
| Iteration speed | Change every 6-12 months | Change monthly or quarterly |
| Data ownership | Non-sensitive, non-strategic data | Data is the asset |
| Technical team available | Zero in-house capacity | Internal team or technical partner |
| Use horizon | Less than 3 years | More than 5 years |
| User volume | Small team (<30) | Large team (>100) |
None decides on its own. It’s the sum. When three or more point the same way, that’s the answer.
The hybrid model: standard SaaS + custom modules
In many cases the right answer is to combine both: SaaS for commodity processes (CRM, accounting, email, support) and custom modules where real differentiation lives.
Example we see repeatedly with clients:
- CRM: SaaS (HubSpot or Pipedrive). Standard goes here.
- Accounting: SaaS (Holded, Quipu, or Xero).
- Operational core: custom software (sector-specific project management, scheduling, product configurator).
- Integration layer: a REST API that syncs critical data in both directions.
The model works if there’s architectural discipline: the core is the system of record, the SaaS is satellite, never the other way around. If you set it up with the SaaS as system of record and custom modules orbiting around it, you’ve recreated the “almost SaaS” trap with extra steps.
What about our case? Power Time
To make it concrete with a close example: we built Power Time, a SaaS for time-tracking. Why SaaS and not custom? Because the problem (complying with Spanish RD-Ley 8/2019 time-tracking law) is as standard as it gets. The law says the same thing for everyone, technical criteria are identical, and building bespoke time-tracking is shooting flies with a cannon.
The custom software services we deliver to clients are the opposite: specific processes, integrations with a 15-year-old legacy ERP, workflows no standard SaaS will ever have.
We apply the same matrix honestly: SaaS where the process is commodity, custom where there’s differentiation.
How to decide in your case
If the decision is on your desk right now:
- Map your 10 most critical processes. Tag each one as “industry standard”, “specific to my company”, or “in-between”.
- For the standard ones: pick the best SaaS on the market and close that decision. Stop second-guessing.
- For the specific ones: assess whether they justify custom or whether you can live with the closest SaaS plus an organizational workaround.
- For in-between ones: apply the grey-zone matrix. When in doubt, start on SaaS, prototype the process, and migrate to custom only if real demand justifies it.
- Decide the system of record on day one. Where the truth lives. Everything else syncs from there, not the other way around.
If you want a second opinion on your specific map, let’s talk. Half an hour is usually enough to see which blocks justify which decision, without getting into pricing.
Resources
- Modernizing a legacy ERP: when to migrate and when not to: the parallel decision.
- VisibleSoft services: what custom software projects we take on.
- Power Time: our time-tracking SaaS (example of SaaS where it makes sense).
- Book a free diagnostic
Frequently asked questions
Which is cheaper over 5 years?
It depends on team size and customization level. SaaS is cheaper if your team is small (under 30 users) and processes fit without customization. If you have more than 100 users or need extensive customization, custom software usually comes out cheaper over 5 years, although the upfront cost is 5 to 10 times higher.
What if processes change in the future?
That's exactly where custom software shines: what changes, you change. With a SaaS, you depend on the vendor's roadmap and your subscription tier. If your business operates in a sector where processes evolve quickly (changing regulation, new markets, M&A), custom offers faster adaptation.
Can I start with SaaS and migrate to custom later?
It's the most common path and usually works well if you plan data ownership from day one. What kills these projects is discovering that your 3 years of history on the SaaS sit in a proprietary format with no functional export. Before choosing a SaaS, verify: documented export API, full downloadable backup, and contractual terms on data portability.
Are there in-between options?
Yes. A strong option: SaaS for the standard stuff (CRM, accounting, email) plus custom modules for the differential, connected via API. Another is low-code/no-code (Airtable, Bubble) to prototype quickly and migrate to custom when the process is validated. The 'pure' SaaS-only or custom-only stance is rare in companies that actually work well.