Så du vurderer å vibe-kode ditt eget CRM?

Du har en helg, en AI-assistent og en visjon. Hvor vanskelig kan det være? Kontakter, avtaler, en pipeline-visning — det er jo bare CRUD, ikke sant? (Red: akronym-guide til ikke-utviklere: Create, Read, Update, Delete).

Det er her det starter å bli interessant. Fordi spørsmålet om å bygge eller kjøpe et CRM ser ut som et teknisk spørsmål.

Det er det ikke.

Det er et kommersielt prioriteringsspørsmål i forkledning. Svaret forteller deg noe vesentlig om hva teamet egentlig bruker energien sin på.

Et CRM er ikke det du tror det er

CRM som begrep ble etablert på 90-tallet. Siebel Systems var pioneren, og det var et rendyrket salgsverktøy. Kjernelogikken var account management: hvem eier hvilke kunder, hva er status i pipeline, hva skjedde sist vi snakket. Bygget for store B2B-salgsteam med lange salgssykler og mange selgere som trengte å koordinere seg rundt de samme accountsene.

Salesforce digitaliserte og skalerte den samme logikken på nett fra 1999. Men grunnfilosofien var den samme: CRM som system of record for salgsteamet.

Det som er faglig interessant: den opprinnelige akademiske definisjonen av CRM er bredere enn dette. Gartner og andre definerte CRM som en forretningsstrategi for å administrere alle relasjoner med kunder og potensielle kunder på tvers av hele organisasjonen. Ikke bare salg. Men programvaren, og dermed begrepet i markedet, ble kapret av salgsavdelingen.

HubSpot er faktisk nærmere den opprinnelige, brede definisjonen. Et system som binder hele den kommersielle organismen sammen. Marketing, salg, service, data.

Hvorfor er dette relevant når du vurderer å bygge ditt eget? Fordi det definerer hva du faktisk prøver å bygge. Hvis du ser på det som en kontaktdatabase med pipeline-tracking kan du ende opp med å løse et smalt problem og kalle det et CRM. Dette er en feil som skaper følgefeil som vokser seg verre og mer kompleks over tid.

Et CRM er ikke en database. Det er et system for å håndtere gapet mellom menneskelig hukommelse og forretningsrelasjoner i skala. Verdien ligger ikke i datafeltene. Den ligger i det som skjer rundt dem:

• Delt kontekst. Kollegaen din kan ta over en kundedialog uten å spørre «hva diskuterte vi sist?»
  
  
• Prosesshåndhevelse. Avtaler beveger seg gjennom steg med obligatoriske felt, slik at ingenting faller mellom sprekkene.
  
  
• Aggregert innsikt. Pipeline-rapporter betyr noe bare når det er nok data til å vise mønstre.
  
  
• Automatisering. Lead-ruting, oppfølgingspåminnelser og eskaleringsregler er bare viktige når volumet er høyt nok til at ting faktisk blir oversett.

Kjernen i et CRM er genuint enkel å bygge. Det er alt rundt kjernen som er produktet.

Den enkle delen

Selve kjernen er rett frem:

• Kontakter og selskaper — navn, e-poster, telefonnumre, relasjoner mellom dem. Standard databasestoff.
  
  
• Avtaler med steg — en Kanban-tavle der du drar kort mellom kolonner. Hvert frontend-rammeverk har et dra-og-slipp-bibliotek.
  
  
• Notater og aktivitetslogging — tekstfelt med tidsstempler.
  
  
• Grunnleggende filtrering og søk — Postgress håndterer dette for tusenvis av poster uten å svette.

Hvis behovene dine stopper ved at du bare trenger en personlig kontaktdatabase med avtalesporing, kan du bygge noe genuint nyttig på en helg. En Next.js-app med Postgres, deployet på Vercel eller Railway. Det er et legitimt resultat.

Hvis du er en selvstendig konsulent som sporer 200 kontakter og 30 aktive avtaler, kan et skreddersydd verktøy tilpasset nøyaktig hvordan du jobber, være bedre enn å betale for HubSpot.

Der det blir interessant

I det øyeblikket du vil at CRM-et ditt skal gjøre det du forventer at et CRM skal gjøre, eskalerer ting raskt. Ikke fordi en enkelt funksjon er umulig, men fordi de påvirker hverandre.

E-post

Her treffer de fleste hjemmesnekrede CRM-prosjekter veggen. Det er flere lag.

Å se e-poster på kontaktkort krever synkronisering med innboksen din: OAuth-flyter med Gmail eller Outlook, håndtering av token-fornyelse, polling eller webhooks for nye meldinger, matching av e-poster til kontakter — folk har flere adresser — og tråding av samtaler, der e-posttråd-headere er inkonsekvente på tvers av klienter. Nylas selger et API for dette til 3–7 dollar per konto per måned, fordi å bygge det selv er genuint flere måneders arbeid.

Å sende e-poster fra CRM-et betyr enten å rute gjennom Gmail/Outlook-APIer med ratebegrensninger og autentiseringskompleksitet, eller å bruke en sendetjeneste som SendGrid. Vil du ha sporing — åpnet de den, klikket de? — legger du til pikselsporing og lenkeomskriving. Begge deler er stadig mer upålitelige på grunn av Apple Mail Privacy Protection og bedriftssikkerhetsverktøy som forhåndsklikker på hver lenke.

Automatiserte sekvenser betyr å bygge en arbeidsflytmotor med varig tilstand som overlever server-restarter. Du er nå i jobbkø-territoriet.

For en enkeltbruker er det praktiske svaret ofte: ikke synk e-post. BCC en dropbox-adresse, eller lenk til Gmail-tråder manuelt. Det er ikke elegant, men det er ærlig om innsatsen.

Kalender

Synkronisering av møter høres enkelt ut helt til du håndterer to forskjellige kalender-APIer, gjentakende hendelser med tidssone-hjørnetilfeller, og toveis synkronisering som ikke skaper uendelige oppdateringsløkker. Vil du ha «book et møte med meg»-lenker, bygger du tilgjengelighetsberegning på tvers av flere kalendere, tidssonekonvertering og håndtering av race conditions — to personer som booker samme tidsluke.

For en enkeltbruker: lenk til Calendly eller Cal.com og noter møter manuelt.

Egendefinerte felt

Enhver CRM-bruker vil til slutt spore noe systemet ikke har et felt for. Kontraktfornyelsesdato. Nedtrekksmeny for leadkilde.

Dette virker trivielt. Bare legg til en kolonne i databasen. Men hvis brukere skal kunne opprette felt uten en kode-deploy, bygger du et skjemastyrings-UI. Og de egendefinerte feltene må være søkbare, filtrerbare og dukke opp i rapporter.

Datamodellbeslutningen, JSON-kolonne, EAV-tabell, dynamisk ALTER TABLE etc, er et av de mest konsekvenstunge arkitekturvalgene i et CRM, og det er vanskelig å endre i ettertid. For en enkeltbruker som kan redigere kode: bare legg til kolonner etter behov. Det er faktisk en fordel med hjemmesnekring.

Ting du ikke tenker på før du trenger dem

Deduplisering. Du importerer kontakter fra en CSV. Du synker fra e-post. Du får dem fra et webskjema. Nå har du tre poster for samme person — «John Smith», «J. Smith» og «john@acme.com» uten navn. Å matche og slå sammen disse er et uløst problem i det generelle tilfellet. Selv Salesforce bommer. For en enkeltbruker med hundrevis av kontakter er manuell dedupe greit. For tusenvis vil du ønske du hadde tenkt på dette tidligere.

Databerikelse. Selskapsstørrelse, bransje, LinkedIn-profil, telefonnummer mm. Hvor kommer det fra når alt du har er en e-postadresse? Tjenester som Apollo eller People Data Labs tar betalt per oppslag, fra 30 øre til 5 kroner per stykk. De store CRM-ene inkluderer dette fordi de har data fra millioner av brukere. Det er en nettverkseffekt du ikke kan kopiere alene. CRM-et ditt vil ha tynnere poster enn HubSpots gratisversjon.

Mobiltilgang. Selgere lever på telefonene sine. En responsiv webapp får deg et stykke på vei, men den vil ikke ha push-varsler, offline-tilgang eller den raske fangst-følelsen til en native app.

Sikkerhetskopiering og gjenoppretting. CRM-et ditt er nå kilden til sannhet for hvert forhold og hver avtale i virksomheten. Hva skjer når en migrering går galt? Du trenger automatiserte sikkerhetskopier, og du må faktisk ha testet gjenoppretting minst én gang.

Enkeltbruker-begrensningen

Her er det som er vanskelig å se fra innsiden: et CRM bygget for én person optimaliserer for feil ting.

Et CRM er egentlig ikke et personlig produktivitetsverktøy. Verdien kommer fra delt kontekst, prosesshåndhevelse og aggregert innsikt — ting som bare betyr noe når det er flere mennesker og nok volum til å skape mønstre. En enkeltbruker med et håndterbart antall kontakter kan ofte holde alt dette i hodet, i et regneark eller i en enkel notisapp.

Overheaden med å vedlikeholde et skreddersydd CRM — hosting, oppdateringer, sikkerhetskopier, feilrettinger når et API endrer seg — kan overstige tiden det sparer.

Det ærlige spørsmålet å stille seg selv: Bygger jeg dette fordi det gjør meg mer effektiv, eller fordi å bygge det høres mer interessant ut enn å drive salg?

Det er ikke et retorisk spørsmål. Det er en diagnostikk. Aktivitet som føles produktiv fortrenger altfor lett aktivitet som faktisk er produktiv. Å bygge verktøy er håndgripelig og tilfredsstillende. Å drive salg er uforutsigbart og krevende.

Når egenbygd faktisk gir mening

Bransjespesifikke arbeidsflyter. Jobber du i eiendom, rekruttering eller en bransje der generiske CRM-er tvinger deg inn i kronglete omveier, kan et skreddersydd verktøy formet etter din eksakte prosess være transformativt.

Integrasjonslim. Kanskje trenger du ikke et fullt CRM — du trenger et dashboard som henter fra tre eksisterende verktøy og viser en samlet visning. En lettvekts skreddersydd app som kobler til Notion, Google Sheets og e-post via APIer kan være mer nyttig enn noe hyllevare-CRM.

Opinionert enkelhet. De store CRM-ene er oppblåste fordi de betjener alle. Hvis du vet nøyaktig hva du trenger — og ingenting mer — kan du bygge noe raskere og mer behagelig å bruke enn noe på markedet. Attio og Folk startet som akkurat den innsikten.

Kostnadene du glemmer å inkludere

Sammenlign det med HubSpots gratisversjon eller Attio til 290 kroner per bruker per måned, og avgjør om avveiningen gir mening. Kalkylen handler ikke om lisenskostnad. Den handler om alternativkostnad — og hva du velger å ikke gjøre i mellomtiden.

Det kommersielle vurderingen

Spørsmålet om å bygge eller kjøpe er egentlig et spørsmål om hva virksomheten din er til for. Er dere et teknologiselskap som leverer programvare, eller et kommersielt selskap som bruker teknologi? Svaret på det spørsmålet bør styre langt mer enn CRM-beslutningen.

Det beste egenbygde CRM-et er det du faktisk bruker. Men det beste kommersielle systemet er det som frigjør flest mulig timer til det du egentlig er satt til: å skape lønnsom vekst.