We have built a SaaS platform. Ours.
Multi-tenancy, subscription billing, plan enforcement, per-customer branding, custom domains, and every operational problem that arrives once real customers depend on it. We did not read about these — we shipped them, and we still run them.
SaaS is easy to demo and hard to operate
The first version is deceptively quick. Then the second customer arrives and every assumption about one shared database gets tested. Then someone wants their own domain. Then a card fails mid-renewal. Then a customer asks which of their staff opened a record in March.
None of that is visible in a prototype. All of it is architecture, and retrofitting tenant isolation or idempotent billing into a running product is dramatically harder than building it in — sometimes it means starting again.
Clasify is our own answer to those questions, in production: academies as isolated tenants, each on its own branding and optionally its own domain, with subscriptions, quota enforcement, live video, recording, and a payment path built so a lost response cannot double-charge anyone.
What a real SaaS needs underneath
Every item here is something we built and still run ourselves — not a service line we have only read about.
Tenant isolation
Every query scoped to a tenant, enforced in the data layer rather than remembered by each developer. One missed filter is a customer reading another customer’s data.
Subscriptions that survive failure
Idempotency keys and claim-before-charge, so a timeout after a successful charge cannot bill twice. Renewals, dunning retries, grace periods and promo codes handled — and a refund or void taken at the gateway reconciled back into your own ledger.
Plan limits actually enforced
Quotas checked on the server at the point of use, not merely displayed on a pricing page. Otherwise the free tier quietly costs you the most.
White-label and custom domains
Per-tenant branding, and customers on their own domain with certificates issued automatically — including making sure vendor pages never appear on a customer’s host.
Self-serve signup to first value
Signup, payment-gated provisioning, and the path to a customer’s first real use — the stretch that decides whether anyone converts.
An operator console
The internal tool you need by month two: inspect an account, change a plan, extend or reset a subscription, suspend an account, investigate a complaint — without anyone opening a database client.
Knowing before your customers do
Metrics, health and readiness endpoints, and alerts that reach a human. Learning about downtime from a support email is a choice you make in advance.
Deploys you can undo
Builds pinned to an image digest with a one-command rollback, and migrations run deliberately rather than automatically on boot. When something is wrong at 2am you need reverse, not a debugger.
How we build a SaaS
The same sequence on every engagement, whatever the stack.
1. Settle the hard parts first
Tenancy model, billing model, and the permission model. These three are the ones that cannot be changed cheaply later, so they get decided before feature work starts.
2. Narrow product, complete spine
Few features, but signup, billing, permissions and operations all real. A demo with fake billing tells you nothing about whether the business works.
3. Run it with you
Monitoring, backups, on-call runbooks and the first weeks of live traffic alongside your team, until operating it is genuinely routine.
Straight answers
The questions that actually come up on a first call.
Yes — Clasify, the product this site sells. Multi-tenant with per-tenant branding and custom domains, subscription billing through a payment gateway, live WebRTC classrooms with a self-hosted relay, session recording to object storage, quota enforcement, an operator console and a full monitoring stack. You can sign up and inspect it yourself.
With fewer features, yes. With a fake spine, no. The common mistake is an MVP that skips billing, permissions and tenancy — the exact parts that are expensive to add later. Narrow the product, not the foundation.
Depends on where you collect. We have shipped a full integration with Paymob, including the intention flow, webhook reconciliation and exactly-once charging, and the same patterns port to other gateways. We will recommend based on your market and settlement terms, not on familiarity.
No. We work on paid engagements, which keeps the advice honest — including advice to build less than you asked for.
Building a SaaS product?
Tell us the idea and where you are. We will come back with an architecture sketch and a scope for a first version that is small but genuinely complete.
Every project starts with a scoping conversation and a written estimate before any code is written. No retainer required to talk.