Byggde skiktet för betalningar och åtkomsträttigheter — Stripe vid sidan av köp i appen via Apple och Google — som spärrar katalogen, sökningen och exporten bakom en åtkomstmodell i 11 tabeller som kontrolleras på servern.

Situation. Pengar är den del av en plattform som ingen har råd att vara nonchalant med. En prenumeration måste klara ett kort som går ut, en återbetalning, ett planbyte, en webhook som kommer två gånger och en webhook som kommer i fel ordning. I samma stund som betalning kan ske i tre försäljningskanaler — ett kort på webben, Apple i den ena appbutiken, Google i den andra — finns det tre olika versioner av vad någon har köpt, och produkten behöver ändå ett enda svar på en enda fråga: vad får den här personen göra just nu?

Uppgift. Att ta betalt och att ge behörighet måste vara två system och inte ett, så att en ny försäljningskanal inte skulle innebära att varje spärr i produkten måste skrivas om.

Handling. Stripe hanterar kort och prenumerationer genom 18 Go‑filer, och köp i apparna hos Apple och Google kommer in via sin egen kvittoverifiering. Alla tre strålar samman i ett betalningsschema med 9 tabeller och 34 funktioner — och stannar där. Det som produkten faktiskt ställer sina frågor till är ett separat åtkomstschema, 11 tabeller och 34 funktioner, som svarar på ”får det här kontot göra det här?” utan att veta eller bry sig om vilken försäljningskanal som betalade. Det svaret styr åtkomsten till företagskatalogen, sökningen och dataexporten, och det verifieras på nytt på servern vid varje anrop, eftersom en dold knapp är en artighet och inte ett skydd.

Resultat. Att lägga till en försäljningskanal berör nu betalningssidan och lämnar spärrarna orörda, och en supportfråga om någons åtkomst har en tabell att slå upp i stället för tre. Kostnaden är två scheman där en mindre produkt skulle nöja sig med ett, plus ett behörighetsuppslag på anrop som annars hade varit gratis.