Fra idé til lansert CRM: slik bygde vi Altiv

De fleste CRM-systemer er laget for store organisasjoner og tilpasset ned. Vi gjorde det motsatte. Her er valgene bak Altiv — og hva vi ville gjort annerledes.

Det finnes allerede mange CRM-systemer. Noen av dem er svært gode. Så hvorfor bygge et til?

Svaret handler mindre om funksjoner enn om utgangspunkt. De store systemene er bygget for organisasjoner med egne CRM-ansvarlige, implementeringsprosjekter og opplæringsbudsjett. Når en bedrift med femten selgere tar dem i bruk, skrur de av nitti prosent og sitter igjen med noe som er dyrere og mer tungvint enn regnearket de kom fra.

Altiv startet med et enklere spørsmål: hva om systemet var klart på minutter, og gjorde de få tingene et salgsteam faktisk trenger, uten at noen måtte lære det bort?

Vi bestemte oss for hva det ikke skulle være

Den mest verdifulle øvelsen tidlig var å skrive ned hva vi ikke skulle bygge. Ikke markedsføringsautomatisering. Ikke kundeservice-moduler. Ikke et rapportverktøy man må ta kurs i. Ikke tilpasningsmuligheter som gjør at to bedrifter ender med to helt forskjellige systemer.

Det som ble igjen var kjernen: hvem har vi kontaktet, hvor langt er vi kommet, hva er neste steg, og hva tjener vi. Fire spørsmål. Alt i Altiv finnes fordi det svarer på ett av dem.

Sikkerhet i databasen, ikke i koden

Når flere bedrifter deler samme system, er det ett krav som betyr mer enn alle andre: ingen skal noen gang se andres data. Den vanlige måten å løse det på er å filtrere i applikasjonskoden — hver spørring får et tillegg om at den bare gjelder din bedrift.

Problemet er at det holder å glemme det én gang. Ett endepunkt uten filteret, og data lekker mellom kunder. Vi la derfor reglene i selve databasen, med Row Level Security i PostgreSQL. Da er det databasen som nekter, ikke koden som husker — og en glemt sjekk i applikasjonen fører til at spørringen returnerer ingenting, ikke at den returnerer noe den ikke skulle.

Det er tregere å komme i gang med, og det er verdt hver time. Sikkerhetsmodellen er ikke noe man reparerer i etterkant.

Kjedelig teknologi, med vilje

Stacken bak Altiv er bevisst udramatisk: Next.js og React i grensesnittet, TypeScript gjennom hele, PostgreSQL via Supabase, Stripe til abonnement, Resend til e-post, og Vercel til drift.

Ingen av valgene er spennende, og det er poenget. Vi skal drifte dette i mange år. Da er det viktigere at teknologien har god dokumentasjon, mange som kan den, og en tydelig oppgraderingsvei, enn at den er ny og elegant. Den mest undervurderte egenskapen ved et rammeverk er hvor lett det er å forstå koden din to år etter at du skrev den.

Det å lansere er ikke å bli ferdig

Vi trodde, som alle gjør, at lansering var målstreken. Den er startstreken. Første gang ekte selgere brukte Altiv en hel arbeidsdag, lærte vi mer på åtte timer enn på ukene før — ikke om feil, men om hva folk faktisk gjør. Hvor de klikker først. Hva de leter etter og ikke finner. Hvilke felt de fyller ut og hvilke de hopper over.

Det er derfor vi bygger ting som er små nok til å endres. Er du sikker på at du har rett, bygger du stort. Vet du at du kommer til å lære noe, bygger du noe du tør å kaste.

Hva vi ville gjort annerledes

• Sluppet noen inn tidligere. Vi brukte for lang tid på å polere før noen utenfor fikk se det. Tilbakemeldingene vi ventet på, hadde vi kunnet få uker før.
• Tatt betalingsløsningen først. Vi utsatte Stripe fordi det ikke føltes som produktarbeid. Det viste seg å påvirke hvordan hele kontostrukturen måtte se ut.
• Skrevet ned avgjørelsene. Ikke dokumentasjon av koden, men av hvorfor vi valgte som vi gjorde. Et halvår senere husker ingen begrunnelsen, bare resultatet.

Vurderer du å bygge et system for din egen bransje, er du velkommen til å ta kontakt. Vi deler gjerne det vi lærte — også de delene som var dyre.