Build vs Buy 2026: the tech SMB decision framework

For fifteen years, the default answer to the "build or buy" question leaned almost always towards buy. SaaS covered everything: CRM, support, analytics, auth, payments, email, scheduling. Building seemed expensive, risky, and never as polished as a specialised product team. That era is ending. In 2026, four converging forces reshuffle the deck, and an SMB that mechanically applies the "buy by default" dogma leaves €200 to 600k on the table every five years.

First force: SaaS fatigue. A French SMB of 50 employees uses on average 40 to 80 SaaS tools in 2025, versus 15 to 25 in 2018. The average monthly bill per user climbed from €35 to €90 over the same period. Subscription sprawl is no longer anecdotal: it is now the second IT cost line after payroll, ahead of hardware and hosting. CIOs have started auditing these subscriptions the way they audit service contracts — and the findings are often harsh.

Second force: AI and assistance tools have driven down the cost of build. Cursor, Claude Code, GitHub Copilot, v0.dev: a senior developer now produces in a week what took a month in 2020. The marginal cost of a custom feature has been divided by three to five. Projects that weren't profitable in 2020 — an internalised workflow, a bespoke connector, a small back-office — become profitable in 2026.

Third force: European sovereignty. GDPR, NIS2, the DSA, and the coming European AI Act impose increasingly costly traceability on data processed outside the EU. Hosting with a US vendor subject to the CLOUD Act is no longer neutral: it is a documented legal risk. The SREC (Europol Reference System) and the EUCS directives push towards self-hosted or EU-hosted architectures. Several of our clients have migrated their analytics stack from Mixpanel to self-hosted Plausible for precisely this reason.

Fourth force: open-source parity. In 2026, for 80% of generic use cases (auth, DB, analytics, scheduling, CRM, helpdesk, payments orchestration), a mature open-source equivalent exists: Supabase, PostHog, Plausible, Cal.com, Twenty, Chatwoot, Hyperswitch. Functional parity is no longer a blind spot — it's often the opposite, with superior extensibility. "Buy" no longer buys a feature you can't find elsewhere: it buys the comfort of a managed service. And that comfort has a price, which reveals itself in year 5.

At VALRY LABS, we never make the build vs buy decision on instinct. We apply a five-criteria weighted framework, designed for a French SMB of 10 to 250 employees. Each criterion is scored from 1 (leans buy) to 5 (leans build). A total ≥ 15 triggers a deep build study. A total ≤ 10 closes the debate: buy.

Criterion 1 — Strategic differentiation. Is the feature a core business competency, or a generic service? If tomorrow your competitor uses the same thing with no visible difference, it's probably a commodity → buy. If the feature is what makes your clients pay → build. Example: for a HealthTech, the patient record is build; invoicing is buy. For a DTC e-commerce brand, the product recommendation engine is build; the shipping label is buy.

Criterion 2 — TCO over 3 to 5 years, not 1. The classic SaaS mistake: reasoning in annual cost. At €50/user/month × 50 users × 5 years, a single tool costs €150k. A well-designed internal workflow, hosted on an €80/month VM, with 0.3 FTE of maintenance smoothed over 5 years, costs about €90 to 120k over the same period — while staying under your control. TCO is never computed on year 1, where SaaS is structurally the winner (zero implementation cost, immediate start).

Criterion 3 — Data sensitivity and GDPR. The more sensitive the data (health, finance, HR, business IP), the more build or self-hosted becomes mandatory. The compliance cost of a leak at a US subcontractor can exceed that of a full build (CNIL fines, lost contracts, reputational damage). Rule of thumb: identifying health or financial data → build or EU-hosted with a robust DPA. Generic operational data → buy acceptable.

Criterion 4 — Integration cost with the existing stack. A badly integrated SaaS costs more than a well-integrated build. If the tool requires 4 to 8 weeks of connection work (custom connectors, bidirectional ETL, state synchronisation, webhook handling, retry policies), integration cost can reach €25 to 40k — and that debt persists with every vendor-side change. For a tool destined to interact deeply with your core business, build almost always wins.

Criterion 5 — Vendor risk. What happens if the vendor shuts down, changes pricing by 200%, or is acquired by a hostile player? This question was theoretical in 2018; it became concrete in 2026 (see the aggressive acquisitions by Thoma Bravo and Vista, plus the pricing U-turns of several analytics vendors in 2023-2024). Evaluate: vendor age, profitability, dependence on a tier-1 investor, contractual lock-in, complexity of data export. If the answer is "impossible to migrate in under 6 months", vendor risk becomes a dominant build factor.

Beyond the scoring, there is an empirical axis that defuses 80% of executive-meeting debates: the commodity / differentiation distinction. Commodities are the standard functions everyone implements the same way; differentiators are the ones that make your product unique. The rule is simple: buy for commodities, build for differentiators.

Buy without hesitation: auth (Clerk, Supabase Auth, WorkOS), payments orchestration (Stripe, Adyen), transactional email (Resend, Postmark), cloud infrastructure (AWS, GCP, Scaleway), observability (Sentry, Better Stack). Building your own auth system or payment processor in 2026 is almost always a mistake — these layers are commoditised, regulation-watched, and benefit from economies of scale no SMB can match.

Build by default: internal tools (business back-offices, management interfaces, ops scripts), customer-facing workflows that embody your product promise, and above all any AI-assisted process that consumes your intellectual property. If your competitive edge lies in a scoring algorithm, a RAG pipeline over your document base, or a proprietary qualification workflow — building is the only defensible option. Buying a SaaS tool that would require your team to drop its IP into an external prompt is a hidden value transfer.

The grey zone — CRM, helpdesk, analytics, marketing automation — is where the debate genuinely deserves to happen. For a B2B services SMB, a CRM like HubSpot or Pipedrive remains relevant: the value is in the usage, not the technology. For a tech SMB with an atypical customer lifecycle (subscription furniture, multi-sided marketplaces, staged services), a generic CRM breaks the sales process: you start coding workarounds, custom fields, increasingly brittle automations. At that point, switch to Twenty (open-source CRM) or evaluate a targeted build.

Take the real case of a French B2B services SMB, 50 employees, activating five standard SaaS tools in 2026: a CRM (HubSpot Starter, €18/user/month ex. VAT × 50), a support tool (Intercom Essential, ~€25/user/month × 20 agents), a product analytics solution (PostHog Cloud, ~€40/user/month × 10 seats + €200/month of volume), a scheduling tool (Calendly Teams, €12/user/month × 30), a marketing automation tool (Brevo Business, ~€50/user/month × 10 + volume).

Over 12 months, the total bill reaches about €56,000 ex. VAT. Over 5 years, factoring in the average price increases observed at these vendors (8 to 12% per year), you exceed €340,000 ex. VAT. For 5 tools — not counting the 15 to 30 other minor subscriptions added along the way (Notion, Loom, Figma, Slack, Linear, 1Password, Hotjar, etc.) which easily add another €25,000 to €60,000 per year.

Alternative profile: migration to Supabase (auth + DB + storage, EU-hosted, ~€150/month self-hosted), self-hosted Plausible (analytics, €9/month on a VM), self-hosted Cal.com (€0/month beyond infra), Twenty CRM self-hosted (open-source, ~€100/month of infra), Chatwoot (open-source helpdesk, ~€80/month of infra). Total infra cost: ~€600/month. Smoothed maintenance FTE cost: 0.5 senior full-stack developer, roughly €60,000/year loaded. Over 5 years: ~€360,000. Pure financial break-even arrives around month 24, and the curves diverge sharply afterwards — by year 5, the open-source profile is 30 to 40% cheaper, and the company owns its infrastructure.

The financial reasoning isn't the only one. The open-source profile removes pricing risk: no vendor can unilaterally raise your bill by 30%. It also removes lock-in: your data stays in your PostgreSQL, your schemas belong to you, your integrations don't depend on a closed API. Conversely, the SaaS profile spares you infrastructure management and frees 0.5 FTE for product tasks. The right choice depends on your ability to hire and retain a competent DevOps profile — which, in 2026, is no longer an obstacle for an SMB getting serious about digital.

The build vs buy debate is increasingly replaced by a third model: hybrid. The most mature 2026 pattern consists of using an open-source core with a commercial support contract for operational comfort. You keep control of the code and the data, without carrying the maintenance load alone.

Supabase illustrates this model perfectly: the self-hosted offer is free and complete (PostgreSQL, Auth, Storage, Realtime, Edge Functions), and the Cloud offer provides a managed service with SLAs, support, and a dashboard. Plausible Analytics works on the same scheme, as do Cal.com, PostHog, Twenty, and Sentry. For an SMB, the efficient strategy is to start on Cloud (time-to-market, no ops), then switch to self-hosted as soon as usage justifies a DevOps FTE — generally around €1,500/month of Cloud bill.

Second hybrid pattern: self-hosted for the core (data, auth, business IP) + SaaS for the periphery (collaboration tools, communication, marketing). A HealthTech will self-host its patient database, its business API, its auth; it can on the other hand buy Slack, Notion, or Figma without risk. The rule: everything touching the product or sensitive data is self-hosted; everything that is a generic collaboration tool can stay SaaS.

Third pattern, the most strategic: build the orchestration, buy the components. Rather than building every brick, you buy (or adopt as open-source) standard components, and you build the orchestration layer that assembles them according to business logic. Concretely: Stripe for charging, Hyperswitch for multi-PSP routing, and an in-house orchestrator that decides which route based on amount, country, and risk. This pattern maximises differentiation (orchestration) while minimising cost (components). It is the architecture we deploy for our FinTech and e-commerce clients.

The 5-criteria framework plays out differently by sector. Here is the decision matrix we apply on missions, built from some fifty SMB cases handled in 2024-2025.

FinTech / PayTech. Everything touching credit risk, KYC scoring, fraud prevention, multi-PSP orchestration, and regulatory accounting → build. Everything that is raw payment (card, SEPA), standardised tax reporting, verified identity → buy (Stripe, Adyen, Onfido, Pennylane). Never build your own payment processor; always build your own fraud layer if it is core business.

HealthTech. Patient records, assisted-diagnosis algorithms, anonymisation pipelines, integrations with DMPs and business software (Doctolib, Maiia, Wandercraft) → build, on HDS hosting. Invoicing, electronic signature (Yousign, DocuSign), video conferencing → buy, while checking HDS certification and the DPA. The stakes are less about cost than compliance and control over patient data — your primary asset.

E-commerce. The recommendation engine, dynamic pricing, merchandising rules, the cross-sell universe → build (this is where margin is won). Shipping (Sendcloud, Shoprunr), payments, technical SEO, email marketing (Brevo, Klaviyo), the headless CMS for the storefront → buy. Special CRM case: in high-volume B2C, targeted build or a specialised tool (Klaviyo, Sarbacane); in B2B, a standard CRM like HubSpot or Pipedrive is largely sufficient.

B2B services (consulting firms, agencies, ESNs, law firms). Time-tracking, invoicing, margin-per-engagement reporting, the sales pipeline → a pragmatic mix where SaaS holds up (Pennylane, Cycle, Forecast, HubSpot). Internal knowledge management and generative-AI tools applied to deliverables → build, because that is where the competitive edge is built (reuse of know-how, capitalisation of methods).

The short answer: stop reasoning in "build vs buy" and reason in "core vs context". Core: what differentiates you, protects your IP, or processes sensitive data — build or hybrid self-hosted. Context: everything else, commoditised, generic — buy without guilt, auditing the bill annually.

Operational course of action in four steps. Step 1: run a full SaaS audit (1 week, €6-10k). Map the subscriptions, real cost per user, real usage rate. You will discover on average 25 to 35% of under-used or redundant subscriptions — an immediate first saving of €15 to 40k/year with no build decision at all.

Step 2: apply the 5-criteria framework to your 10 most expensive tools. Score each criterion, sum it up, identify the 2 or 3 migration candidates. Focus your effort: don't migrate 15 tools at once; pick the 2 where the 5-year TCO leans most clearly towards build or self-hosted.

Step 3: for each candidate, evaluate the open-source alternative and the migration cost (often €30-80k for a medium-scope tool). Compute break-even in months. If ≤ 24 months, go. If 24-36 months, decide based on your strategic horizon. If > 36 months, keep the SaaS — the context doesn't justify the migration.

Step 4: industrialise the reasoning with an internal ADR (Architecture Decision Record) for every new tool acquisition. Any new SaaS subscription above €200/month goes through a 1-page ADR sheet: need, open-source alternatives, 5-year TCO, vendor risk. That is the only way to prevent the situation from rebuilding itself in three years.