Een SaaS-platform laten bouwen, van MVP tot schaal
Wij bouwen multi-tenant SaaS-platforms met tenant-architectuur, Stripe billing en observability die al vanaf de eerste sprint zijn ingericht op groei naar duizenden tenants.

Elke klant een eigen omgeving op hetzelfde platform, vanaf de eerste versie. Bekijk onze werkwijze →
Wat is SaaS Development?
SaaS development is het bouwen van een multi-tenant softwareplatform waarbij meerdere klanten met een gedeelde codebase werken, elk met eigen afgeschermde data. Het platform bevat vaste bouwstenen die al in de architectuur zitten: authenticatie, tenant-isolatie, subscription billing en monitoring. De keuze voor een pool-, bridge- of silo-model bepaalt hoe tenants van elkaar gescheiden zijn en hoe het platform kan meegroeien van een eerste MVP naar duizenden gebruikers. Worden deze fundamenten niet vanaf de start meegenomen, dan ontstaat vaak technische schuld die later moeilijk te herstellen is.
Onder meer gebouwd voor Tata Steel, M&G Investments, Digistore24, Toppers in Concert, Bar-le-Duc en Loogman
Van tenant-scheiding tot billing-logica: dit zijn de knelpunten die we het vaakst tegenkomen bij SaaS-platforms die uit hun MVP-fase groeien.

Tenant-scheiding hangt af van losse code-checks
Tenant ID's worden per query handmatig meegegeven in plaats van afgedwongen op databaseniveau. Een vergeten filter in een nieuwe endpoint betekent dat klant A data van klant B kan zien.

Billing zit los van het platform, niet erin
Upgrades, downgrades en mislukte betalingen worden handmatig rechtgezet in Stripe, omdat de abonnementslogica nooit gekoppeld is aan de features en limieten die een tenant daadwerkelijk krijgt.

Elke nieuwe klant vraagt een aanpassing in de code
Een custom domein, een SSO-koppeling voor een enterprise klant of een extra plan vereist telkens development werk in plaats van configuratie, waardoor sales moet wachten op engineering capaciteit.
MVP of meteen goed: wat je nu wel en niet moet bouwen
Een MVP is geen half product, het is een volledig product met een smalle scope. Het verschil is belangrijk. Wie functies half afmaakt om er meer in te proppen, levert iets op waar niemand mee wil werken en leert dus niets. Wie één ding echt goed doet, krijgt bruikbare antwoorden van echte gebruikers.
Tegelijk zijn er fundamenten die je niet later goedkoop invoegt. Multi-tenancy, de scheiding van klantdata, authenticatie en de manier waarop je facturatie modelleert: dat zijn keuzes in het datamodel. Ze achteraf inbouwen betekent in de praktijk migreren, en migreren met betalende klanten erop is duur en spannend.
- Smalle scope, geen half afgemaakte functies
- Multi-tenancy en datascheiding vanaf het datamodel
- Vooraf bepaald wat fundament is en wat later mag
Wat er stukgaat als je van tien naar duizend klanten gaat
De problemen die bij schaal opduiken, zijn zelden de problemen die je verwacht. Het is bijna nooit de rekenkracht. Het is de rapportage die over alle klanten heen queryt, de achtergrondtaak die per klant draait, de e-mail die bij elke wijziging verstuurd wordt, en de beheerder die niet meer kan overzien wat er in het systeem gebeurt.
Daarom bouwen we vanaf het begin met achtergrondverwerking, meetbare doorlooptijden en logging per klant. Niet omdat je dat op dag een nodig hebt, maar omdat het later toevoegen betekent dat je de bestaande stroom moet openbreken terwijl klanten hem gebruiken.
- Achtergrondverwerking en logging per klant
- Beheerdersomgeving zodat support niet bij development landt
- Doorlooptijden meetbaar vanaf de eerste versie
Je product is van jou, ook de code en de kennis
Bij een SaaS-product is de software je bedrijf. Dat maakt afhankelijkheid van je bouwer een risico dat je niet wilt lopen, hoe prettig de samenwerking ook is. Wij leveren daarom code, documentatie en de onderbouwing van architectuurkeuzes op, in jouw eigen repository en op jouw eigen infrastructuur.
Dat betekent ook dat we geen technologie kiezen die alleen wij kunnen onderhouden. We werken met breed gedragen stacks, zodat je een developer kunt aannemen die er meteen mee uit de voeten kan, of een andere partij kunt inschakelen zonder eerst een vertaalslag te betalen.
- Code en documentatie in jouw eigen repository
- Breed gedragen stacks, geen exotische afhankelijkheid
- ISO 27001 en ISO 9001, hosting binnen de EU
Geen generieke webapp-aanpak, maar architectuurkeuzes die specifiek zijn afgestemd op multi-tenant software die moet schalen.
Tenant-architectuur die vanaf dag 1 meegroeit
We kiezen bewust tussen een pool-, bridge- of silo-model per project, afhankelijk van schaal en compliance-eisen, in plaats van één opzet die na de eerste honderd tenants vastloopt. Row-level security en tenant-isolatie zitten in het fundament, niet als latere patch.
Stripe Billing tot in de randgevallen uitgewerkt
Recurring billing, usage-based pricing, proraties en dunning zijn onderdeel van de architectuur vanaf de eerste sprint, niet een integratie die er achteraf bij hangt. We weten precies waar het standaardmodel tegen zijn grenzen aanloopt en wanneer maatwerk nodig is.
Beveiliging vanaf de architectuur, niet als los project
Voor SaaS-platforms die aan enterprise klanten verkopen is een compliance-baseline vaak een showstopper in het salesproces. Wij zijn zelf ISO 27001 en ISO 9001 gecertificeerd; die certificering geldt voor onze organisatie en de vastgelegde scope. Los daarvan maken we vanaf de architectuur keuzes over toegang, scheiding tussen tenants, logging en incidentafhandeling, zodat de eerste security-vragenlijst geen verbouwing wordt.
Een werkend platform vanaf sprint 1
Na de eerste sprint draait er al een testbare omgeving met echte data, niet pas een demo bij oplevering.
Hardening voor livegang
Voor livegang toetsen we het platform met load tests per tenant, een pentest en een compliance-baseline, zodat kwaliteit niet pas achteraf blijkt.
Overdracht met runbooks en monitoring
Deploy-procedures, monitoring en architectuurkeuzes leggen we vast in documentatie, zodat het platform ook zonder ons team te beheren is.
- projecten opgeleverd
- terugkerende klanten
- uit 127 reviews
- ISO27001 en 9001 gecertificeerd
Drie manieren om aan software te komen, naast elkaar.
- Past op hoe jij werkt, niet andersomStandaardpakket: nee · Freelancer of klein bureau: ja
- Broncode en data zijn van jouStandaardpakket: nee · Freelancer of klein bureau: wisselt
- ISO 9001 en ISO 27001 gecertificeerdStandaardpakket: wisselt · Freelancer of klein bureau: zelden
- Koppelingen met wat er al draaitStandaardpakket: deels · Freelancer of klein bureau: ja
- Zegt het ook als een pakket beter pastStandaardpakket: nee · Freelancer of klein bureau: wisselt
- Design, software, data en AI in één teamStandaardpakket: nee · Freelancer of klein bureau: nee
- Beheer en doorontwikkeling na livegangStandaardpakket: via de leverancier · Freelancer of klein bureau: wisselt
- Vaste contactpersonen, kantoor in AmsterdamStandaardpakket: nee · Freelancer of klein bureau: wisselt
Discovery met architectuur keuzes (pool, bridge, silo), iteratieve build en handover naar interne teams.
- 01
Discovery en architectuurkeuzes (2 tot 4 weken)
We bepalen samen het tenant model (pool, bridge of silo), de billing strategie (Stripe Billing of Stripe Connect), de auth aanpak (Clerk, Auth0 of custom OIDC met SSO) en de compliance baseline die past bij je doelgroep. Deze keuzes liggen vast voordat er een regel code geschreven wordt, want ze zijn achteraf duur om te wijzigen.
- 02
Data model en tenant isolatie
We ontwerpen het database schema met row level security of schema per tenant, afhankelijk van het gekozen model. Migraties, seeding en tenant provisioning automatiseren we vanaf het begin, zodat nieuwe klanten zonder handmatig werk aangesloten kunnen worden.
- 03
MVP build in sprints (12 tot 20 weken)
We bouwen de kernfunctionaliteit in sprints van twee weken: multi tenant routing, Stripe billing, RBAC en de eerste feature set. Observability (logging, tracing, error tracking) zit vanaf sprint 1 in de codebase, niet als los project achteraf.
- 04
Production hardening
Voor livegang draaien we load tests op tenant niveau, een pentest en toetsen we de opzet aan ISO 27001 of SOC2 baselines. Runbooks, monitoring en een SLA stellen we op, zodat het platform ook zonder ons team beheerd kan worden.
- 05
Livegang en onboarding eerste tenants
We begeleiden de eerste klanten die het platform in gebruik nemen: provisioning testen onder echte omstandigheden, billing flows valideren en supportprocessen inrichten. Bugs die alleen bij echt gebruik zichtbaar worden, lossen we in deze fase direct op.
- 06
Doorontwikkeling en schaal
Na livegang bouwen we door met feature flags voor gecontroleerde rollouts en A/B testing. Groeit het aantal tenants, dan migreren we waar nodig van pool naar bridge of silo voor extra isolatie of compliance. We blijven betrokken in een hypercare periode voordat we overdragen aan je eigen team.
Een SaaS-platform is nooit af na livegang
- Monitoring per tenantWe bewaken gebruik, foutmeldingen, billing-events en performance per tenant, niet alleen op platformniveau.
- Uptime en incidentresponsWe bewaken beschikbaarheid tegen de afgesproken SLA en grijpen in bij storingen, load-pieken of billing-fouten.
- Beveiliging en tenant-isolatieWe patchen dependencies, controleren rechten en row level security policies en toetsen periodiek of tenantdata gescheiden blijft.
- Schalen met de tenantbaseWe volgen groei per tenant en migreren zwaardere klanten van pool naar bridge- of silo-model zodra dat nodig is.
- Doorontwikkeling en feature flagsWe rollen nieuwe features gecontroleerd uit via feature flags en verfijnen billingplannen op basis van tenantfeedback.

Geen accountmanager. Bij het eerste gesprek zit iemand die het werk zelf doet, vaak met een van de oprichters erbij. Daarna bouw je met een vast team vanuit ons kantoor in Amsterdam.
- Kantoor aan de Duivendrechtsekade in Amsterdam
- ISO 9001 en ISO 27001, gecertificeerd door Kiwa
- 500 projecten opgeleverd
- 4,8 uit 127 reviews

Een platform-dashboard gebouwd om meerdere labels tegelijk te bedienen.
Eén dashboard, meerdere klanten
Het label dashboard van VIRPP is gebouwd in Vue.js met een Laravel-backend op AWS, zodat platenlabels ieder hun eigen omgeving krijgen zonder dat er per klant apart gebouwd hoeft te worden.
Architectuur die vooruitkijkt
We ontwerpen de datamodellen en autorisatie zo dat een volgende klantgroep aansluit op de bestaande structuur, in plaats van dat elke uitbreiding een nieuw fundament vraagt.
Wat kost een SaaS-platform laten bouwen?
Een MVP met authenticatie, een multi-tenant fundament en Stripe-billing kost meestal tussen de 60.000 en 150.000 euro, afhankelijk van de complexiteit van het domein. Een volwaardig platform met SSO of industrie-specifieke logica loopt op tot 300.000 à 400.000 euro.
Wat is het verschil tussen pool, bridge en silo multi-tenancy?
Bij een pool-model delen alle tenants dezelfde database met row-level security, wat snel te bouwen is en past bij consumer- of MKB-SaaS onder duizend tenants. Bij een silo-model krijgt elke tenant een eigen database-instantie, nodig bij zware compliance-eisen of grote enterprise-klanten. Een bridge-model zit ertussenin: gedeelde infrastructuur met isolatie waar dat telt.
Hoe lang duurt het om een SaaS MVP te bouwen?
Een production-ready MVP met auth, multi-tenant fundament, billing en de kernfunctionaliteit duurt doorgaans twaalf tot twintig weken. De eerste twee tot vier weken gaan naar discovery en architectuurkeuzes, zodat het tenant-model en de billingstrategie vaststaan voordat de bouw start.
Werken jullie met Stripe voor subscription billing?
Ja, voor het overgrote deel van SaaS-projecten gebruiken we Stripe Billing, dat recurring billing, usage-based pricing, proraties en dunning standaard afdekt. Alleen bij zeer specifieke business rules of complexe multi-currency scenario's bouwen we maatwerk bovenop Stripe.
Wie host het SaaS-platform na oplevering?
Standaard draait het platform in jullie eigen cloudomgeving, zoals AWS, GCP, Azure of Hetzner, zodat je zelf eigenaar blijft van infrastructuur en data. Wil je dat wij het beheer overnemen, dan bieden we dat optioneel aan als managed SLA-pakket.
Wat zijn de meest voorkomende fouten in een SaaS-architectuur?
De drie fouten die we het vaakst tegenkomen bij het overnemen van een bestaand platform zijn een hardgecodeerd tenant-ID in plaats van row-level security, authenticatielogica die vermengd is met domeinlogica, en het ontbreken van feature flags vanaf het begin. Elk van deze drie kost achteraf al snel drie tot zes maanden refactorwerk om recht te trekken.
Kunnen jullie naast de webapp ook een mobiele app bouwen?
Ja, de meest gekozen combinatie is een Next.js webapplicatie met een React Native mobiele app die via een monorepo dezelfde TypeScript-types en API-laag deelt. Dat voorkomt dubbel werk en houdt web en mobiel in sync naarmate het platform groeit.
Neem direct contact met ons op. We komen zo snel mogelijk bij je terug


Je bericht komt bij ons team in Amsterdam binnen.


