Bygde back office for operatørene — rundt 40 administrasjonsruter og 128 komponenter for eierskapskrav, moderering, funksjonsflagg, cache og diagnostikk — slik at plattformen kan driftes uten databasetilgang.

Situasjon. Hver plattform får i det stille en applikasjon nummer to, og det er som regel den ingen planlegger. Noen må godkjenne et eierskapskrav, skjule en omtale, slå på en funksjon for en del av brukerne, tømme en cache eller finne ut hvorfor én konto ser noe merkelig. Når den applikasjonen ikke finnes, er svaret en ingeniør med en databasekonsoll — noe som er tregt, uten logg, og én skrivefeil unna en hendelse.

Oppgave. Den daglige driften av plattformen måtte være mulig uten shell‑tilgang, slik at driften tilhørte den som hadde vakt, og ikke den som hadde påloggingsinformasjonen.

Handling. Backoffice‑løsningen endte på rundt 40 administrasjonsruter bygget av 128 komponenter, og den dekker arbeidet slik det faktisk kommer inn: avgjøre krav om eierskap til selskaper, moderere omtaler og innlegg, slå funksjonsflagg av og på, inspisere og tømme cacher, lese diagnostikk, og rapporteringen daglig leder ber om. Den kjører på det samme designsystemet og den samme genererte API‑klienten som det offentlige produktet, og det var det avgjørende valget — et internt verktøy bygget på sin egen teknologistack blir den delen ingen oppdaterer, og deretter den delen ingen stoler på.

Resultat. De som drifter plattformen, kan drifte den, og hver handling går gjennom den samme autorisasjonen og etterlater det samme sporet som alt annet. Det er en stor flate å holde testet og universelt utformet for et lite internt publikum, og den kostnaden er løpende. Det er likevel billigere enn alternativet, som er en ingeniør som skriver UPDATE mot produksjon klokken ni en søndag kveld.