SERVICESSAAS DEVELOPMENTSaaS platform development, from MVP to scale
We build multi-tenant SaaS platforms with tenant architecture, Stripe billing and observability, set up from the first sprint to grow to thousands of tenants.
ISO 9001 & 27001
Every customer gets their own environment on the same platform, from the first version. See our approach →
What is SaaS Development?
SaaS development is building a multi-tenant software platform where multiple customers work on a shared codebase, each with their own isolated data. The platform contains fixed building blocks that are part of the architecture from the start: authentication, tenant isolation, subscription billing and monitoring. Choosing a pool, bridge or silo model determines how tenants are separated and how the platform can grow from a first MVP to thousands of users. If these foundations aren't in place from the start, the result is often technical debt that's hard to fix later.
Built for clients including Tata Steel, M&G Investments, Digistore24, Toppers in Concert, Bar-le-Duc and Loogman
From tenant separation to billing logic: these are the bottlenecks we come across most often in SaaS platforms growing out of their MVP phase.
Tenant separation depends on scattered code checks
Tenant IDs are passed manually with every query instead of being enforced at database level. One forgotten filter in a new endpoint means customer A can see customer B's data.
Billing sits next to the platform, not inside it
Upgrades, downgrades and failed payments are fixed by hand in Stripe, because the subscription logic was never tied to the features and limits a tenant actually gets.
Every new customer needs a code change
A custom domain, an SSO integration for an enterprise customer or an extra plan requires development work every time instead of configuration, so sales has to wait for engineering capacity.
MVP or done right: what to build now and what to leave
An MVP isn't half a product, it's a complete product with a narrow scope. The difference matters. If you half-finish features to squeeze more in, you ship something nobody wants to use, so you learn nothing. If you do one thing really well, you get useful answers from real users.
At the same time, some foundations can't be cheaply added later. Multi-tenancy, separation of customer data, authentication and the way you model billing: those are choices in the data model. Building them in afterwards means migrating in practice, and migrating with paying customers on board is expensive and nerve-racking.
- Narrow scope, no half-finished features
- Multi-tenancy and data separation from the data model up
- Agreed up front what's foundation and what can wait
What breaks when you go from ten to a thousand customers
The problems that surface at scale are rarely the ones you expect. It's almost never computing power. It's the report that queries across all customers, the background job that runs per customer, the email sent on every change, and the administrator who can no longer see what's happening in the system.
That's why we build with background processing, measurable lead times and per-customer logging from the start. Not because you need it on day one, but because adding it later means breaking open the existing flow while customers are using it.
- Background processing and logging per customer
- An admin environment, so support doesn't end up with development
- Lead times measurable from the first version
Your product is yours, including the code and the knowledge
With a SaaS product, the software is your business. That makes depending on whoever built it a risk you don't want to take, however good the working relationship. So we deliver code, documentation and the reasoning behind architecture choices, in your own repository and on your own infrastructure.
It also means we don't choose technology only we can maintain. We work with widely used stacks, so you can hire a developer who can get going straight away, or bring in another supplier without first paying for a translation exercise.
- Code and documentation in your own repository
- Widely used stacks, no exotic dependencies
- ISO 27001 and ISO 9001, hosting within the EU
Not a generic web app approach, but architecture choices tailored specifically to multi-tenant software that has to scale.
Tenant architecture that grows from day one
We make a deliberate choice between a pool, bridge or silo model per project, depending on scale and compliance requirements, instead of one setup that gets stuck after the first hundred tenants. Row-level security and tenant isolation are in the foundation, not patched in later.
Stripe Billing worked out down to the edge cases
Recurring billing, usage-based pricing, proration and dunning are part of the architecture from the first sprint, not an integration bolted on afterwards. We know exactly where the standard model reaches its limits and when custom work is needed.
Security from the architecture up, not as a separate project
For SaaS platforms selling to enterprise customers, a compliance baseline is often a showstopper in the sales process. We are ISO 27001 and ISO 9001 certified ourselves; that certification applies to our organisation and its defined scope. Separately, we make choices about access, separation between tenants, logging and incident handling from the architecture up, so the first security questionnaire doesn't turn into a rebuild.
A working platform from sprint 1
After the first sprint there's already a testable environment with real data, not just a demo at delivery.
Hardening before go-live
Before go-live we test the platform with load tests per tenant, a penetration test and a compliance baseline, so quality doesn't only become clear afterwards.
Handover with runbooks and monitoring
We document deployment procedures, monitoring and architecture choices, so the platform can be managed without our team too.
- projects delivered
- returning clients
- from 127 reviews
- ISO27001 and 9001 certified
Three ways to get software, side by side.
- Fits the way you work, not the other way roundOff-the-shelf package: no · Freelancer or small agency: yes
- You own the source code and the dataOff-the-shelf package: no · Freelancer or small agency: varies
- ISO 9001 and ISO 27001 certifiedOff-the-shelf package: varies · Freelancer or small agency: rarely
- Integrations with what's already runningOff-the-shelf package: partly · Freelancer or small agency: yes
- Tells you when a package is the better fitOff-the-shelf package: no · Freelancer or small agency: varies
- Design, software, data and AI in one teamOff-the-shelf package: no · Freelancer or small agency: no
- Management and further development after go-liveOff-the-shelf package: via the vendor · Freelancer or small agency: varies
- Dedicated contacts, office in AmsterdamOff-the-shelf package: no · Freelancer or small agency: varies
Discovery with architecture choices (pool, bridge, silo), an iterative build and handover to internal teams.
- 01
Discovery and architecture choices (2 to 4 weeks)
Together we decide on the tenant model (pool, bridge or silo), the billing strategy (Stripe Billing or Stripe Connect), the auth approach (Clerk, Auth0 or custom OIDC with SSO) and the compliance baseline that suits your audience. These choices are fixed before a single line of code is written, because they're expensive to change later.
- 02
Data model and tenant isolation
We design the database schema with row-level security or a schema per tenant, depending on the chosen model. We automate migrations, seeding and tenant provisioning from the start, so new customers can be onboarded without manual work.
- 03
MVP build in sprints (12 to 20 weeks)
We build the core functionality in two-week sprints: multi-tenant routing, Stripe billing, RBAC and the first feature set. Observability (logging, tracing, error tracking) is in the codebase from sprint 1, not a separate project afterwards.
- 04
Production hardening
Before go-live we run load tests at tenant level and a penetration test, and check the setup against ISO 27001 or SOC 2 baselines. We put runbooks, monitoring and an SLA in place, so the platform can be managed without our team too.
- 05
Go-live and onboarding the first tenants
We guide the first customers who start using the platform: testing provisioning under real conditions, validating billing flows and setting up support processes. Bugs that only show up in real use are fixed straight away in this phase.
- 06
Further development and scale
After go-live we keep building with feature flags for controlled rollouts and A/B testing. As the number of tenants grows, we migrate from pool to bridge or silo where needed for extra isolation or compliance. We stay involved through a hypercare period before handing over to your own team.
A SaaS platform is never finished after go-live
- Monitoring per tenantWe monitor usage, errors, billing events and performance per tenant, not just at platform level.
- Uptime and incident responseWe monitor availability against the agreed SLA and step in during outages, load spikes or billing errors.
- Security and tenant isolationWe patch dependencies, review permissions and row-level security policies, and periodically check that tenant data stays separated.
- Scaling with your tenant baseWe track growth per tenant and migrate heavier customers from the pool to a bridge or silo model as soon as that's needed.
- Further development and feature flagsWe roll out new features in a controlled way using feature flags and refine billing plans based on tenant feedback.
No account manager. Your first conversation is with someone who does the work, often with one of the founders. After that you build with a dedicated team from our office in Amsterdam.
- Office on the Duivendrechtsekade in Amsterdam
- ISO 9001 and ISO 27001, certified by Kiwa
- 500 projects delivered
- 4.8 from 127 reviews
A platform dashboard built to serve multiple labels at once.
One dashboard, multiple customers
VIRPP's label dashboard is built in Vue.js with a Laravel backend on AWS, so each record label gets its own environment without anything being built separately per customer.
Architecture that looks ahead
We design the data models and authorisation so the next customer group plugs into the existing structure, instead of every extension needing a new foundation.
How much does it cost to build a SaaS platform?
An MVP with authentication, a multi-tenant foundation and Stripe billing usually costs between €60,000 and €150,000, depending on the complexity of the domain. A full platform with SSO or industry-specific logic can run to €300,000 to €400,000.
What's the difference between pool, bridge and silo multi-tenancy?
In a pool model all tenants share the same database with row-level security, which is quick to build and suits consumer or SME SaaS with fewer than a thousand tenants. In a silo model each tenant gets its own database instance, which is needed for heavy compliance requirements or large enterprise customers. A bridge model sits in between: shared infrastructure with isolation where it matters.
How long does it take to build a SaaS MVP?
A production-ready MVP with auth, a multi-tenant foundation, billing and the core functionality usually takes twelve to twenty weeks. The first two to four weeks go into discovery and architecture choices, so the tenant model and billing strategy are fixed before the build starts.
Do you use Stripe for subscription billing?
Yes, for the vast majority of SaaS projects we use Stripe Billing, which covers recurring billing, usage-based pricing, proration and dunning as standard. Only for very specific business rules or complex multi-currency scenarios do we build custom logic on top of Stripe.
Who hosts the SaaS platform after delivery?
By default the platform runs in your own cloud environment, such as AWS, GCP, Azure or Hetzner, so you remain the owner of the infrastructure and data. If you'd like us to take over management, we offer that as an optional managed SLA package.
What are the most common mistakes in SaaS architecture?
The three mistakes we come across most often when taking over an existing platform are a hardcoded tenant ID instead of row-level security, authentication logic mixed in with domain logic, and no feature flags from the start. Each of these easily costs three to six months of refactoring to put right afterwards.
Can you build a mobile app alongside the web app?
Yes, the most popular combination is a Next.js web application with a React Native mobile app that shares the same TypeScript types and API layer through a monorepo. That avoids duplicate work and keeps web and mobile in sync as the platform grows.
Related services
Get in touch with us directly. We'll get back to you as soon as we can
Your message goes straight to our team in Amsterdam.