Build vs Buy: how to decide without conflict of interest
An honest framework to choose between building custom software, buying SaaS or adopting a hybrid stack. Without vendor bias, with verifiable criteria and cases where each path is the right one.
The question comes after the diagnostic: a company realises its current software does not hold up anymore and has to decide. Build a custom system? Buy SaaS and migrate? A mix? The problem is that almost anyone who answers has a conflict of interest. The SaaS vendor will say “buy”. The build consultancy will say “build”. The integrator will say “both, and I will connect them for you”.
This article is for the company to make the decision with its own judgement. A framework with five concrete questions, a table of when each path is right, and the three most expensive mistakes we see in mid-sized companies. No sales pitch. No “it depends”.
Why the decision so often goes wrong
Three reasons we see repeated. First, bias: most companies first consult the vendor who will sell them the answer. Second, horizon: they compare year-one costs when the decision plays out over 3-5 years. Third, identity: they confuse what the company does well with what is central to its competitive advantage. “We do it well” is not the same as “this distinguishes us”.
Joel Spolsky framed it in 2001: if your difference depends on doing X in a unique way, build X. If X is commodity (invoicing, email, basic accounting), buy it. The rule still holds. What changed is that in 2026 the grey zone is enormous: processes that are commodity for one company are core for another in the same industry.
The framework: five questions
If you answer yes to three or more, building makes sense.
Competitive advantage
Is this process what distinguishes you from competitors?
SaaS fit
Does a SaaS exist that covers the flow without forcing you to redesign your business?
3-year TCO
Does the 3-year total cost favour build vs licence + integrate?
Change velocity
Do you need to change the process several times a year?
Operational capacity
Do you have a team (in-house or contracted) to maintain what is built?
Question 1, competitive advantage
If the process is what distinguishes your company, building it gives you control. If it is commodity, building it is an expensive luxury. A gourmet bakery could have a unique sourdough management system (its differentiator), but does not need to build its accounting. A consultancy could build its own project management platform only if the proprietary methodology is the differentiator sold to the client. Otherwise, Asana or Monday exist.
Honesty test: if you describe the process to a competitor, do they identify it as something unique to you, or do they find it similar to what they do? If the latter, it is not your differentiator.
Question 2, SaaS fit
Three levels. Natural fit: SaaS covers 90% of what you need and the remaining 10% is tolerable. Forced fit: covers 60-80% and you have to adapt your operation to the product. No fit: covers less than 60% or forces you to operate the way you do not want.
Forced fit is the most common trap. The product promises to cover everything, you buy it, and you discover your team is redesigning flows to accommodate the software. The SaaS ended up defining how you operate. Sometimes that is fine (it aligns you with good practices you lacked), sometimes it is disastrous (it breaks what made you different).
“Customisable” in a SaaS demo is not the same as “adapts to your process”. Customisable usually means custom fields, predefined workflow rules, branding. When the process needs logic the product did not anticipate, customisable becomes “we can check with the dev team, premium rate, no timing guarantee”.
Question 3, 3-year TCO
Honest comparison requires looking at 3 years, not 1. Building costs more upfront and less later; SaaS costs less upfront and more later. The crossover typically lands between year 2 and year 4 depending on usage volume and vendor.
Internal management system for 20 users, mid-sized company, 2026.
Ranges assume typical mid-sized SMB volume and complexity, 2026. They are not universal. The honest exercise is to ask for real quotes from 2-3 SaaS vendors and 2-3 custom software providers with the same brief.
Question 4, change velocity
If you need to change the process 3-4 times a year (because the business grows, regulations shift, clients demand new things), SaaS limits you. The SaaS change velocity is set by the vendor, not by you. For stable processes (accounting, email, helpdesk), SaaS wins. For continuously evolving processes (operational engine, pricing logic, specific integrations), building wins.
The question is not just what it costs today. It is who decides when your system changes.
Question 5, operational capacity
Building software you cannot maintain is worse than buying. If your company has no in-house IT team and no sustained maintenance budget, lean toward SaaS or a maintenance provider with a clear annual contract. What kills mid-sized companies is not deciding to build, it is deciding to build without a maintenance plan.
Concrete question for your team: “If the main developer resigns tomorrow, what happens?”. If the answer is “we do not know”, the problem is not build vs buy: it is governance. Fix that first.
When each path is right
General rules with typical SMB cases.
- 01 Build: core business engine. Matching platform, dynamic pricing logic, industry-specific operations, traceability with legal signature, deep integrations with non-standard tax authorities or payment rails.
- 02 Buy: commodity administrative processes. Email (Google Workspace), basic CRM (Pipedrive, HubSpot), accounting (local provider), tax invoicing, helpdesk (Zendesk, Freshdesk), document management.
- 03 Hybrid: the common case. You buy commodity, build the core. 80% of mid-sized companies operate this way (Gartner, 2023). What is missing is not the decision: it is planning it instead of accumulating it.
- 04 Custom-on-OSS: middle ground. You build on open source (Django, Saleor, PocketBase, Strapi, n8n). Lower initial cost vs pure custom, you keep ownership and portability.
- 05 SaaS with exit plan: pragmatic. You buy SaaS but require from day one: DPA contract, documented exportability, exit plan with date. If the vendor resists, red flag.
Three expensive mistakes
Mistake 1: building commodity. An SMB builds its own invoicing system because “it is cheaper long term”. Two years in, the system is poorly maintained, fails to keep up with tax authority changes, and replacing it costs what they would have spent on SaaS from the start. Rule: if the process is regulated and changes frequently, buy.
Mistake 2: buying the core. A consultancy with proprietary methodology buys a standard management platform. Six months in, the entire team is adapting flows to the product instead of operating as before. Differentiation dilutes and clients notice. Rule: if the process is what you sell, do not subcontract it to a product.
Mistake 3: building without maintenance plan. Company hires custom development, launches, does not budget maintenance. Eighteen months later the system accumulates technical debt, depends on one person, and enters phase 3 of technical debt. Rule: budget 15-25% of initial cost every year, or do not build.
Honest examples
At Bioaudita, an organic certification platform, the decision was to build because immutable traceability with Chilean Law 19.799 electronic signature is what differentiates it. No SaaS covers that flow without contortions, and the logic is regulated and specific.
At TCultura, we built the ticketing plus socioemotional impact measurement platform, but we use Flow and Transbank for payments (commodity), Google Workspace for collaboration (commodity), and open source libraries for validated psychometric scales (we did not invent them). The result is planned hybrid, not accumulated.
In the products we offer to our own clients (Hub Nubiq, Sign DataNubi), the logic is the same: we build where the difference matters, we integrate where it is standard. Hub Nubiq uses Stripe for billing (we did not build a billing engine). Sign DataNubi uses Smallstep CA for PKI (we did not build a certificate authority). The differentiator sits above, not in the foundations.
Build what distinguishes you. Buy what does not. The trap is confusing the second for the first.
Clauses to require if you buy SaaS
- 01 Signed DPA with defined jurisdiction (your country or agreed equivalent).
- 02 Full data exportability in standard format, no extra cost at exit.
- 03 Defined breach notification deadline (ideally 72 hours, max 7 days).
- 04 Access to audit logs and change traceability.
- 05 Continuity commitment: what happens if the vendor closes or is acquired.
- 06 Price review clause (no arbitrary unilateral increase).
- 07 Documented exit plan with guaranteed maximum migration date.
Closing
Build vs Buy is not ideological. It is operational. The company that builds everything because “it is all strategic” drowns in maintenance. The company that buys everything because “it is easier” ends up with a Frankenstein of disconnected SaaS paying licences that double the cost of building.
The five-question framework resolves most cases. For the rest (and those are the interesting ones), let’s talk. We will not sell you a build if the right answer is buy: we will tell you which process is central and which is commodity, with the honesty that comes from working both sides.
Frequently asked questions
When does it make sense to build custom software?
When the process is central to your competitive advantage, when no SaaS covers your flow without distorting your business, or when SaaS recurring costs exceed building + maintaining over 3 years. Also when you need deep integrations no vendor offers.
When does it make sense to buy SaaS?
When the process is commodity (invoicing, basic accounting, email, standard CRM, helpdesk), when time-to-value matters more than differentiation, or when your team cannot maintain custom software. Buying is the right answer for most administrative processes.
What is a hybrid solution?
A stack where you buy commodity (Gmail, Slack, accounting, basic CRM) and build what differentiates you (matching engine, dynamic pricing logic, specific operational dashboard). Gartner estimates 80% of mid-sized companies operate this way, but few plan it: most arrive by accumulation.
How much does custom software cost?
A functional MVP runs USD 8K-30K in LATAM markets. A full enterprise system USD 50K-200K. Realistic annual maintenance is 15-25% of initial cost. Any quote outside these ranges needs a second opinion.
What does SaaS cost over 3 years?
Depends on vendor and users. A Salesforce or HubSpot Enterprise CRM for 20 users runs USD 25K-60K over 3 years. A cloud ERP USD 30K-150K. The real number includes implementation, training and adjustments, not just licences.
What is the biggest risk of buying SaaS?
Vendor lock-in: dependence that becomes hard to reverse. Price increases without negotiation, feature removals, limited data exportability. The second risk is that SaaS defines how your business operates, not the other way around: you end up adapting your process to the product.
Who at aGo can give an unbiased second opinion?
We work both sides. We build custom software (we are build) and we operate showcase products like Nubiq, DataNubi, QueLicitar. That context lets us recommend buy when it is right, without losing the client. A 20-minute second opinion is free.