One platform, every customer isolated and billed

The first architectural decision is how tenants share infrastructure. A pooled model puts every customer in the same database with a tenant identifier on each row. It is the cheapest to run and the quickest to ship, but isolation depends on discipline in the code. A schema-per-tenant or database-per-tenant model costs more to operate and gives stronger separation, easier per-customer backup and simpler data export.

Most products land on a hybrid: pooled by default, with a dedicated option for customers who pay for it or whose sector demands it. We make that choice with you from three inputs: who your customers are, what a data incident would cost, and how many tenants you expect in the first two years.

Whatever the model, we enforce isolation in layers, with row-level rules in the database, tenant context set once at the request boundary, and automated tests that try to cross the line on purpose. Noisy-neighbour controls such as rate limits and per-tenant quotas keep one large customer from slowing everyone else down.

Subscription billing looks simple until plans change mid-cycle. We model plans, trials, seats, add-ons and metered usage explicitly, with proration rules written down and tested. Payment methods follow your buyers: cards, mada and bank-transfer invoicing for larger accounts.

If your platform issues tax invoices on behalf of tenants or for your own subscriptions, ZATCA e-invoicing rules apply, and they are far easier to satisfy when the invoice data model is designed for them from the start. Personal data held for your tenants falls under the Personal Data Protection Law, so we build consent records, purpose limits, export and deletion as product features.

Public-sector and regulated buyers often ask about alignment with National Cybersecurity Authority controls and about where data sits. We design the platform so it can be deployed in an in-Kingdom cloud region and so tenant-level audit logs are available, then document the controls you can show during a customer's security review. We do not claim certification on your behalf.

A SaaS product is a service you run, not a file you hand over. Before launch we set up environment separation, automated deployment, database backups with tested restores, error tracking and alerting on the signals that matter, such as failed payments, queue backlogs and slow queries.

We also build the tools your own team will use daily: a console to create and suspend tenants, view usage, and impersonate a user for support with every action recorded. These save more time in the first year than most customer-facing features.

A realistic timeline for a first production release is 10 to 16 weeks, depending on integrations and the number of user roles. We stage it so that the tenant core and billing are live early, and refinements follow in short releases. After launch you can keep us on a monthly support plan, or take over with the documentation and runbooks we hand you.