De meest voorkomende vraag die we van andere oprichters krijgen, gaat niet over prijzen of go-to-market. Het is een rustige, enigszins verdachte: Hoe onderhoudt een team van jouw omvang 150 modules zonder dat het geheel instort? Het eerlijke antwoord is dat we geen 150 modules onderhouden. Wij onderhouden één platform en daar bovenop een heel dun laagje. De truc is de meedogenloosheid over tot welke laag een bepaald werkstuk behoort.
De wiskunde die mensen bang maakt.
Als je je 150 modules voorstelt als 150 kleine applicaties – elk met zijn eigen datamodel, zijn eigen rechten, zijn eigen facturering, zijn eigen meldingen – dan zijn 22 mensen duidelijk krankzinnig. Dat zijn zes modules per engineer, elk een product op zich. Geen enkel team overleeft dat. De angst klopt, voor die architectuur.
Maar dat is niet de architectuur. Een CRM, een factureringstool en een helpdesk zien er voor een gebruiker uit als drie verschillende producten. Daaronder bevinden zich dezelfde handvol primitieven: records, relaties, een tijdlijn met gebeurtenissen, rollen en machtigingen, geld, documenten en een meldingenbus. De verschillen zitten vooral in de woordenschat en de lay-out, niet in de machines.
We bouwen geen 150 geweldige producten. We bouwen een klein aantal goedgebouwde primitieven, op 150 manieren geconfigureerd.
De kern/module splitst.
Al het harde leeft in de kern, en het is één keer gebouwd: identiteit, machtigingen, de relationele gegevenslaag, betalingen, bestandsopslag, zoeken, het auditlogboek, het notificatiesysteem, de exportengine. Dit zijn de onderdelen die echt moeilijk zijn en die echt gedeeld worden. Een hier opgeloste bug wordt voor alle 150 modules tegelijk opgelost. Een mogelijkheid die hier wordt toegevoegd, bijvoorbeeld elektronische handtekeningen, wordt onmiddellijk beschikbaar voor elke module die daar behoefte aan heeft.
Een module is dus bewust dun gemaakt. Het is een dataschema, een reeks weergaven, een workflow of twee, en de woordenschat voor één taak. "CRM" is een configuratie die zegt: deze recordtypen zijn leads en deals, dit is de pijplijnweergave, dit zijn de fasen, dit is wat een conversie betekent. Het rijdt volledig op de kern. Een nieuwe module bestaat voornamelijk uit declaratie, en niet uit code.
De harde regel: verdien uw uniciteit.
De discipline die ervoor zorgt dat dit niet vergaat, is één enkele regel, die bij herziening wordt afgedwongen: een module mag niet bijzonder zijn, tenzij deze deze ook daadwerkelijk heeft verdiend. Elke keer dat een module zijn eigen op maat gemaakte toestemmingsmodel, zijn eigen eenmalige notificatieformaat, zijn eigen privémanier om een datum op te slaan wil, is het standaardantwoord nee. Duw het tot de kern als een algemene vaardigheid, of doe het niet.
Dit is op dit moment vervelend en door de jaren heen doorslaggevend. De meeste 'we hebben hier iets op maat nodig'-verzoeken zijn eigenlijk 'we hebben niet goed genoeg nagedacht over het algemene geval'. Wanneer je het algemene geval forceert, wordt de kern rijker, profiteert elke module ervan, en blijft de oppervlakte die je moet behouden ongeveer vlak, zelfs als het aantal modules stijgt.
Wat we hebben opgegeven.
Deze aanpak brengt reële kosten met zich mee, en die moeten we benoemen. Een eersteklas puntentool, gebouwd door een team dat geobsedeerd is door één taak, zal onze gelijkwaardige module voor die ene taak overtreffen. Het diepste e-mailplatform heeft automatisering die wij niet hebben. De diepste projecttool heeft visies die wij niet hebben. Wij doen niet alsof het anders is.
Waar we die diepgang voor inruilen is samenhang: modules die één datamodel, één login, één factuur, één export en één notificatielaag delen. Voor een team van 5 tot 50 personen is die samenhang meer waard dan de laatste 20% van de diepgang in welke categorie dan ook. Voor een team waarvan de hele activiteit in die ene categorie valt, is dat niet het geval. We weten precies voor wie we zijn en de architectuur is de reden dat we ze met 22 man kunnen bedienen.