HMDeveloper
All articles
sistemas
sistemasconsultoriapmes

Custom system or SaaS: when each one pays off

A decision framework for small business owners: when SaaS solves it, when a custom system pays for itself, and the hybrid zone almost nobody considers.

I often get a question that sounds technical but is really about business: "is it better to subscribe to a SaaS or build a system from scratch?"

The answer, like almost everything in software engineering, is "it depends." But "it depends" without criteria is useless. What follows is the framework I use to help a client decide — based on systems I have built on both sides.

Rule 1: start with SaaS until the process hurts

If you are just getting started and your process fits inside a SaaS, use the SaaS. Seriously.

SaaS gives you a working system in hours, with automatic updates, no server to maintain, and no developer to hire. You pay a monthly subscription and discover whether the process actually needs software before investing in building.

The time to leave SaaS is not when it is imperfect — it is when the cost of working around the limitation exceeds the cost of building. If you spend two hours a day exporting a spreadsheet from the SaaS and importing it into another system, the math has already flipped.

Rule 2: custom when the business rule is the competitive advantage

SaaS solves generic processes well. It does not solve what makes your business different.

I built a multi-tenant SaaS platform for electronic real-estate registration where the business rule was exactly the client's competitive advantage. The real-estate registration flow in Brazil involves notaries, banks, buyers, sellers, and the National Registry Operator — each with specific legal requirements, regulatory deadlines, and different communication formats. No generic SaaS covers that.

When the rule that makes your business money is not supported by any SaaS on the market, building is the only option. And in that case, building is an investment, not a cost.

Rule 3: custom when the integration is the product

If the value of your system lies in connecting systems that were not built to talk to each other, SaaS solves the wrong end.

A multi-tenant SOAP integration gateway I built connected dozens of tenants to a national registry system, each with different credentials and data schemas. The product was not the CRUD — it was the reliable integration, with a token pool, encrypted credentials, and asynchronous workers that processed 13 message types in parallel. No SaaS offers that as a service, because the secret is in the domain-specific orchestration.

Rule 4: custom when the per-seat cost exceeds a small team

SaaS charges per user. If you have three people using it, any SaaS fits the budget. If you have 200, the per-seat cost multiplies fast.

A custom system with 200 users costs the same as one with 3 — the cost is development and infrastructure, not per-person licensing. The math is: annual SaaS cost × number of users vs. build cost + annual maintenance. When the second is lower than the first, building pays for itself in months.

The hybrid zone almost nobody considers

Between pure SaaS and a from-scratch system, there is a middle ground that solves more cases than it seems: SaaS as the core + custom integration at the edges.

You keep the SaaS for what it does well (CRM, email marketing, accounting) and build the layer that connects these systems to each other and to your business's specific rules. The cost is a fraction of a complete system, and the result is an ecosystem that operates as if it were integrated.

This model worked well in the business platforms I built, where finance talked to academics, academics to sales, and sales to the payment gateway — each module using the right tool for its domain, connected by a custom orchestration layer.

Where it breaks

A custom system without documentation is technical debt with interest. If only one person knows how it works, the system is as fragile as that person's availability. The build cost includes the cost of documentation — and that is non-negotiable.

SaaS without a clear SLA also breaks. If the SaaS goes down for eight hours on a business day, your business stops with it. Read the SLA before signing — and if there is no SLA, treat it as a system that can disappear.

If you are on the fence between SaaS and a custom system, tell me about your context. I will help you do the math with your business numbers, not portfolio numbers.

I work with teams adopting AI agents in their day-to-day engineering. If that is your situation, let us talk.

See consulting