Self-hosting vs managed services — build the spreadsheet

Self-hosting (running software on servers you control) and managed services/SaaS (paying a provider to run it for you) are both valid approaches. For beginners, the most reliable way to decide is to build a simple spreadsheet that compares total cost of ownership (TCO) and risk across the tools you need: email, analytics, CI/CD, databases, and more.

This article gives you a practical framework, real-world examples, and a decision matrix you can reuse.

What you’re really choosing: responsibility vs convenience

When you self-host, you “buy” flexibility and control, but you also “buy” the work:

• provisioning servers (VMs, containers, networking)
• security patching and vulnerability response
• monitoring, backups, disaster recovery
• upgrades, migrations, performance tuning
• on-call responsibility when something breaks

When you use a managed service/SaaS, you pay a higher cash cost but usually reduce:

• operational toil
• time-to-ship
• risk of catastrophic misconfiguration
• staffing requirements

The spreadsheet approach forces you to price your time and quantify risk instead of deciding based on vibes.

Step 1: List the services you need (and what “done” means)

Start a sheet tab called Inventory. For each capability, define the outcome you need. Example rows:

• Email: transactional + marketing? SPF/DKIM/DMARC? deliverability reporting?
• Analytics: basic pageviews or product analytics? privacy requirements?
• CI/CD: build minutes, artifact storage, deployment approvals, secrets management?
• Database: uptime target, backups, encryption, read replicas, point-in-time recovery?

A beginner-friendly set of columns:

• Service (Email, Analytics, CI/CD, Database, etc.)
• Scope (what features you need)
• Data sensitivity (Low/Med/High)
• Uptime target (e.g., 99.5%, 99.9%)
• Compliance needs (GDPR, HIPAA, SOC2—if any)
• Growth expectation (users/events/requests per month)

This prevents “we’ll just self-host it” from turning into “oh no, we also needed deliverability/replicas/audit logs.”

Step 2: Create options per service (Self-hosted vs Managed)

Create another tab called Options. Each service gets at least two options:

• Self-hosted (on your VPS/Kubernetes/home lab/colo)
• Managed/SaaS (vendor-hosted)

Depending on the service, you might also include a hybrid:

• Managed database but self-host the app
• SaaS analytics but self-host log storage

Example options (not endorsements, just common shapes):

• Email

- Self-hosted: Postfix + DKIM/DMARC + spam handling (hard mode) - Managed: Postmark/SendGrid/Mailgun (transactional), or Google Workspace/M365 (inbox)

• Analytics

- Self-hosted: Plausible/Matomo - Managed: Plausible Cloud, Google Analytics, Mixpanel/Amplitude

• CI/CD

- Self-hosted: GitLab CE, Jenkins, Gitea Actions runners - Managed: GitHub Actions, GitLab.com, CircleCI

• Database

- Self-hosted: PostgreSQL/MySQL on a VM with your own backups - Managed: RDS/Cloud SQL/Fly/Neon/Supabase (managed Postgres variants)

Step 3: Build the TCO model (money + time + risk)

Create a tab called TCO with one row per option. Include both monthly costs and one-time setup costs.

Core cost columns to include

Cash costs

• Subscription cost ($/mo): vendor plan
• Infrastructure cost ($/mo): VM(s), storage, bandwidth, load balancers
• Backup/storage cost ($/mo): snapshots, object storage, retention
• Monitoring/logging cost ($/mo): either SaaS tools or extra infra

Time costs (convert to dollars)

• Setup hours (one-time)
• Monthly maintenance hours
• Incident hours/month (expected average)
• Hourly rate ($/hr): use a realistic blended rate for your team

- For a solo founder, you might choose $50–$150/hr depending on opportunity cost. - For a company, use a loaded rate (salary + overhead), often $80–$200/hr.

Risk/impact costs (optional but valuable)

• Downtime cost ($/hr): estimated lost revenue/productivity
• Expected downtime (hrs/mo): based on your maturity and option
• Compliance/security cost ($/mo): audits, pentests, vendor add-ons

Spreadsheet formulas (simple and effective)

Add these computed columns:

• Time cost one-time ($)

`= SetupHours * HourlyRate`

• Time cost monthly ($/mo)

`= (MaintenanceHours + IncidentHours) * HourlyRate`

• Downtime cost monthly ($/mo)

`= DowntimeHours * DowntimeCostPerHour`

• Total monthly TCO ($/mo)

`= Subscription + Infrastructure + Backups + Monitoring + TimeMonthly + DowntimeMonthly + Compliance`

• First-month cost ($)

`= TotalMonthlyTCO + TimeOneTime` (Optionally include any migration cost here too.)

Practical example: database option comparison

Assume:

• Hourly rate: $100/hr
• Downtime cost: $200/hr (lost sales + support time)
• Basic needs: Postgres, automated backups, encryption, 99.9% desired

Option A: Self-host Postgres on a VPS

• Infrastructure: $40/mo (VM + disk)
• Backups: $10/mo (object storage)
• Monitoring: $10/mo
• Setup: 12 hours (hardening, backups, restore test)
• Maintenance: 4 hrs/mo (patching, tuning, backup checks)
• Incidents: 1 hr/mo (small issues)
• Expected downtime: 1 hr/mo

Calculations:

• Time one-time: 12 * 100 = $1,200
• Time monthly: (4+1)*100 = $500/mo
• Downtime: 1*200 = $200/mo
• Total monthly: 40+10+10+500+200 = $760/mo

Option B: Managed Postgres

• Subscription: $150/mo
• Extra backups/monitoring: included
• Setup: 3 hours (provision, migrate, connection pooling)
• Maintenance: 1 hr/mo
• Incidents: 0.2 hr/mo
• Expected downtime: 0.2 hr/mo

Calculations:

• Time one-time: 3*100 = $300
• Time monthly: (1+0.2)*100 = $120/mo
• Downtime: 0.2*200 = $40/mo
• Total monthly: 150+120+40 = $310/mo

Even though managed “costs more” in subscription, it often wins in TCO once you price your time and downtime realistically.

Step 4: Add qualitative factors with a scoring model

Money isn’t everything. Add a tab called Decision Matrix where you score each option (1–5) across criteria and apply weights.

Suggested criteria (with beginner-friendly weights)

You can start with weights that sum to 100:

• Reliability/Uptime (20)
• Security risk (20)
• Time-to-implement (15)
• Ongoing maintenance burden (15)
• Scalability (10)
• Cost (10)
• Data control/privacy (5)
• Vendor lock-in risk (5)

Score each option from 1 (bad) to 5 (excellent). Then compute:

• Weighted score

`=SUMPRODUCT(ScoreRange, WeightRange) / SUM(WeightRange)`

This allows a managed option to win even if it costs more, or a self-hosted option to win when privacy/control dominates.

Example: analytics scoring snapshot

For a small site needing basic pageviews:

• Self-hosted analytics (Matomo/Plausible self-host)

- Reliability: 3 (you operate it) - Security: 3 - Time-to-implement: 2 - Maintenance: 2 - Scalability: 3 - Cost: 4 (low cash, higher time) - Data control: 5 - Lock-in: 4

• Managed analytics (Plausible Cloud / GA / similar)

- Reliability: 5 - Security: 4–5 - Time-to-implement: 5 - Maintenance: 5 - Scalability: 5 - Cost: 3 (subscription) - Data control: 2–3 - Lock-in: 2–3

Your weighted result will depend on your priorities, not internet arguments.

Step 5: Apply the framework to common categories

Below are category-specific notes that help you estimate time/risk realistically.

Email: self-hosting is usually a trap (at first)

Self-hosting email isn’t just running a mail server. The hard parts are:

• deliverability (IP reputation, spam filters, feedback loops)
• DNS correctness (SPF/DKIM/DMARC)
• abuse handling (account compromise, spam outbreaks)
• inbox placement monitoring

Spreadsheet tip: inflate incident time for self-hosted email unless you have prior experience. Many teams choose:

• Managed inbound inbox (Google Workspace/M365)
• Managed outbound transactional (Postmark/Mailgun/etc.)
• Maybe self-host marketing automation only if you truly need it (rare early)

Analytics: self-hosting can be reasonable if scope is small

Analytics is often a good “starter” self-host if:

• you can tolerate brief downtime
• you keep it isolated (separate DB/user, minimal permissions)
• you have automated updates and backups

Hidden costs to model:

• data retention and storage growth
• cookie/privacy compliance work
• bot filtering and data quality

CI/CD: consider hybrid (managed control plane, self-host runners)

Many beginners do best with:

• Managed CI (GitHub Actions/GitLab.com)
• Optionally self-host runners for performance, secrets locality, or cost control

Spreadsheet tip: separate “control plane” from “compute minutes.” Self-hosting the whole CI stack can be operationally heavy; self-hosting runners is often the sweet spot.

Databases: managed usually wins for production

Databases demand:

• proven backups and restore drills
• upgrades with minimal downtime
• replication/high availability (if required)
• performance tuning under load

Beginners frequently underestimate maintenance and incident time. Managed databases reduce operational risk dramatically.

If you self-host anyway: explicitly budget hours for:

• monthly patching
• quarterly restore test
• monitoring tuning
• capacity planning

Step 6: Make the spreadsheet actionable (a simple rule set)

Once you have both TCO and weighted scores, decide with rules that prevent analysis paralysis:

1. If a service is business-critical and stateful (databases, auth, payments): default to managed unless you have strong reasons. 2. If downtime is cheap and the service is stateless (internal tools, small analytics): self-hosting can be a learning-friendly choice. 3. If the service involves reputation networks (email): managed is usually best. 4. If you lack on-call coverage: managed services reduce “2am pager” risk. 5. If regulation/privacy is strict: self-hosting might help, but only if you can meet security obligations—otherwise choose a compliant managed provider.

Suggested spreadsheet structure (copy/paste outline)

Tabs:

• Inventory: requirements and “definition of done”
• Options: each option per service
• TCO: costs + time + risk converted to monthly dollars
• Decision Matrix: weighted scoring
• Assumptions: hourly rate, downtime cost, expected growth

Key global assumptions to store once:

• Hourly rate ($/hr)
• Downtime cost ($/hr) by service criticality (e.g., DB higher than analytics)
• Target uptime (by service)
• Time horizon (12 or 24 months)

Final takeaway: you’re buying outcomes, not software

Self-hosting vs managed services isn’t a moral choice—it’s an operations and economics decision. A spreadsheet that includes time and risk will usually show:

• Managed services win for email and production databases early on.
• Hybrid wins for CI/CD (managed platform + optional self-host runners).
• Analytics can go either way depending on privacy needs and tolerance for downtime.

Build the spreadsheet once, reuse it for every tool you add, and revisit assumptions as your team and revenue grow.