Hvordan GoRabbit ble til, fortalt av den som trengte den først.
I tretti år har konsulentvirksomheten min tatt mellom sytti og hundre timer i uken. Alt det andre kom på toppen: fotografering, formidling, utleie, en rekke nettbutikker — rundt tjue av dem er det blitt gjennom årene. Og konsulentdelen hadde sitt eget synlighetsbehov, for i finansmarkedet må du holde kontakten vedlike om du skal bli spurt.
Alt dette trengte markedsføring. Ingen av delene fikk det.
Og det var ikke av uvitenhet. Jeg kunne satt meg ned med hvem som helst og pekt ut hva de burde publisert denne uken og hvorfor. Jeg hadde bare ikke én time til å gjøre det selv. Så ble det liggende, og regningen kom som den alltid gjør: i omsetning som aldri kom.
Jeg brukte år på å lete etter noe å kjøpe. Problemet var sjelden at produktene var dårlige — det var at hvert av dem dekket én skive av en virksomhet, mens jeg hadde flere virksomheter som ikke lignet hverandre. Det jeg trengte, lå alltid i sprekken mellom to produkter.
Til slutt gikk det opp for meg at selve spørsmålet var feil. Jeg ba om én pakke som skulle favne foto, utleie, formidling og publisering samtidig. Noe slikt lages ikke, og det er det god grunn til. Svaret måtte være komponenter som utvekslet data seg imellom.
Den erkjennelsen burde kommet mye tidligere, for det er omtrent det eneste jeg kunne fra før.
Fra 1980 og utover arbeidet jeg med finanssystemer, og den gangen skrev jeg koden selv — i språk som i dag står i museum. Jeg var testleder, prosjektleder og databaseadministrator. Utover nittitallet gikk jeg fra å bygge enkeltsystemer til å tegne hvordan systemer skulle henge sammen, og siden fulgte år som toppleder, blant annet i finans og som ansvarlig for konsulentdivisjonen i et amerikansk IT-konsern.
Ett oppdrag sier mest. For et stort dansk finanskonsern designet jeg en integrasjonsløsning som lot maskinparken de allerede eide spille på lag, framfor at de skulle erstatte den med noe altomfattende. Prislappen ble en brøkdel, og de årlige driftskostnadene falt med rundt førti prosent.
Jeg visste altså godt hvordan deler skal settes sammen. Jeg hadde bare ikke skrevet en av dem selv siden nittitallet.
Jeg skriver ikke moderne kode, og jeg kommer ikke til å lære det nå. Men å kunne formulere en oppgave skarpt nok — datagrunnlaget, resultatet, og oppførselen den dagen noe ryker — viste seg å være verdt mer enn syntaks. Jeg beskrev problemet, testet svaret og justerte kursen. Det er rollen jeg hadde hatt i tre tiår, bare med noen i andre enden som svarte med en gang.
Den aller første utgaven var regneark og tastaturmakroer på en helt vanlig Mac. Den gjorde jobben for meg, og den var samtidig helt uaktuell å selge videre: en maskin som står hjemme og klikker seg gjennom dagen, tåler ikke å ha kunder på seg. Så ble arkene til datastrukturer, makroene til kode, og publiseringen til noe en server kunne håndtere på egen hånd.
Den første versjonen beviste at det gikk. Da jeg viste den frem, fikk jeg et svar jeg har hatt nytte av siden: folk likte tanken, men skjønte ikke hva jeg løste for dem. Den andre snudde på det og handlet ikke om hva systemet kunne, men om hva du slipper å gjøre når du har det. Den traff.
Og så gjorde jeg det som kostet mest og betalte seg best: jeg satte min egen løsning under lupen mot personvernreglene, markedsføringsloven og Metas vilkår, før noen andre rakk det. Konklusjonen var ubehagelig entydig. Den opprinnelige idéen min — et system som leste grupper og svarte automatisk på folks livshendelser — var ikke lov, og kom aldri til å bli det.
Det vanskeligste i prosjektet var altså ikke teknisk. Det var å avlive min egen beste idé mens den fortsatt virket, uten at noen hadde bedt meg om det. Versjonen som kom ut av det, er den som er i drift i dag.
Jeg hadde ingen planer om å selge dette til noen. Jeg nevnte det etter hvert til folk jeg snakker med uansett — kolleger, bekjente i andre bransjer, og et par konkurrenter. De sa det samme, alle sammen: de visste hva de burde gjort, men hadde ikke kapasitet til å gjøre det ved siden av å drive selve virksomheten.
At en konkurrent sier det høyt, er verdt å legge merke til. Folk pynter på det meste, men ingen pynter på at markedsføringen har stått stille i to år.
GoRabbit er motoren som driver småbedriften: atten moduler rundt én kjerne, som dekker markedsføring, salg, nettbutikk, kundedialog, regnskap og kontroll. Informasjonen legges inn én gang og brukes overalt. Og én regel står over alle andre, som arv fra den runden med regelverket: systemet foreslår, mennesket bekrefter.
En god del av den er gjenbruk. Medieovervåkingen stammer fra et verktøy jeg laget for å følge spansk presse, og fra rapporten jeg brukte på egne investeringer gjennom tretti år. Kontrollmodulen er eldst av alle — slike oppsett har jeg levert til kunder siden nittitallet. Det er ikke to års arbeid som ligger her. Det er et yrkesliv, sortert.
Første kunde var meg selv. Den første som ikke var meg, var et lite forlag som gir ut dialektpoesi — omtrent så langt fra serverrom som man kommer, og nettopp derfor en god test. For nå måtte hele kjeden stå uten meg i midten: påmelding med samtykke som kunne dokumenteres, en bekreftelse som faktisk kom frem og ikke havnet i søppelposten, et klikk som verifiserte, selve leveransen, og til slutt en plass på e-postlisten som tålte å bli ettergått. Jeg satt og fulgte loggene mens det skjedde, og det er en annen følelse enn å teste selv.
Du abonnerer på GoRabbit månedlig, uten bindingstid. Det er hovedveien inn, og den er sånn fordi et produkt som trenger binding for å beholde kundene, sier noe om produktet.
For den som ikke kan legge penger på bordet før hun vet at det virker, finnes det i tillegg noen innganger der vi bærer risikoen i stedet — nettbutikk mot en andel av salget er den mest brukte. Jeg vet nemlig godt hvordan det føles å betale åtti tusen for en butikk før man har solgt én eneste ting.
Hele historien, inkludert alt som gikk galt underveis, står i boka «Jeg kan ikke kode — men bygde et system likevel».
Morten von Hafenbrädl
Grunnlegger, GoRabbit · NiceLife.no