Skip to main content

← /journal / escape / self-host-vs-saas

[post_004] · § Escape

Self-Host vs SaaS: A Decision Framework for Mid-Market Teams

Four axes — cost, ops capacity, compliance, customisation — and a matrix for when each path is the right one.

DK · Principal Engineering · · 7 min read · Escape

Four axes — cost, ops capacity, compliance, customisation — and a matrix for when each path is the right one.

[01] §

The four-axis framework

Score the candidate workload on four axes from 1–5: cost sensitivity (how much does the SaaS bill hurt?), operational capacity (can your team patch a Postgres instance at 2am?), compliance posture (does data sovereignty actually matter for this workload?), and customisation needs (how often does the off-the-shelf product fit poorly?). Anything scoring high on three of four is a candidate to leave.

[02] §

When SaaS is right

Low cost sensitivity, low ops capacity, low compliance bar, low customisation: SaaS is right and almost certainly cheaper than the alternative. This describes most marketing tools, most analytics, most communication tools, and most CRM at sub-100-seat scale. Stay; do not optimise the unimportant.

[03] §

When self-host is right

High cost sensitivity (large seat count), available ops capacity (you have a serious infra team or a partner), strict compliance (regulated data that should not leave your perimeter), high customisation (the workflows are core to your moat). Most ERPs at scale, most internal tooling, most data warehouses, most ML inference for sensitive data.

[04] §

The hybrid (managed open-source)

Supabase Cloud, Cal.com Pro, PostHog Cloud, Plausible Cloud, Mattermost Cloud — you get the open-source codebase available as an exit ramp, and you get someone else operating it. Often the right answer for teams that want exit-readiness without taking on the ops burden today. The economics tend to be better than pure SaaS, worse than self-host.

[05] §

A worked matrix

CRM @ 50 seats: stay SaaS. CRM @ 300 seats: build or migrate. Email marketing @ any scale: stay SaaS unless you are a deliverability-sensitive shop. Internal admin tools: build. Data warehouse @ any scale that uses it: self-host (it is too easy to leak governance). Auth: hybrid (Clerk, Supabase Auth) until you outgrow it.

Working on something like this? Start a project →