Meer klanten, meer omzet. Op het dashboard ziet groei er altijd goed uit. Maar er is een getal dat bijna niemand bijhoudt en dat bepaalt of die groei houdbaar is: wat het kost om één klant te bedienen. Groeit dat getal mee met je omzet, dan werk je harder voor hetzelfde resultaat. Groeit het langzamer, dan wordt je product met schaal juist winstgevender.
Dat verschil wordt niet in de boekhouding gemaakt. Het wordt in de architectuur gemaakt, vaak maanden eerder, op een moment dat niemand er nog naar keek.
Kort antwoord
- Duurzame groei betekent dat de kosten per klant of per transactie dalen of gelijk blijven naarmate je schaalt.
- De FinOps-praktijk noemt dit cloud unit economics: totale infrastructuurkosten gedeeld door de geleverde eenheden van waarde.
- Kies één eenheid die past bij je product: kosten per klant, per transactie, per rit, per analyse of per modelaanroep.
- Zonder meting ontdek je te laat dat een tarief verlies maakt. Een tier die 7,20 euro kost en 8 euro opbrengt laat niets over voor support en ontwikkeling.
- Kosten zijn een architectuurvraagstuk: caching, wachtrijen, dataopslag en hoe je AI-aanroepen inricht bepalen de rekening.
- Eén meting kan een duur subsysteem verbergen. Voeg pas een tweede metriek toe als die een andere beslissing ondersteunt.
Wat cloud unit economics betekent
Cloud unit economics is het vertalen van technische kosten naar de taal van het bedrijf. In plaats van één groot bedrag per maand kijk je naar wat één eenheid van waarde kost. De formule is eenvoudig: de toegerekende infrastructuurkosten gedeeld door het aantal geleverde eenheden.
De kunst zit in het kiezen van de juiste eenheid. Voor een product dat voornamelijk verzoeken afhandelt is "kosten per verzoek" logisch. Voor een abonnementsproduct is "kosten per klant" beter. Voor een analyseplatform is het "kosten per analyse". Voor AI-werk is "kosten per modelaanroep" of "kosten per token" het meest direct.
De FinOps Foundation, de beroepsvereniging achter deze praktijk, maakt onderscheid tussen bedrijfsmetrieken zoals kosten per klant en efficiëntiemetrieken zoals kosten per verzoek. Het eerste vertelt je of je verdienmodel klopt. Het tweede vertelt je of je techniek efficiënt is. Je hebt ze meestal allebei nodig, maar voor verschillende beslissingen.
Waarom dit meer is dan een financiële exercitie
Het verleidelijke van unit economics is dat het een cijfer oplevert. Het gevaarlijke is dat een cijfer pas waarde heeft als iemand het gebruikt om iets te veranderen. Een meting die alleen in een rapportage verdwijnt, is administratie.
Waar het echt iets doet, is op het snijvlak van techniek en commercie. Wanneer je weet dat het bedienen van één klant drie euro aan infrastructuur kost, kun je prijzen met vertrouwen in plaats van met een gevoel. Wanneer je weet dat een specifieke functie het grootste deel van je rekening veroorzaakt, kun je beslissen of die functie het waard is. En wanneer je weet dat je kosten per klant stijgen naarmate je groeit, weet je dat er een architectuurprobleem is voordat het zich in de marge uit.
Bedrijven ontdekken dit vaak te laat. Stel: een SaaS-bedrijf vraagt 8 euro per maand voor een instaptarief en ontdekt later dat het bedienen van een klant in dat tarief 7,20 euro kost. Er blijft vrijwel niets over voor support, verkoop of ontwikkeling. Het tarief aanpassen lost dat op, maar het getal had maanden eerder bekend kunnen zijn.
Kosten zijn een architectuurvraagstuk
Het is makkelijk om cloudkosten als een factuur te zien die je achteraf probeert te drukken. In de praktijk worden ze bepaald door beslissingen die je tijdens het bouwen neemt. Hoe je data opslaat, of je cachet, of je werk in wachtrijen zet in plaats van synchroon, hoe vaak je een model aanroept en of je dat slim doet: dat alles bepaalt de rekening.
Een paar voorbeelden. Een overzichtspagina die elke keer opnieuw alle records uit de database haalt, kost bij tien gebruikers niets en bij tienduizend gebruikers veel. Een AI-functie die bij elk paginaverzoek een model aanroept in plaats van resultaten te bewaren, schaalt lineair mee met je verkeer. Een systeem dat alle ruwe data oneindig bewaart in plaats van samen te vatten, groeit mee met de tijd zonder dat je er iets voor terugkrijgt.
Geen van deze dingen is fout op het moment dat je ze bouwt. Ze zijn fout op het moment dat je schaalt en niemand ze heeft herzien. Daarom is kostenbewust bouwen geen bezuiniging achteraf. Het is een eigenschap van de architectuur.
Van meten naar sturen
De praktijk begint bij het toewijzen van kosten aan onderdelen. Zonder tagging en kostenhiërarchie weet je niet welk deel van de rekening bij welke functie hoort. Dat is de reden dat veel teams wel een totaalfactuur hebben en geen enkel idee waar het geld heen gaat.
Begin klein. Kies één eenheid, meet die consequent en zorg dat de meting dezelfde blijft wanneer je groeit. Voeg pas een tweede metriek toe wanneer die een andere beslissing ondersteunt. Een bedrijf dat kosten per actieve gebruiker meet terwijl de engineering naar verzoeken en achtergrondtaken kijkt, meet twee dingen en stuurt op geen van beide.
Voor AI- en machine learning-werk komt daar iets bij: kijk naast de kosten ook naar de kwaliteit en snelheid van wat je levert. Kosten per token zonder oog voor nauwkeurigheid of latentie kan een goedkope oplossing belonen die gebruikers wegjaagt. De meting moet dus altijd iets zeggen over waarde, niet alleen over uitgaven.
Conclusie
Duurzame groei is niet meer omzet met meer kosten. Het is meer waarde leveren tegen dezelfde of lagere kosten per eenheid. Dat lukt alleen als je weet wat een eenheid kost, als je die wetenschap gebruikt bij het bouwen en als je architectuur meegroeit met je klanten in plaats van erachteraan te lopen.
Wil je weten wat het bedienen van één klant of één transactie in je product werkelijk kost? GitCity kijkt graag met je naar de architectuur, de infrastructuur en het verdienmodel erachter. Neem contact op voor een eerste gesprek zonder verplichtingen.