{"id":2898,"date":"2026-05-27T09:30:00","date_gmt":"2026-05-27T09:30:00","guid":{"rendered":"https:\/\/mugnos-it.com\/?p=2898"},"modified":"2026-05-20T12:29:56","modified_gmt":"2026-05-20T12:29:56","slug":"is-it-still-worth-buying-saas-or-should-i-just-build-it","status":"publish","type":"post","link":"https:\/\/mugnos-it.com\/pt\/is-it-still-worth-buying-saas-or-should-i-just-build-it\/","title":{"rendered":"Is It Still Worth Buying SaaS, or Should I Just Build It?"},"content":{"rendered":"<div data-elementor-type=\"wp-post\" data-elementor-id=\"2898\" class=\"elementor elementor-2898\" data-elementor-post-type=\"post\">\n\t\t\t\t<div class=\"elementor-element elementor-element-6e760810 e-flex e-con-boxed e-con e-parent\" data-id=\"6e760810\" data-element_type=\"container\">\n\t\t\t\t\t<div class=\"e-con-inner\">\n\t\t\t\t<div class=\"elementor-element elementor-element-30291da7 elementor-widget elementor-widget-text-editor\" data-id=\"30291da7\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t\n<p>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 \u2014 at a time when AWS Backup didn&#8217;t even exist yet.<\/p>\n\n\n\n<p>It was exactly the kind of thing that excited me. Build, solve, deliver.<\/p>\n\n\n\n<p>But one day my manager pulled me aside and asked a simple question that stuck with me ever since:<\/p>\n\n\n\n<p><em>&#8220;If you build it, you also have to maintain it. How much does maintaining a solution actually cost?&#8221;<\/em><\/p>\n\n\n\n<p>That question was important. It made me realize that maintenance isn&#8217;t just about making something work once. It&#8217;s about updating, adjusting features, fixing issues, and evolving continuously. Recurring cost, not a one-time effort.<\/p>\n\n\n\n<p>For years, that thinking shaped many of my decisions: buy when it&#8217;s not core business. Outsource maintenance. Focus on what really matters.<\/p>\n\n\n\n<p>But recently, I started questioning that logic.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">Evaluating a SaaS has become more expensive than it looks<\/h3>\n\n\n\n<p>When you decide to buy a SaaS tool, it&#8217;s rarely a straightforward decision. The process involves:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Negotiation and contract review<\/li>\n\n\n\n<li>Internal alignment conversations<\/li>\n\n\n\n<li>Initial deploy and configuration<\/li>\n\n\n\n<li>Testing and validation<\/li>\n\n\n\n<li>Deep understanding of the tool<\/li>\n\n\n\n<li>Security assessment<\/li>\n\n\n\n<li>Integration with existing systems<\/li>\n\n\n\n<li>Adjustments and customizations<\/li>\n<\/ul>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>That brought me back to the original question \u2014 but from a different angle.<\/p>\n\n\n\n<p>From an SRE perspective, this evaluation process is essentially <strong>toil<\/strong>: manual, repetitive work that doesn&#8217;t scale and doesn&#8217;t deliver direct value. And in every maturity cycle, the goal is to eliminate it or reduce it.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">What changed in the cost of building<\/h3>\n\n\n\n<p>Before, even if you knew how to build something, the maintenance cost was high. Today, that scenario is shifting \u2014 fast.<\/p>\n\n\n\n<p>With the advancement of:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Better practices and consolidated patterns<\/strong> \u2014 templates, reusable modules, well-structured IaC<\/li>\n\n\n\n<li><strong>Pipeline automation<\/strong> \u2014 CI\/CD, automated testing, continuous deployment<\/li>\n\n\n\n<li><strong>AI and agents<\/strong> \u2014 tools that accelerate development, generate code, review, document<\/li>\n\n\n\n<li><strong>Internal skills and frameworks<\/strong> \u2014 well-defined context that reduces the learning curve and rework<\/li>\n<\/ul>\n\n\n\n<p>Building and maintaining internal solutions has become far more accessible. The delta between &#8220;buy&#8221; and &#8220;build&#8221; is shrinking.<\/p>\n\n\n\n<p>And here&#8217;s a direct point: if you already have the technical knowledge, defined best practices, clear functional and non-functional requirements, and a controlled environment \u2014 the logic of &#8220;buy because it&#8217;s not core business&#8221; needs to be revisited.<\/p>\n\n\n\n<p>From a <strong>toil elimination<\/strong> standpoint, building internally may actually be the most efficient path. You control the lifecycle, integrate without friction, and reduce dependency on third parties.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">The comparison every team should run<\/h3>\n\n\n\n<p>Consider a SaaS tool that costs <strong>$100,000\/year<\/strong>.<\/p>\n\n\n\n<p>Now compare that to the engineering cost of dedicating <strong>20 hours per week<\/strong> over a year:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Profile<\/th><th>Estimated Hourly Rate<\/th><th>20h\/week \u00d7 52 weeks<\/th><\/tr><\/thead><tbody><tr><td>Junior Engineer<\/td><td>~$30\u201350<\/td><td>~$31k\u201352k\/year<\/td><\/tr><tr><td>Mid-level Engineer<\/td><td>~$60\u201390<\/td><td>~$62k\u201394k\/year<\/td><\/tr><tr><td>Senior Engineer<\/td><td>~$100\u2013150<\/td><td>~$104k\u2013156k\/year<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>These numbers aren&#8217;t exact \u2014 they vary by region, contract type, and seniority. But they spark important reflection:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What does engineering time actually cost?<\/li>\n\n\n\n<li>How much of that time would it take to build an equivalent \u2014 or good enough \u2014 version?<\/li>\n\n\n\n<li>Is that cost one-time (build) or recurring (maintenance)?<\/li>\n\n\n\n<li>After it&#8217;s built, does the cost tend to drop or grow?<\/li>\n\n\n\n<li>Does the SaaS actually reduce effort \u2014 or does it just shift work to a different type of operation?<\/li>\n<\/ul>\n\n\n\n<p>In SRE, we call this <strong>Total Cost of Ownership (TCO)<\/strong>. It&#8217;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.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">The variable nobody wants to admit<\/h3>\n\n\n\n<p>There&#8217;s one factor that complicates the equation: <strong>team capability<\/strong>.<\/p>\n\n\n\n<p>I have experience and I know what I&#8217;m doing. I can build and maintain solutions efficiently. But I can&#8217;t assume that everyone who will maintain that solution has the same level of knowledge.<\/p>\n\n\n\n<p>Many times, they have expertise in a different domain \u2014 and that&#8217;s perfectly valid.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>On the other hand, a poorly chosen SaaS can create invisible dependency: the team doesn&#8217;t understand what&#8217;s underneath, can&#8217;t debug, and when something breaks, they open a ticket and wait.<\/p>\n\n\n\n<p>The decision needs to consider:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>What is the technical level of the team that will operate this?<\/strong><\/li>\n\n\n\n<li><strong>Is there a risk of knowledge concentration in a single person?<\/strong><\/li>\n\n\n\n<li><strong>Does the SaaS reduce real complexity \u2014 or just hide it?<\/strong><\/li>\n\n\n\n<li><strong>In case of an incident, who resolves it? How fast?<\/strong><\/li>\n<\/ol>\n\n\n\n<p>This is about <strong>observability and control<\/strong>: two core SRE values. You need to understand what&#8217;s happening inside your system \u2014 whether it was built or bought.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">When to buy and when to build<\/h3>\n\n\n\n<p>There&#8217;s no universal formula. But some questions help clarify the decision:<\/p>\n\n\n\n<p><strong>Consider buying when:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The tool solves a complex problem outside the team&#8217;s domain<\/li>\n\n\n\n<li>Build time clearly exceeds the SaaS evaluation process<\/li>\n\n\n\n<li>The team lacks the technical capacity to maintain the solution<\/li>\n\n\n\n<li>There&#8217;s mature support, SLA, and ecosystem behind the product<\/li>\n<\/ul>\n\n\n\n<p><strong>Consider building when:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You already know the underlying APIs and the tool is essentially an abstraction of them<\/li>\n\n\n\n<li>The SaaS evaluation process consumes more time than development would<\/li>\n\n\n\n<li>You have clear control over requirements and the environment<\/li>\n\n\n\n<li>Maintenance can be automated and knowledge can be documented<\/li>\n\n\n\n<li>The recurring SaaS cost isn&#8217;t justified by the value delivered<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\">The new reality<\/h3>\n\n\n\n<p>What&#8217;s becoming clear is that we&#8217;re no longer just talking about &#8220;buy because it&#8217;s not core business.&#8221;<\/p>\n\n\n\n<p>We&#8217;re in a new reality where, even for non-core solutions, it can be faster and cheaper to build \u2014 especially when you have the technical context, a controlled environment, and the right tools.<\/p>\n\n\n\n<p>And as AI, automation, and mature frameworks keep advancing, that balance will keep shifting.<\/p>\n\n\n\n<p>The question is no longer &#8220;build vs. buy.&#8221; It has become:<\/p>\n\n\n\n<p><em>&#8220;Given the real cost of each path, which one delivers more value to my team now \u2014 and over the long run?&#8221;<\/em><\/p>\n\n\n\n<p>Sometimes the answer is to buy. Sometimes it&#8217;s to build. But the decision needs to be intentional, not automatic.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p>If you want to go deeper on building and operating infrastructure solutions with quality and resilience, check out the training at <a href=\"http:\/\/mugnos-it.com\/pt\/\">mugnos-it.com<\/a> \u2014 practical content for engineers working with cloud, platform, and reliability.<\/p>\n\n\n\n<p>Cheers,<\/p>\n\n\n\n<p>Douglas Mugnos<\/p>\n\n\n\n<p>MUGNOS-IT \ud83d\ude80<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t<div class=\"elementor-element elementor-element-eed7af2 e-flex e-con-boxed e-con e-parent\" data-id=\"eed7af2\" data-element_type=\"container\">\n\t\t\t\t\t<div class=\"e-con-inner\">\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"<p>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 \u2014 at a time when AWS Backup didn&#8217;t even exist yet. It was exactly the kind of thing that excited me. Build, solve, deliver. [&hellip;]<\/p>","protected":false},"author":3,"featured_media":2899,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2898","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/mugnos-it.com\/wp-content\/uploads\/2026\/05\/ChatGPT-Image-20-de-mai.-de-2026-07_58_39.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/comments?post=2898"}],"version-history":[{"count":4,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2898\/revisions"}],"predecessor-version":[{"id":2903,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2898\/revisions\/2903"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media\/2899"}],"wp:attachment":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media?parent=2898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/categories?post=2898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/tags?post=2898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}