Bygde laget for betaling og tilgangsrettigheter — Stripe sammen med kjøp i appen hos Apple og Google — som styrer tilgangen til katalogen, søket og eksporten gjennom en tilgangsmodell på 11 tabeller som kontrolleres på serveren.

Situasjon. Penger er den delen av en plattform ingen får lov til å ta lett på. Et abonnement må tåle at et kort utløper, en refusjon, et planbytte, en webhook som kommer to ganger og en webhook som kommer i feil rekkefølge. I det øyeblikket betaling kan skje i tre salgskanaler — et kort på nettet, Apple i den ene appbutikken, Google i den andre — finnes det tre ulike fremstillinger av hva noen har kjøpt, og produktet trenger fortsatt ett svar på ett spørsmål: hva har denne personen lov til å gjøre akkurat nå?

Oppgave. Å ta imot penger og å gi tilgang måtte være to systemer i stedet for ett, slik at en ny salgskanal ikke skulle bety å skrive om hver eneste tilgangssjekk i produktet.

Handling. Stripe håndterer kort og abonnementer gjennom 18 Go‑filer, og kjøp i appen via Apple og Google kommer inn gjennom sin egen kvitteringsverifisering. Alle tre møtes i et databaseskjema for betalinger med 9 tabeller og 34 funksjoner — og stopper der. Det produktet faktisk spør om, er et eget databaseskjema for tilgang, 11 tabeller og 34 funksjoner, som svarer på «har denne kontoen lov til å gjøre dette?» uten å vite eller bry seg om hvilken salgskanal som betalte for det. Det svaret styrer tilgangen til bedriftskatalogen, søket og dataeksporten, og det kontrolleres på nytt på serveren ved hver forespørsel, fordi en skjult knapp er en høflighet og ikke en kontroll.

Resultat. Å legge til en salgskanal berører nå betalingssiden og lar tilgangssjekkene være i fred, og et brukerstøttespørsmål om noens tilgang har én tabell å se i i stedet for tre. Kostnaden er to skjemaer der et mindre produkt ville klart seg med ett, pluss et rettighetsoppslag på forespørsler som ellers ville vært gratis.