SaaS Product Development
We design and build SaaS products: multi-tenant architecture, subscriptions and billing, roles and access control, a public API. We take a product from business model to operation and growth. We work with companies in Almaty and across Kazakhstan.
- Multi-tenant
- Subscriptions
- Billing
What is custom SaaS product development?
SaaS development means building a cloud service that many independent companies use on a subscription basis. At its core are a multi-tenant architecture that isolates each client's data, user accounts, billing, roles and permissions, a public API, and an admin panel for the product owner.
Who it is for
Product founders
You have a validated idea for a subscription service. You need an engineering partner who will design the architecture, build the first version, and avoid decisions that surface as problems once the product grows.
Companies with an internal system
An internal product has covered the company's own needs — and could cover them for the whole industry. We turn the system into a multi-tenant service: data isolation, pricing plans, self-service client sign-up.
Existing SaaS products
The product already earns subscriptions, but the architecture is holding it back: releases have become risky and the load keeps growing. We run an audit and build a refactoring and scaling roadmap.
Niche experts
Deep knowledge of an industry — salons, clinics, logistics, accounting — can become a service the market pays for monthly. We help translate that expertise into the product's business logic.
What we solve
When do you need SaaS rather than a regular web application?
SaaS makes sense when many independent companies will use one product — each with its own data, users, and plan. If only one company needs the system, a web application is enough; SaaS adds multi-tenant architecture, billing, and customer self-service.
How does billing work in a SaaS product?
SaaS billing covers pricing plans, trial periods, recurring charges, and limit enforcement. It is built on payment gateways: the system issues invoices on its own, restricts overdue accounts, and gives the owner subscription reports.
Can a SaaS launch as a first version with a minimal feature set?
Yes — a working strategy is a first version built around the core value: a customer portal, a subscription, and two or three key scenarios. The architecture is designed so new modules can be added without rewriting the product.
What do you do when a SaaS stops handling the load?
Start with a technical audit: measure the bottlenecks in the database, the API, and background jobs. Then comes a scaling plan: caching, queues, horizontal infrastructure growth. That is cheaper than rewriting the product from scratch.
What development includes
items
- Multi-tenant architecture with each client's data isolated
- Personal accounts for users and organizations
- Roles and permissions inside client accounts
- Subscriptions and billing: plans, trial periods, payment acceptance
- Public API and webhooks for integrations
- Owner admin panel: clients, plans, subscription metrics
- Onboarding and self-service client sign-up
- QA: automated tests for critical flows and billing
- Infrastructure, monitoring, and a scaling plan
How much SaaS costs: InterLAB references
The product grows in versions: first an MVP with one scenario and payments, then multiple client companies, roles and integrations.
| Format | What is included | Reference | Timeline |
|---|---|---|---|
| SaaS MVP | One scenario, user account, subscription and payments, admin panel | 3–6 million ₸ | 8–12 weeks |
| Turnkey SaaS | Multiple client companies in one system, roles, billing, integrations, analytics | 6–15 million ₸ | 3–5 months |
| Platform | Open API, single sign-on (SSO), high load and security requirements | from 15 million ₸ | in stages |
| Support | Infrastructure, monitoring, updates and development | from 300,000 ₸ per month | after launch |
These are ranges, not a price list: we give a preliminary estimate broken down by version after a brief. The price depends on the pricing and billing model, the number of roles and integrations.
Contract, payment and warranty
The same terms for every B2B project: payments are tied to accepted results, and a stage price does not change after it starts.
| Term | How we work |
|---|---|
| Payment for smaller projects | Projects up to 3 million ₸ and the MVP sprint: 50% upfront, 50% after acceptance |
| Payment for larger projects | ERP, CRM, SaaS, portals — in stages of 1–2 months: 30% before a stage, 70% after the stage is accepted and signed off |
| Stage price | Fixed before the start. New requirements are estimated separately and taken on only with your approval |
| Warranty | 6 months after acceptance: we fix defects in our code free of charge — whenever the system does not work as agreed |
| Not covered by the warranty | New features and changed requirements, as well as failures caused by changes in third-party systems (a 1C update, a new bank or service API) — that is support |
| Code and access | Owned by the client from the first commit: repository, servers and keys are on your accounts. NDA on your template or ours |
The terms are fixed in the contract before work begins.
Multi-tenancy: three models for isolating client data
The model is chosen at the design stage — it is expensive to change once clients are already working in the system. A product usually starts with a shared database, and a large client can be moved to a dedicated one when needed.
| Model | How it works | When it fits | Trade-offs |
|---|---|---|---|
| Shared database | All clients share the same tables, and every row carries a client identifier; PostgreSQL Row-Level Security policies filter out other clients' rows inside the database itself | Product launch, many small clients with the same functionality | Cheapest to run, one migration for everyone. Requires isolation tests and limits so that one busy client does not slow down the rest |
| Schema per client | A shared database server, with each client getting its own schema of tables | A small number of clients who need a more explicit separation of data | Migrations repeat for every schema; cross-client reports are harder to build |
| Database per client | A separate database or server for each client, with shared application code | Large clients with requirements on data location, separate backups and load | Most expensive: backups, monitoring and migrations for every database; updates roll out across all databases in turn |
The models can be combined: most clients in the shared database, a large client in a dedicated one, with a single product codebase.
Subscriptions, roles, admin panel, analytics and API
Parts found in almost every SaaS product. What goes into the first version and what waits for growth is decided at the design stage.
Subscriptions and billing
Beyond plans and trials: mid-cycle plan changes with proration, card auto-billing or payment by invoice, retries on failed charges with a notice to the client, payment history and documents in the account.
Roles inside a client account
The account owner manages billing and users, an administrator configures the workspace, employees work in their own sections. Invitations by email, offboarding a departing employee in one action; single sign-on (SSO) for large clients.
Product owner's admin panel
Clients with their plan, payment status and activity; support actions — extend a trial, grant a payment deferral, block an account, open a client account to investigate a request. Every such action is recorded in the audit log.
Product analytics
Subscription metrics — MRR, churn, trial-to-paid conversion — and product events: where clients reach first value and where they abandon setup.
Public API and webhooks
API keys scoped to the account, rate limits by plan, API versioning so that updates do not break clients' integrations, and documentation. Webhooks notify external systems about events: a payment, a status change, a new object.
Isolation testing
Automated tests verify isolation: on every release they try to read and modify another client's data, and the release does not ship if they succeed. The application connects to the database with a role that cannot bypass isolation policies.
Deployment, monitoring and support
A SaaS product is updated constantly, and clients use it every day. That is why the path a change takes to production and the way the service is observed are designed together with the product.
- 01
Separate environments
Development, a staging environment with anonymised data, and production are kept apart. A new feature reaches clients only after it has passed staging.
- 02
CI/CD and zero-downtime migrations
Every change goes through automated tests and code review. Database migrations are written so that the old and new versions of the application can work with the database at the same time — a release does not require stopping the service.
- 03
Gradual rollout
Risky features are switched on with feature flags: first for the team and a few clients, then for everyone. If something goes wrong, the feature is switched off without a new release.
- 04
Monitoring and alerts
Errors, API response times, background job queues and failed payment charges go to a dashboard and to alerts. The team learns about a problem from a notification, not from a client complaint.
- 05
Backups
Database backups run on a schedule, and restoring from them is regularly tested on staging: an untested backup can let you down exactly when you need it.
- 06
Support and growth
Handling requests from the service's clients, fixes, dependency updates and new modules along the roadmap. Response times and the escalation procedure are set out in the support agreement.
Support is a separate format with monthly billing; the reference is in the pricing table above.
Useful before we talk
How SaaS development works
- 01
Brief and business model
We work through the product's scenarios, pricing logic, and market. A preliminary scope and cost estimate follows after the brief.
- 02
Design
Architecture, data model, tenant isolation scheme, version roadmap. Mistakes at this stage cost the most, which is why it is separate and mandatory.
- 03
Development
Backend, frontend, billing, and API — in two-week sprints. Each sprint ends with a demo of the working product, not a slide deck.
- 04
Launch
Production environment, payment acceptance, monitoring, and alerts. The first wave of clients goes through onboarding under the team's supervision.
- 05
Growth
Subscription and retention metrics drive the roadmap. From there it is ongoing support: new modules, optimization, scaling as the client base grows.
Get your project assessed before development starts
Describe the task in the form below — we reply within a business hour and suggest the next step: a call, a review or an estimate.
Architecture and stack
TypeScript on both backend and frontend lowers the cost of mistakes: the data contract is checked before release, not on live clients. PostgreSQL enforces tenant isolation at the database level, while Redis and job queues absorb peak load. CI/CD with automated tests lets us ship updates frequently and without taking the service down.
- TypeScript
- Next.js
- Node.js
- PostgreSQL
- Redis
- REST API
- Docker
- CI/CD
Integrations
A SaaS rarely lives in isolation: clients expect connections to accounting, payments, and messengers. We connect payment gateways for subscriptions, data exchange with 1C, and notifications in Telegram and WhatsApp. The product's public API opens integrations to its own clients as well.
Payment gateways, Kaspi, 1C, Telegram, WhatsApp, Email services, Analytics
InterLAB projects in this area
Real work with a dated status: what's live, what's still in development, where it's a demo.
status as of Oct 12, 2026
Questions and answers
InterLAB references: a SaaS MVP (one scenario, subscription and payments, admin panel) is 3–6 million ₸ and 8–12 weeks; a turnkey SaaS with multiple client companies, roles and billing is 6–15 million ₸ and 3–5 months; a platform with an open API and single sign-on starts from 15 million ₸ in stages; support starts from 300,000 ₸ per month. These are ranges, not a price list: we give a preliminary estimate broken down by version after a brief.
One installation serves all clients: updates ship once, infrastructure costs less, and product metrics are collected centrally. Data stays isolated at the database level — clients never see each other.
Yes, in stages. First, a client identifier and isolation policies are added to the code and the database; then each copy's data is migrated into the shared database with reconciliation of control figures. Clients are switched over one at a time, and the old copy stays available until reconciliation confirms that everything has been moved.
Billing supports both paths: card auto-billing through a payment gateway and invoicing. With payment by invoice, access is extended once the payment is confirmed — manually in the admin panel, or automatically from bank data if a bank integration is connected.
You do. The repository is created in your organization from the first commit — along with documentation and access to the infrastructure.
Tenant isolation at the database level, roles and permissions, encrypted connections, backups, and an activity log. Security requirements are fixed at the design stage, not after an incident.
Support and growth: monitoring, fixes, new modules per the roadmap. Decisions about the next features are driven by subscription metrics and client behavior.
When client scenarios call for working from a phone — yes. The product's API is designed so the web portal and the mobile app share one set of business logic without duplicated code.
Deep dives in the blog
Related services
Got a project?
We'll scope and estimate it — for free.
Tell us about the product or the problem. After reviewing the task we'll come back with an architecture, a timeline and a price for the first version.
- Scope and risks estimated before we start
- NDA — yours or ours
- Work starts within a week