Multi-Tenant SaaS Platform Architecture

Overview

A veteran Australian solo founder is building an accounting SaaS aimed squarely at e-commerce merchants — the kind of niche that generic incumbents have underserved for years. The early version runs, has paying seats, and needed to grow past single-tenant "set it up manually per customer" operations into something that can self-scale.

My role: long-term engineering partner on the platform layer. Everything from VPS consolidation through multi-tenant provisioning, operational tooling, and infrastructure decisions that need to outlive a single operator.

What's Being Built

• Self-serve tenant provisioning — public signup fires a job that creates a per-tenant database, runs EF migrations, seeds defaults, writes a templated Apache vhost fragment, and drops a per-tenant systemd unit. Zero manual steps per customer.
• Encrypted central credential vault — AES-256-GCM keyed credentials for external services (bank aggregators, SMTP, tax APIs) with rotation versioning. Tenants fetch by service/environment at startup; no secrets in tenant configs.
• Tenant isolation layer — per-tenant databases resolved dynamically per request, with a collapse-to-shared path kept cheap in case operational simplicity wins later. EF global query filters enforce boundary at the ORM level as a second defense.
• Super-admin operations dashboard — tenant list with live health (API status, DB size, last activity), license editing (plan tier, max users, max companies), user/company injection, rotation of compromised keys, suspend/resume flows.
• Request-boundary tenant resolution — tenant identity pulled from a request-scoped parameter at middleware, attached to the request context, scopes every downstream query and service call.

Delivered So Far

• VPS consolidation — bare Ubuntu 24.04 to a full KeyHelp-managed stack (Apache, PHP-FPM, MariaDB, SVN with WebSVN, Let's Encrypt auto-renewal across main + subdomains) in under 24 hours.
• Licensing system schema — plan tiers, max-users/max-companies enforcement, suspend/cancel endpoints with hardware-bind teardown, E2E tested.
• Tenant table DDL + provisioning contract finalized; encryption design approved (AES-256-GCM, environment-keyed, rotation via KeyVersion column).
• Multiple staging and demo environments live — public coming-soon page + protected operational dashboards + Swagger-exposed API for the product team.
• Third-party integration reliability work — diagnosed and resolved a production config drift where a bank-API key environment mismatch was silently failing on the demo box.

Operating Model

The founder plays product owner and stakeholder side (accounting, legal, marketing, tax compliance). I drive the technical architecture, implementation, and operational tooling. Decisions get made async over text; no video calls, no meetings — deep-work respectful on both sides. Every major architectural call is weighed against "does this still make sense if the founder steps back in five years?" — because it's meant to.

Tech Stack

Why It Matters

Most SaaS advice is written for companies trying to become Xero. This one isn't — it's a defensible niche product aimed at a specific merchant segment the incumbents underserve. The architecture goal isn't to support ten million users; it's to let a single founder run a durable, sustainable, boring-in-the-best-way platform for the next decade-plus. That's the part that's harder than it sounds: shipping something that keeps working long after the founder moves on to the next thing.