060 279 5587 info@sitect.co.za 139 Davies Street, Doornfontein, Johannesburg, 2001 Gauteng, SA
Software · Custom SaaS Platform Build

From MVP to multi-tenant scale.

We build SaaS platforms for founders who've outgrown no-code, agencies who've been burned by under-engineered MVPs, and teams who've earned the right to a properly-architected product. End-to-end — architecture, design, backend, frontend, deployment — and a partnership that survives launch.

From R100k · MVP tier 3–5 months typical to first live customer Multi-tenant from day one
app.{tenant}.sitect.co.za
Kasi LogisticsPro plan · 24 seats
Workspace
Dashboard
Customers 12
Billing
Reports
Admin
Settings
Team

Dashboard

Workspace metrics · last 30 days
Export New customer
MRR
R142 580
+12.4%
Active tenants
86
+9
Trials → paid
42%
+5pp
Churn
2.1%
−0.6pp

MRR — last 12 weeks +R18.2k

Plan mix

68%
Pro · 68%
Starter · 21%
Trial · 11%

Recent tenants

Tenant
Status
MRR
M
Mzansi Roastery
Active
R3 480
B
Bokamoso Health
Active
R6 200
T
Tlhokomelo Group
Trial
R0
L
Lerato Logistics
Active
R8 750
Multi-tenantWorkspace-isolated by default
SLO
99.9%
ObservabilitySentry · APM · alerts
Why SaaS builds collapse

The 4 patterns that kill SaaS founders

Building a SaaS is hard. Building one that survives its first 100 customers is harder. Here's what we see go wrong — and why we exist.

Pattern 01

"MVP" that was never going to scale past 10 customers.

Built fast, hard-coded with the first customer's name in the database, no multi-tenancy, no auth layer, no billing. Works for the demo. Falls over on customer #11 because adding a tenant means writing migrations and copying environment variables.

What it costs: 6 months of customer-onboarding pain, then a full rebuild while losing momentum.
Pattern 02

The dev shop disappeared two weeks after launch.

The build was fine. The handover was not. No documentation, no architecture diagrams, no test suite, no CI/CD, no runbook. The first bug after launch takes a week to fix because nobody knows where anything lives. The agency is "happy to help" — for retainer fees, not warranty.

What it costs: a working product that becomes unmaintainable, then unmaintained.
Pattern 03

Built on a no-code stack you've outgrown.

Bubble, Webflow, Airtable. Brilliant for validation, terrible at 1 000 users. Re-platforming after product-market fit is technically possible but operationally brutal — and the rebuild eats 4–6 months your competitors will spend acquiring customers.

What it costs: a re-platform mid-growth, with all the customer-pain and team-burnout that implies.
Pattern 04

Billing was an afterthought. Now nothing reconciles.

"Just add Stripe at the end" — except SaaS billing isn't just charging cards. It's plan changes mid-cycle, proration, dunning, failed-card retries, trial→paid conversion, usage metering, taxes by region. Bolting on billing late is harder than building it from day one.

What it costs: revenue leak, finance team confused, customers double-charged, manual reconciliation forever.
Our non-negotiables

The 6 foundations every Sitect SaaS ships with

These aren't features — they're foundations. They're what separates "a SaaS that works in a demo" from "a SaaS that runs a business". Every Sitect build ships with all six, baked in from day one.

1. Multi-tenancy from day one

Every record knows which tenant it belongs to. Every query enforces tenant isolation. No cross-tenant data leaks possible by construction.

  • Tenant scoping at ORM level
  • Sub-domain or path routing
  • Per-tenant config + branding

2. Auth + RBAC, properly

Email + magic-link + Google/Microsoft SSO + per-tenant roles + permissions. SAML/SSO ready when you upgrade an enterprise customer.

  • Magic-link + 2FA
  • Roles & granular permissions
  • SAML/SSO upgrade path

3. Billing & subscriptions

Stripe Billing (or Paddle/Lemon Squeezy/Yoco-recurring), plan tiers, proration, trials, dunning, customer self-serve portal — production-grade.

  • Plan changes + proration
  • Trial flow + win-back
  • Usage metering ready

4. CI/CD + infrastructure

Terraform-defined AWS infrastructure, GitHub Actions pipelines, automated migrations, blue-green deploys, env-based config — from day one.

  • AWS af-south-1 default
  • Terraform IaC
  • Auto-migrate on deploy

5. Observability

Sentry, Datadog APM, structured logs, custom dashboards, on-call alerts. The day a bug hits production, you know within minutes — not next-day.

  • Error + APM tracking
  • SLO dashboards
  • Slack / WhatsApp alerts

6. Security & compliance

POPIA aligned, audit logs, encrypted at rest, secrets in AWS Secrets Manager, daily backups, runbook for breach response.

  • POPIA / GDPR ready
  • Audit log on every action
  • Disaster-recovery runbook
Architecture · the stack

The technology choices we make — and why

We make boring, well-understood choices because you're hiring engineering, not novelty. Here's the stack we default to for SaaS builds, and the reasoning behind each layer.

Frontend

Layer 1

Next.js 15 with App Router + server components. Inertia.js + Vue 3 where the team prefers Vue. Tailwind CSS + shadcn for a fast design system. React Native for mobile.

Next.js 15Inertia.jsVue 3Tailwindshadcn

Backend

Layer 2

Laravel 12 on PHP 8.2+ is our default — mature, productive, batteries-included. Node.js (Hono / NestJS) for I/O-heavy real-time workloads. Both deploy the same way.

Laravel 12Node.jsSanctumHorizonOctane

Data

Layer 3

PostgreSQL as default (better JSON, partial indexes, RLS). MySQL when the team prefers. Redis for cache + queues. OpenSearch for full-text. S3 for media + exports.

PostgreSQLMySQLRedisOpenSearchS3

Infrastructure

Layer 4

AWS Cape Town (af-south-1) as default — SA data residency, POPIA-friendly latency. ECS Fargate for containers, RDS for databases, ElastiCache for Redis, Terraform throughout.

AWS af-south-1ECS FargateRDSTerraformCloudflare

Observability

Layer 5

Sentry for errors, Datadog (or self-hosted Grafana) for APM + dashboards, structured JSON logs into CloudWatch + queryable store. SLO-driven alerting.

SentryDatadogGrafanaCloudWatch

Billing

Layer 6

Stripe Billing is our default — best SaaS billing primitives anywhere. Paddle when you need MoR. Yoco recurring for ZAR-only SA SaaS. Webhook-driven, fully reconciled.

Stripe BillingPaddleYocoWebhooks
What we engineer into your platform

The 9 capabilities SaaS founders ask us for most

Beyond the 6 foundations, here's the next layer of capability — features we've shipped many times and can roll into your build.

Team + invite flows

Invite teammates, accept invites, manage seats, billing-aware seat-limits, role-changes, ownership transfer.

Usage metering

Real-time usage counting, soft/hard limits per plan, usage-based billing dimensions, customer-facing usage dashboards.

Public API + docs

Versioned REST or GraphQL API, auto-generated OpenAPI docs, API key management, rate-limiting per plan.

Webhooks (outbound)

Webhook subscriptions for customers, signed deliveries, retry with backoff, delivery log + manual replay UI.

Audit log + activity feed

Immutable audit trail of every meaningful action — for compliance, for customer support, for debugging "who deleted X?"

In-app notifications

Real-time toasts, notification centre, email digests, customer-configurable preferences, fan-out via queues.

Data export / import

CSV/Excel export of every important entity, scheduled exports to customer S3, import wizards with validation + error reports.

White-label + custom domain

Per-tenant custom domains (with auto-SSL), brand colours, custom logos, customer-facing email templates.

AI-native features

LLM-powered search, summarisation, generation. Sitect's AI core wired in correctly — with audit-logging, approval gates, cost tracking.

How a SaaS build runs

The 6-phase engagement

SaaS builds are real engineering projects with explicit go/no-go gates between phases. You see weekly progress, and you can pause or pivot at any phase boundary.

1

Product & UX discovery

Founder workshops, user-journey mapping, feature scoping. We produce a 30-page product brief, a Figma user-flow map, and a "Phase 1 vs later" feature matrix. Outputs are yours regardless.

Weeks 1–2
2

Architecture & foundations

Repo, CI/CD, AWS infrastructure via Terraform, auth + tenancy + billing skeleton, observability stack. A first "hello world" tenant is live behind a feature flag.

Weeks 3–5
3

Core feature build

Iterative 2-week sprints, demos every Friday, weekly retros. Each sprint ships at least one shippable user-visible feature behind a flag, plus the backend behind it.

Weeks 6–14
4

Billing & lifecycle

Stripe Billing wired up properly. Plan tiers, proration, trials, dunning. Customer self-serve portal. Tested end-to-end with real cards.

Weeks 10–14
5

Hardening & private beta

Load test, security review (internal penetration test), POPIA review, performance tune. 5–10 design-partner customers onboarded into private beta.

Weeks 14–18
6

Public launch + warranty

Public sign-up open, marketing site cut-over, monitoring + on-call ramp-up. 90-day defect warranty with weekly check-ins. Deliberate handover to your team.

Month 5+
What walks away with you

Everything in the handover package

You own the code, the infrastructure, the docs, the accounts. We deliberately design for hand-off — your team or any competent agency should be able to take over.

Full source code

Every line MIT-licensed, pushed to your GitHub. Branching strategy, PR conventions, and code-review playbook documented in the repo README.

Terraform AWS infra

Every AWS resource defined in code, environment-specific configs, secrets in Secrets Manager, full disaster-recovery runbook.

Living architecture docs

C4-model diagrams, ADRs for every major decision, OpenAPI specs, ERDs, sequence diagrams — all versioned in the repo.

Test suites

Unit tests on domain logic, integration tests against real DB/Redis, Playwright E2E tests on critical user flows. CI gates enforce passing tests before merge.

Observability stack

Sentry, Datadog (or Grafana), dashboards, SLO definitions, alert routing to your on-call. You see issues before customers do.

90-day warranty + ramp

Every defect we ship, we fix free for 90 days. We pair-program with your team, review their PRs, and deliberately exit only when you're confident running solo.

What "built right" earns

The compounding gains of a real SaaS foundation

Indicative figures from recent SA SaaS builds, measured 12 months post-launch. Built-right SaaS doesn't just work today — it absorbs the next 18 months of growth without rebuild.

99.9%
Uptime · year 1
Across 5 active platforms
0
Cross-tenant data leaks
Multi-tenancy at ORM level
~3 days
Time-to-onboard a new tenant
Down from 2 weeks on legacy stacks
8.3×
User growth absorbed
Without a re-architecture
Indicative pricing — ZAR, ex VAT

How SaaS engagements are scoped

Every SaaS build is estimated bottom-up after a 2-week discovery sprint — these tiers are the bands we usually land in. 25% on signature, 25% on phase-2 demo, 25% on private beta, 25% on launch.

MVP

First product to first paying customer
From R100 000 · ex VAT
3–4 months · single-tenant scaffolded as multi
  • All 6 foundations from day one
  • ~10 core user-facing features
  • Stripe Billing wired (1 plan)
  • AWS af-south-1 + Terraform
  • Private beta with 5 customers
  • 90-day warranty
Scope an MVP

Scale & Enterprise

SSO · audit · multi-region · enterprise
POA
From R320 000 · 6–9 months
  • Everything in Growth, plus:
  • SAML / SSO · SCIM provisioning
  • Multi-region deployment
  • SOC2 / ISO27001 audit-ready
  • Mobile apps (iOS + Android)
  • Retained engineering pod
Talk to us about Scale
FAQ

The questions we get asked most

Honest answers about cost, risk, ownership, hand-off, and how to know if a custom SaaS is genuinely the right call.

Should I build my MVP on no-code first?
Often, yes. Bubble / Softr / Glide / Retool are brilliant for validating that anyone wants to pay for your idea. We've literally sent founders away to validate in no-code before spending real engineering money. Come back when you have 10 paying customers and a clear product-market signal — that's the right time to build properly. Building "real" too early is the most expensive way to validate an idea.
What if our requirements change mid-build?
They will. Every SaaS we've shipped has had a meaningful pivot between week 8 and week 14. We expect it. Our process leaves room: 2-week sprints, weekly demos, explicit feature-matrix re-prioritisation at every phase gate. The 6 foundations don't change; the features above them often do.
How do you handle scope creep?
We don't pretend it doesn't happen. We use a "feature matrix" — Phase 1 vs Phase 2+ vs deferred. New requests come in via a backlog, get scored on impact × effort, and either bump something else out of Phase 1 or move to Phase 2. We don't silently slip the date — we make the trade-off explicit. Honest tension over silent erosion every time.
What if you lose the team mid-build?
Every project ships its ADRs, OpenAPI specs, README runbooks, and weekly architecture-decision recordings into your repo. We use mainstream tech (Laravel, Next.js, PostgreSQL, AWS) that any competent SA agency can pick up. We've twice handed off mid-build to client teams; both shipped on time.
Will I be locked into you for maintenance after launch?
No. You own the code, the cloud accounts, every credential. Our 90-day warranty period includes deliberate pair-programming + PR review with your team, so when we exit you're genuinely capable. If you want to retain us afterwards we offer monthly engineering retainers from R22k/mo — but it's optional, not forced.
What about AI features?
We bake in our AI core where it adds value — LLM-powered search/summarisation/generation, with audit logging, approval gates for high-value actions, cost tracking, and prompt versioning. We're opinionated: AI features that make customers' jobs faster, not gimmicky AI-for-AI's-sake.
How are payments handled for SA customers?
Two patterns: (1) Stripe SA for SA card processing + ZAR settlement (now widely available); (2) Yoco-recurring or Paystack for SA-first SaaS where Stripe onboarding is unclear. For international, default to Stripe globally. We always tax-invoice with SA VAT correctly, sequentially numbered, archived for SARS.
What's POPIA compliance look like on a SaaS?
Built in, not bolted on: explicit consent capture, customer data export, customer data delete (cascade-aware), retention policies, audit log of every PII access, encrypted-at-rest, secrets in AWS Secrets Manager, breach-notification runbook, data-flow document for your information officer. We don't ship without this — and we walk your DPA through it on handover.

Tell us about your SaaS — we'll tell you honestly when to build properly.

Send us a paragraph on what you're building, who's it for, where you are today. We'll come back with a 45-minute product call, a recommended tier, and an indicative budget — and an honest "build later" answer if that's the right call.