In short
SaaS (software as a service) development means designing and building software so it can be offered to many customers over the internet on subscription. It is for start-ups launching a new product and for companies that want to turn an internal tool into one. CybUP handles MVP scoping, multi-tenant architecture, authentication, subscription infrastructure, cloud setup, security and monitoring.
Should a SaaS project start with an MVP?
Yes. For most SaaS projects the right start is an MVP (minimum viable product) that solves one problem well and can be put in front of real users. The point isn’t to build half the product but to test its value proposition with as few features as possible. Until users have a first version in their hands, you can’t know which features they really need.
When setting the MVP scope we ask of every feature: “Would the first customer pay without this?” Reporting screens, advanced settings and a mobile app can usually wait; sign-up, the core workflow and secure separation of customer data cannot. What gets cut is scope, not quality: even an MVP needs solid authentication, backups and tenant isolation, because changing them later is very expensive.
How do you build a multi-tenant SaaS architecture?
In a multi-tenant architecture a single application serves many customers (tenants), and each customer’s data is strictly separated from everyone else’s. The OWASP Multi-Tenant Security Cheat Sheet describes three basic approaches: a separate database per tenant, a separate schema in the same database, or row-level separation in shared tables. A separate database gives the strongest boundary but is harder to manage; shared tables are the most efficient but the most prone to mistakes.
With shared tables we don’t leave tenant isolation to application code alone. Using PostgreSQL row security policies, the database itself returns only the current tenant’s rows, so even if a query in the code forgets a filter, another customer’s data stays out of sight. The tenant ID is also carried into cache keys, file storage paths and background jobs. If a large enterprise customer wants a database of its own, a hybrid model can provide that too.
“Multi-tenant applications serve multiple customers (tenants) from a shared infrastructure, codebase, and often shared databases.”
How do you design authentication and subscriptions for a SaaS product?
Authentication planning covers secure password storage, email verification, two-factor authentication and, for enterprise customers, single sign-on through SAML or OpenID Connect. Each tenant has its own roles as well: account owner, administrator, user. If you don’t plan from the outset for one user belonging to several tenants, you will have to change the data model later.
On the subscription side we design the plans, per-user or usage-based limits, the trial period, and the upgrade and cancellation flows. Card details are never stored in the application’s own database; payments go through a payment service provider built for the job, and the application only knows the subscription status. Which provider fits depends on where your customers are and on your billing requirements.
How is SaaS infrastructure set up in the cloud?
We usually build SaaS infrastructure in an Azure or AWS account opened in your name, using a managed database, container-based application services and object storage. The account and resources belong to your company and are billed to you, so your product’s infrastructure is never held hostage in someone else’s account. We cover the cloud setup in more detail on our Azure and AWS setup page.
We define the infrastructure as code, so test and production environments are built from the same recipe and can be recreated even if one is lost. Code changes go live only after passing automated tests. If your customers process personal data in Türkiye, the region where that data is stored is one of the first architectural decisions to make under KVKK, Türkiye’s Personal Data Protection Law (Law No. 6698).
How do you keep a multi-tenant SaaS product secure as it scales?
SaaS security starts from the principle that one customer’s data must never, under any circumstances, be visible to another, and then carries on with standard web application security. Input validation, authorisation checks on every endpoint, secrets kept in a secrets management service rather than the code repository, and regular dependency updates are the basics. We recommend vulnerability scanning before launch and at regular intervals afterwards, and a WAF in front of the application where needed.
For scaling we design the application to be stateless: session data and files live in shared services, not on the application server, so more copies of the same application can be added when load rises. Long-running jobs (report generation, bulk email, file processing) are queued and run in the background. Say a SaaS that offers document management to accounting firms sees its load multiply at month end; thanks to queues and horizontal scaling, that peak doesn’t slow the interface down for other customers.
“However, multi-tenancy introduces critical security challenges: a single vulnerability can expose all tenants' data, misconfigurations can leak data across tenant boundaries, and resource contention can impact availability.”
How do you monitor a SaaS product in production?
A live SaaS product needs continuous monitoring of application errors, response times, database performance, queue length and infrastructure resources. Spotting a problem before your customer does is the most concrete way to keep trust in a subscription business. We centralise application logs and tag them with the tenant, so when a report comes in that something is wrong for a particular customer, the relevant logs can be found quickly.
Alongside the cloud provider’s own monitoring tools, Zabbix monitoring can be set up if part of the infrastructure is on premises. We test periodically that backups can actually be restored, and provide tools for per-tenant data export and for deleting data when an account is closed.
- Error and response time monitoring, with alerts when thresholds are breached
- Centralised application logs tagged with the tenant
- Automatic backups and periodic restore tests
- A per-tenant data export and deletion tool
Can an internal tool be turned into a SaaS product?
Yes, but it usually takes restructuring. A tool written in-house is generally built around a single company: users sit in one table, settings are hard-coded and there is no concept of a customer. Turning it into a product means adding a tenant model, moving company-specific rules into settings and building sign-up and subscription flows.
The first step is to review the existing code and data model. Sometimes it makes more sense to add a tenant layer to the existing code, sometimes to rewrite the core; we share the decision, with our reasoning, once the review is done. A company that built a custom CRM for its own sales team, for example, may want to offer it to other firms in its sector. The review is free.
What you receive
- An approved MVP scope, screen flows and data model
- A multi-tenant application with tenant isolation enforced in the database layer too
- Authentication, roles and subscription flows
- Test and production environments defined as code in your own cloud account
- An automated test and deployment pipeline
- Monitoring, alerting and backup routines
- Source code and technical documentation
How we work
- 1
Free review
We assess the product idea, target customers, any existing code or tools, and your timeline expectations.
- 2
Scope and architecture
MVP features, the tenant model, authentication and infrastructure decisions are put in writing.
- 3
MVP development
The product is built in short iterations and tried out with you at each stage.
- 4
Security and launch
Vulnerability scanning, load testing and monitoring are completed, and the product opens to its first customers.
- 5
Scaling and maintenance
New features, performance improvements and updates follow, guided by usage data.
Frequently asked questions
How long does it take to launch a SaaS MVP?
Depending on scope, an MVP can usually open to its first users within a few months. What affects the timeline most is how tightly the scope is kept. We give a phased schedule once the scope is agreed.
Who owns the source code and intellectual property?
You do. The contract provides for the source code and the rights to the product to be handed over to you, and cloud accounts are opened in your company’s name. The product stays entirely under your control.
Which technologies do you use?
We choose technology based on what the product needs, the likelihood of your own team taking it over, and how widely supported it is. We generally prefer mainstream, mature web technologies and established databases such as PostgreSQL. We set out the choice and the reasoning in the architecture document.
Do you host the SaaS product?
No. We set up and configure the infrastructure in an Azure or AWS account opened in your name; you own the resources and you are the one billed. We provide setup, configuration and, if you want it, maintenance.
How much does SaaS development cost?
We send a written quote once we have reviewed the scope; the review is free. The quote lists the MVP, later phases and maintenance as separate items; cloud usage charges are paid directly to the provider.
How do you build a KVKK-compliant SaaS product?
Data residency, tenant isolation, access logs, encryption, retention and deletion are designed in as part of the architecture. The legal side, such as contracts and privacy notices, is for your legal adviser to settle. We put the technical measures in place and document them.
Will you keep developing the product after launch?
If you wish, we carry on under a maintenance and development contract. If you plan to build your own team, we make the transition easier with documentation and a structured handover.