Det mest almindelige spørgsmål, vi får fra andre stiftere, handler ikke om priser eller gå-på-markedet. Det er en stille, lidt mistænkelig en: hvordan vedligeholder et hold på din størrelse 150 moduler, uden at det hele falder sammen? Det ærlige svar er, at vi ikke vedligeholder 150 moduler. Vi vedligeholder én platform og et meget tyndt lag ovenpå. Tricket er hensynsløsheden over, hvilket lag et givent værk tilhører.
Matematikken, der skræmmer folk.
Hvis du forestiller dig 150 moduler som 150 små applikationer - hver med sin egen datamodel, sine egne tilladelser, sin egen fakturering, sine egne notifikationer - så er 22 mennesker åbenlyst sindssyge. Det er seks moduler pr. ingeniør, hver et produkt i sin egen ret. Ingen hold overlever det. Frygten er korrekt, for den arkitektur.
Men det er ikke arkitekturen. Et CRM, et faktureringsværktøj og en helpdesk ligner tre forskellige produkter for en bruger. Nedenunder er de den samme håndfuld primitiver: optegnelser, relationer, en tidslinje med begivenheder, roller og tilladelser, penge, dokumenter og en notifikationsbus. Forskellene er for det meste ordforråd og layout, ikke maskineri.
Vi bygger ikke 150 fantastiske produkter. Vi bygger et lille antal velbyggede primitiver, konfigureret på 150 måder.
Kernen/modulopdelingen.
Alt hårdt lever i kernen, og det er bygget én gang: identitet, tilladelser, det relationelle datalag, betalinger, fillagring, søgning, revisionsloggen, notifikationssystemet, eksportmotoren. Det er de dele, der er virkelig svære og ægte delte. En fejl, der er rettet her, er rettet for alle 150 moduler på én gang. En funktion tilføjet her - f.eks. e-signaturer - bliver øjeblikkeligt tilgængelig for hvert modul, der ønsker det.
Et modul er altså bevidst tyndt. Det er et dataskema, et sæt visninger, en arbejdsgang eller to og ordforrådet for ét job. "CRM" is a configuration that says: these record types are leads and deals, this is the pipeline view, these are the stages, here's what a conversion means. Den kører helt på kernen. Et nyt modul er for det meste deklaration, ikke kode.
Den hårde regel: tjen din unikhed.
Den disciplin, der forhindrer dette i at rådne, er en enkelt regel, der håndhæves ved gennemgang: et modul må ikke være specielt, medmindre det virkelig har fortjent det. Hver gang et modul ønsker sin egen skræddersyede tilladelsesmodel, sit eget engangsmeddelelsesformat, sin egen private måde at gemme en dato på - standardsvaret er nej. Skub det ind i kernen som en generel evne, eller lad være med at gøre det.
Dette er irriterende i øjeblikket og afgørende over år. De fleste "vi har brug for noget tilpasset her"-anmodninger er virkelig "vi har ikke tænkt hårdt nok over den generelle sag." Når du fremtvinger den generelle sag, bliver kernen rigere, hvert modul gavner, og det overfladeareal, du skal vedligeholde, forbliver nogenlunde fladt, selvom modultallet stiger.
Hvad vi opgav.
Denne tilgang har en reel omkostning, og vi bør nævne den. Et best-of-breed-punktværktøj, bygget af et team, der er besat af ét job, vil udover vores tilsvarende modul på det ene job. Den dybeste e-mail-platform har automatisering, som vi ikke har. Det dybeste projektværktøj har synspunkter, vi ikke har. Vi foregiver ikke andet.
Det, vi handler den dybde for, er sammenhæng - moduler, der deler én datamodel, ét login, én regning, én eksport og ét meddelelseslag. For et hold på 5-50 er denne sammenhæng mere værd end de sidste 20 % af dybden i en enkelt kategori. For et team, hvis hele forretning er den ene kategori, er det ikke. Vi ved præcis, hvem vi er til, og arkitekturen er grunden til, at vi kan betjene dem med 22 personer.