About five years ago, at a multinational company, I was in the middle of an ambitious project: building internal tools that automated AWS processes, simplified day-to-day operations, and even handled backups — at a time when AWS Backup didn’t even exist yet.
It was exactly the kind of thing that excited me. Build, solve, deliver.
But one day my manager pulled me aside and asked a simple question that stuck with me ever since:
“If you build it, you also have to maintain it. How much does maintaining a solution actually cost?”
That question was important. It made me realize that maintenance isn’t just about making something work once. It’s about updating, adjusting features, fixing issues, and evolving continuously. Recurring cost, not a one-time effort.
For years, that thinking shaped many of my decisions: buy when it’s not core business. Outsource maintenance. Focus on what really matters.
But recently, I started questioning that logic.
Evaluating a SaaS has become more expensive than it looks
When you decide to buy a SaaS tool, it’s rarely a straightforward decision. The process involves:
- Negotiation and contract review
- Internal alignment conversations
- Initial deploy and configuration
- Testing and validation
- Deep understanding of the tool
- Security assessment
- Integration with existing systems
- Adjustments and customizations
And the most ironic part: many of these tools are, at their core, just abstractions of the cloud APIs you already know and have been using for years.
Recently (2026), I went through a situation where the time I estimated for a SaaS POC was clearly greater than what it would take to build the solution internally.
That brought me back to the original question — but from a different angle.
From an SRE perspective, this evaluation process is essentially toil: manual, repetitive work that doesn’t scale and doesn’t deliver direct value. And in every maturity cycle, the goal is to eliminate it or reduce it.
What changed in the cost of building
Before, even if you knew how to build something, the maintenance cost was high. Today, that scenario is shifting — fast.
With the advancement of:
- Better practices and consolidated patterns — templates, reusable modules, well-structured IaC
- Pipeline automation — CI/CD, automated testing, continuous deployment
- AI and agents — tools that accelerate development, generate code, review, document
- Internal skills and frameworks — well-defined context that reduces the learning curve and rework
Building and maintaining internal solutions has become far more accessible. The delta between “buy” and “build” is shrinking.
And here’s a direct point: if you already have the technical knowledge, defined best practices, clear functional and non-functional requirements, and a controlled environment — the logic of “buy because it’s not core business” needs to be revisited.
From a toil elimination standpoint, building internally may actually be the most efficient path. You control the lifecycle, integrate without friction, and reduce dependency on third parties.
The comparison every team should run
Consider a SaaS tool that costs $100,000/year.
Now compare that to the engineering cost of dedicating 20 hours per week over a year:
| Profile | Estimated Hourly Rate | 20h/week × 52 weeks |
|---|---|---|
| Junior Engineer | ~$30–50 | ~$31k–52k/year |
| Mid-level Engineer | ~$60–90 | ~$62k–94k/year |
| Senior Engineer | ~$100–150 | ~$104k–156k/year |
These numbers aren’t exact — they vary by region, contract type, and seniority. But they spark important reflection:
- What does engineering time actually cost?
- How much of that time would it take to build an equivalent — or good enough — version?
- Is that cost one-time (build) or recurring (maintenance)?
- After it’s built, does the cost tend to drop or grow?
- Does the SaaS actually reduce effort — or does it just shift work to a different type of operation?
In SRE, we call this Total Cost of Ownership (TCO). It’s not just the license fee: it includes integration cost, support overhead, customization effort, vendor lock-in risk, and the human effort required to operate the tool day to day.
The variable nobody wants to admit
There’s one factor that complicates the equation: team capability.
I have experience and I know what I’m doing. I can build and maintain solutions efficiently. But I can’t assume that everyone who will maintain that solution has the same level of knowledge.
Many times, they have expertise in a different domain — and that’s perfectly valid.
A well-chosen SaaS can be more accessible for teams with less technical specialization. It abstracts complexity, provides support, and reduces dependency on a single engineer who knows the system inside and out.
On the other hand, a poorly chosen SaaS can create invisible dependency: the team doesn’t understand what’s underneath, can’t debug, and when something breaks, they open a ticket and wait.
The decision needs to consider:
- What is the technical level of the team that will operate this?
- Is there a risk of knowledge concentration in a single person?
- Does the SaaS reduce real complexity — or just hide it?
- In case of an incident, who resolves it? How fast?
This is about observability and control: two core SRE values. You need to understand what’s happening inside your system — whether it was built or bought.
When to buy and when to build
There’s no universal formula. But some questions help clarify the decision:
Consider buying when:
- The tool solves a complex problem outside the team’s domain
- Build time clearly exceeds the SaaS evaluation process
- The team lacks the technical capacity to maintain the solution
- There’s mature support, SLA, and ecosystem behind the product
Consider building when:
- You already know the underlying APIs and the tool is essentially an abstraction of them
- The SaaS evaluation process consumes more time than development would
- You have clear control over requirements and the environment
- Maintenance can be automated and knowledge can be documented
- The recurring SaaS cost isn’t justified by the value delivered
The new reality
What’s becoming clear is that we’re no longer just talking about “buy because it’s not core business.”
We’re in a new reality where, even for non-core solutions, it can be faster and cheaper to build — especially when you have the technical context, a controlled environment, and the right tools.
And as AI, automation, and mature frameworks keep advancing, that balance will keep shifting.
The question is no longer “build vs. buy.” It has become:
“Given the real cost of each path, which one delivers more value to my team now — and over the long run?”
Sometimes the answer is to buy. Sometimes it’s to build. But the decision needs to be intentional, not automatic.
If you want to go deeper on building and operating infrastructure solutions with quality and resilience, check out the training at mugnos-it.com — practical content for engineers working with cloud, platform, and reliability.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
