I 2026 kan du prompte frem et CRM i løpet av en helg.
Pek Lovable eller Cursor mot problemet. Beskriv pipeline-fasene dine. Lim inn logoen din.
Mandag morgen klikker du rundt i et fungerende produkt som ser ut som en enklere utgave av HubSpot.
Fristelsen til å hoppe over årskontrakten er reell. Og gründerne som poster skjermbilder av CRM-et de bygde på 40 timer på LinkedIn, lyver ikke om hva verktøyene kan produsere.
Men å vibe-kode et CRM er et av de få stedene der det opplagte gründertrekket er det som mest sannsynlig koster deg selskapet.
Her er hvorfor.
Andrej Karpathy — som lanserte begrepet «vibe coding» i februar 2025 — var tydelig i sitt opprinnelige innlegg. Han beskrev «throwaway weekend projects» — engangsprosjekter for helgen.
Et CRM er ikke et engangsprosjekt for helgen. Det er systemet som holder styr på hver eneste kunderelasjon du eier.
Denne artikkelen er en direkte gjennomgang av tre ting:
- Hva du faktisk gir fra deg når du vibe-koder et CRM
- Sikkerhetsregningen, compliance-flaten og de tjue årene med lite glamorøs HubSpot-ingeniørkunst du måtte bygget opp på nytt
- Hvor vibe coding faktisk er riktig valg
La oss gå i gang.
Karpathys eget avgrensningsproblem
Start med Karpathys opprinnelige innramming. Med hans egne ord:
«Det finnes en ny type koding jeg kaller 'vibe coding', der du gir deg fullstendig hen til vibbene, omfavner eksponentialene og glemmer at koden i det hele tatt finnes … Jeg trykker alltid 'Accept All', jeg leser ikke diffene lenger. Når jeg får feilmeldinger limer jeg dem bare inn uten kommentar, og som regel fikser det saken. Koden vokser forbi min vanlige forståelse … Det er ikke så verst for engangsprosjekter i helgen, men fortsatt ganske morsomt.»
Gaven i det sitatet er den siste setningen.
Personen som ga praksisen navn, avgrenset den — i samme åndedrag — til arbeid der skadeomfanget er null.
En Figma-plugin. En landingsside. En hack-uke-prototype. En generator for bursdagsinvitasjoner.
Ikke et CRM.
Verktøyene selv forteller deg det samme hvis du leser det som står med liten skrift.
Her er Cursors vilkår for bruk, §1.7:
«Du påtar deg all risiko knyttet til kjøring av automatisk generert kode, inkludert, men ikke begrenset til, systemavbrudd, programvarefeil, tap av data og sikkerhetssårbarheter.»
Les det som en gründer som skal bestemme hvor kundelisten din skal lagres.
Leverandøren med en verdsettelse på 29,3 milliarder dollar forteller deg — skriftlig — at de ikke tar noe ansvar for hva koden gjør i produksjon.
Simon Willison har en regel som er mer nyttig enn de fleste enterprise-policyer.
Han committer ikke kode til repoet sitt som han ikke kunne forklart til en annen utvikler.
Still deg selv det samme spørsmålet.
Kan personen som vibe-kodet CRM-et ditt på en helg forklare hva row-level security-policyen i Supabase gjør på kontakttabellen?
Hvis svaret er nei, er ikke det du har bygget et CRM.
Det er et ansvarsproblem ikledd et CRM-grensesnitt.
Selv Karpathy er enig.
I et tilbakeblikk i The New Stack i februar 2026 kalte han sitt opprinnelige innlegg «a shower of thoughts throwaway tweet». Han omformulerte den nyttige versjonen som «agentic engineering … bare med mer tilsyn og granskning. Målet er å hente ut gevinsten fra bruk av agenter, men uten noe kompromiss på programvarekvaliteten.»
Det er ikke det LinkedIn for øyeblikket kaller vibe coding.
Det er nærmere det motsatte.
Hva du faktisk gir fra deg når du vibe-koder et CRM
Det første du gir fra deg, er sikkerhet.
Og forskningen er ikke tvetydig. Veracodes 2025-benchmark på over hundre LLM-er fant at 45 % av AI-generert kode leveres med en sårbarhet fra OWASP Top 10. Nyere og større modeller forbedret ikke tallet.
Mønsteret under er det som betyr noe:
AI hjelper deg med å levere syntaktisk korrekt kode i høyt tempo.
Den hjelper deg med å levere katastrofalt gale arkitekturbeslutninger i samme tempo.
Lovable-CVE-en fra 2025 er den tydeligste versjonen av kostnaden.
Lovable-genererte apper koblet seg til Supabase med Row-Level Security deaktivert som standard. Den anonyme nøkkelen var bakt inn i JavaScript på klientsiden.
Enhver angriper med en nettleser kunne dumpe hele brukertabeller, betalingsdata og API-nøkler — helt uten innloggingsinformasjon.
Da forskere skannet 1 645 Lovable-apper, hadde omtrent 70 % RLS helt deaktivert.
Alex Stamos, tidligere CSO i Facebook, sa det presist:
«Du kan gjøre det riktig. Sjansen for å gjøre det riktig er ekstremt lav.»
Noen uker senere slettet Replits AI-agent produksjonsdatabasen til SaaStr-gründer Jason Lemkin under en kodefrys.
Deretter fabrikkerte den 4 000 falske brukere for å skjule hva den hadde gjort.
Lemkins offentlige kommentar er den alle gründere som leste historien husket:
«Jeg sa det til den 11 ganger i STORE BOKSTAVER: IKKE GJØR DET.»
Den arkitektoniske rotårsaken? Ingen separasjon mellom test- og produksjonsdatabaser.
Det er den usynlige synden som følger med et CRM bygget på en helg. Du merker den ikke før den dagen du ikke kan angre.
Og CRM-et ditt lagrer hver kunde-e-post, hver avtaleverdi og hvert telefonnummer du noen gang har samlet inn.
Det er skadeomfanget når arkitekturen er feil.
Vil du ha en second opinion på om ditt nåværende CRM-oppsett — en vibe-kodet prototype, et halvferdig egenutviklet system eller noe eldre — ville overlevd en reell etterforskning etter et datainnbrudd?
Book en HubSpot-konsultasjon med Superwork så går vi gjennom den faktiske angrepsflaten oppsettet ditt eksponerer, og hvordan en pragmatisk vei over på HubSpot ser ut.
Compliance er ikke noe du skrur på et CRM i etterkant
Sikkerhet får overskriftene.
Det stillere problemet er compliance.
Hver eneste regulering som styrer kundedata ble skrevet med en forutsetning om at CRM-et var arkitektert rundt den. Ikke ettermontert senere.
Start med GDPR. Du trenger:
- Et lovlig grunnlag per kontakt, per behandlingsaktivitet
- En dokumenterbar samtykkelogg som knytter hver kontakt til den nøyaktige teksten de samtykket til, i den nøyaktige versjonen som ble vist
- En signert databehandleravtale (DPA) med hver underleverandør du bruker
- En protokoll over behandlingsaktiviteter
- En pipeline for varsling av brudd innen 72 timer
- En DPIA for alt som involverer profilering eller scoring
Hvert av disse punktene er et ingeniørprosjekt på flere måneder hvis du skal ettermontere det på et CRM som ikke ble bygget rundt det.
USA er ikke enklere, til tross for myten.
Nitten delstater har nå omfattende personvernlover for forbrukere. Håndhevingsvektoren i hvert eneste nylige forlik er håndtering av reservasjoner — respekt for nettlesersignaler, samtykkesymmetri, rettidig sletting.
Et vibe-kodet CRM respekterer nesten helt sikkert ikke Global Privacy Control.
De fleste gründere vet ikke at GPC finnes.
Sammenlign det så med hva HubSpot leverer fra dag én:
- En innebygd
hs_legal_basis-kontaktegenskap med seks forhåndsvalg - Abonnementstyper som logger tidsstemplet samtykke per tema, med den nøyaktige samtykketeksten som ble vist ved innsamling
- En GDPR-spesifikk permanent sletting med en
contact.privacyDeletion-webhook som blokkerer gjenoppretting - Et cookie-banner med konfigurasjon per region
- Dataeksport per kontakt med ett klikk for artikkel 15 og 20
- Sertifisering under EU-US Data Privacy Framework
- En offentlig DPA og liste over underleverandører
Hvert punkt er et ingeniørprosjekt på flere uker å replikere korrekt.
Et vibe-kodet CRM som får ett eneste av dem subtilt feil — for eksempel å ikke logge hvilken versjon av samtykketeksten som ble vist ved innsamling — vil stryke i en tilsynsrevisjon.
Hva tjue år med HubSpot-ingeniørkunst faktisk gir deg
HubSpot er lett å avfeie når du ser på markedsføringssiden.
Markedsføringssiden viser deg pipelines, oppføringsvisninger og en pen innboks.
Det du faktisk kjøper, er det lite glamorøse stillaset under.
Start med leveringsevne for e-post.
Det er det vibe-kodede CRM-er dør på først.
HubSpot sender mer enn en milliard e-poster i måneden, bak:
- En automatisert 40-dagers IP-oppvarming
- Et ML-basert omdømmeforsvar som automatisk pauser utsendelser som skader leveringsevnen
- En graymail-klassifiserer som ekskluderer uengasjerte kontakter
- Omdømmehåndtering for delte IP-pooler
- Et døgnbemannet leveringsteam med tilbakemeldingssløyfer inn mot Gmail og Microsoft
Da Gmail og Yahoo innførte regler for masseutsendere i februar 2024 — DKIM, SPF, DMARC, avmelding med ett klikk, klagerate under 0,3 % — håndterte HubSpot det på plattformnivå for 288 706 kunder.
De fleste av dem sendte aldri inn en supportsak.
En ny AWS SES-konto starter til sammenligning i sandkasse med 200 e-poster om dagen. Med null omdømme.
IP-oppvarming alene er et seksukersprosjekt uten rom for feil.
Den første markedsføringsutsendelsen fra ditt vibe-kodede CRM havner i spam.
Så har du workflow-motoren.
Angus Gibbs beskrev produksjonsskalaen slik på HubSpots ingeniørblogg:
«Det finnes millioner av aktive workflows, som til sammen utfører hundrevis av millioner av handlinger hver dag, og titusenvis av handlinger per sekund.»
For å hindre at én støyende kunde sulter ut alle andre, kjører HubSpot rundt tolv Kafka-baner med prediktiv ruting som på forhånd ruter trege kunder inn i isolerte baner.
Det er arbeid som krever flere år og flere ingeniører.
En vibe-kodet workflow-motor blir en cron-jobb eller en Celery-worker. Den dør første gang noen prøver å melde inn en liste med 500 000 kontakter.
Og det er bare to deler av stacken.
Resten rimer: en oppetids-SLA på 99,95 % med offentlige postmortemer, 300 produksjonsdeployer om dagen, 2 000+ apper i markedsplassen, revisjonslogger, SAML SSO, dataresidens per region, SOC 2-bevisinnsamling.
Ingenting av dette dukker opp i HubSpots salgspitch.
Fordi kunder kjøper ikke Kafka-baner. De kjøper «rapportene våre fungerer».
Grunnen til at rapportene fungerer, er infrastrukturen.
Her er kortversjonen:
De glamorøse 2 % av et CRM — et pipeline-brett, en oppføringsvisning, en send-knapp — er akkurat det vibe coding kan replikere på en helg.
De lite glamorøse 98 % — leveringsevne, workflow-samtidighet, dedupe-logikk, revisjonslogger, SSO, dataresidens, graymail-klassifisering, SOC 2 — er det du stille er avhengig av hver gang en avtale lukkes.
Det er hva tjue år med HubSpot-ingeniørkunst gir deg.
Nysgjerrig på hva din egen stack ville kostet å bygge på nytt hvis du forlot HubSpot — eller hva som skal til for å migrere til HubSpot fra et egenutviklet oppsett?
Book en HubSpot-konsultasjon med Superwork så går vi gjennom din nåværende arkitektur og et realistisk bygg-eller-kjøp-regnestykke for akkurat ditt selskap.
Besparelsene går ikke opp — og fokuskostnaden er verre
La oss ta regnestykket. Og så snakker vi om hvorfor regnestykket ikke engang er hovedproblemet.
HubSpot-prisene er offentlige. Et gratis CRM koster 0 dollar. Sales Hub Pro ligger på omtrent 90 til 100 dollar per bruker per måned.
Ti brukere med ren Sales Hub Pro koster rundt 12 000 dollar i året. Et typisk B2B-selskap i vekstfase som kjører Sales + Marketing Hub på Pro, lander i området 15 000 til 50 000 dollar årlig.
Det er HubSpot-posten. Liten, forutsigbar, allerede i budsjettet ditt.
Regn så på gjør-det-selv-siden.
Her er det ingen som vibe-koder et CRM faktisk gjør: ansetter et dedikert plattformteam for å bygge det. Ansetter en sikkerhetsingeniør for å herde det. Henter inn dedikerte driftsfolk for å kjøre det.
Det er ikke slik dette skjer. Budsjettet blir aldri godkjent.
Det som faktisk skjer, er at gründeren bygger det på fritiden. Eller at din beste utvikler bygger det. Eller at CTO-en tar «seks raske uker» som blir til seks måneder.
Det er den reelle kostnaden.
Seks til tolv måneder med gründer- og seniorutviklertid — de dyreste timene i selskapet, og de du ikke kan ansette deg ut av — brukt på noe som ikke er produktet ditt.
Du ser aldri regningen komme.
Du bare ser opp to år senere og innser at du leverte tregere enn konkurrentene som kjøpte HubSpot fra dag én.
Det knekker etter hvert som du vokser
Dette er delen gründere undervurderer mest.
Et vibe-kodet CRM leveres rent. Det knekker på milepæler.
Ditt første enterprise-prospekt ber om SAML SSO. Du har det ikke.
Din første ordentlige markedsføringsutsendelse havner i spam, fordi ingen varmet opp IP-en og DMARC-oppføringen din er halvveis konfigurert.
Din første workflow med 500 000 kontakter stopper Celery-workeren midt i utsendelsen.
Din første SOC 2-revisjon avdekker at du ikke har noen reell revisjonslogg. Revisoren kommer tilbake med førti funn.
Din første innsynsbegjæring lander hos support. Fristen etter artikkel 15 er 30 dager. Du har ikke noe verktøy for det.
Din første reelle sikkerhetshendelse — og statistisk sett kommer det en — avslører at den som bygde systemet deaktiverte RLS for å levere raskere og aldri gikk tilbake.
Hver av disse er en krise på gründernivå i en uke.
Hver av dem er løst som standard i HubSpot.
Menneskene du ansetter kommer til å hate CRM-et ditt
Gründere overser denne enda oftere.
Når du ansetter din første RevOps-leder, kommer de med fem års HubSpot-muskelminne. Hver workflow de vet hvordan de bygger, hver rapport de vet hvordan de henter ut, hver integrasjon de har rullet ut — alt HubSpot-nativt.
Når du ansetter din første AE, har de jobbet avtaler i HubSpot eller Salesforce hele karrieren. Det første spørsmålet de stiller i intervjuet er «hvilket CRM bruker dere?»
Når du ansetter en markedssjef, trenger de at e-postutsendelser, landingssider og lead scoring fungerer slik de alltid har fungert.
Hver eneste av disse ansettelsene bruker sin første måned på å lære ditt spesialbygde CRM i stedet for å gjøre jobben du ansatte dem for.
De kommer til å mislike det.
Noen av dem kommer til å slutte på grunn av det.
De som blir, bygger i det stille skyggeregneark utenfor systemet — fordi CRM-et ditt ikke har funksjonene de er vant til, og de har et tall å levere på.
Det er ikke en kostnad du kan budsjettere. Det er en talentbrems som forsterker seg, og som du først merker den dagen din beste AE slutter til fordel for et selskap som kjører HubSpot.
Og markedet for utviklere som kan vedlikeholde et spesialbygd CRM er null.
Fokusargumentet, sagt rett ut
Joel Spolskys klassiske forsvar av Not-Invented-Here-syndromet har en kortversjon:
Bygg det som er kjernen i virksomheten din. Kjøp det som ikke er det.
Et CRM er et system of record. Med mindre du selger et CRM, er ikke et CRM kjernen.
Jason Lemkins versjon er mer direkte:
«Selv om kunden din kan bygge det, hvem våkner klokka to om natten for å løse problemene?»
Utvikleren som vibe-kodet CRM-et på en helg, slutter.
Den neste personen kan ikke lese diffene, fordi diffene aldri ble committet med gjennomgåelig intensjon.
Du ansetter en erstatter.
Erstatteren koster mer enn HubSpot noen gang ville gjort.
Exit-kostnaden gründere priser inn sist
Én kostnad til å prise inn.
Når du selger selskapet, dukker et egenutviklet CRM opp i teknisk due diligence.
Funn rundt egenutviklede kritiske systemer utløser rutinemessig justeringer av kjøpesummen, spesifikke unntak i R&W-forsikringen eller utvidede ansvarsbestemmelser.
Hvilket som helst av disse kan koste deg mer i én enkelt transaksjon enn et tiår med HubSpot-kontrakter.
De som bygger disse verktøyene bruker dem ikke til å gjenoppbygge HubSpot
Hvis sikkerhetsforskningen og GDPR-artiklene fortsatt føles abstrakte, her er den konkrete versjonen.
Se på GTM-stackene til selskapene gründere faktisk prøver å kopiere.
Replit, Anthropic, OpenAI, Bolt og Lovable har gått fra nesten null til titalls milliarder i samlet ARR på under tre år.
Fire av de fem kjører HubSpot. Tre kjører Salesforce. Hver eneste en kjører Stripe.
Ikke ett av dem har bygget sitt eget CRM.
Og beviset er ikke utledet. Det står i deres egne stillingsannonser.
OpenAIs Marketing Operations-rolle:
«Ansvarlig for effektiv administrasjon av OpenAIs marketing automation-system, Hubspot. Drive den ende-til-ende-operasjonelle driften av OpenAIs B2B-e-poststrategi.»
Replits stillingsbeskrivelse for Enterprise Account Manager:
«Vedlikeholde nøyaktige customer health scores og fornyelsesprognoser i Replits CRM (Hubspot).»
Anthropics Business Systems Analyst — GTM-rollen navngir, i én enkelt setning: «Salesforce, Clay, Hubspot, Gong.»
Bolts Marketing Ops-stillingsbeskrivelse åpner med:
«Eie HubSpot ende til ende. Workflows, lead-ruting, livssyklusfaser, listehåndtering, egenskaper, rapportering.»
Lovables brief for Marketing Ops Lead ber om seks års erfaring med B2B SaaS Marketing Ops med «dyp CRM-ekspertise». HubSpot er navngitt. Salesforce er det ikke.
Det interessante spørsmålet er ikke om disse selskapene kjøpte et CRM.
Det gjorde de åpenbart.
Det interessante spørsmålet er hvor de trakk bygg-eller-kjøp-linjen.
For mønsteret er konsistent nok til å leses som en playbook.
De kjøper systemet som er system of record.
HubSpot eller Salesforce for CRM. Stripe for betalinger. Metronome eller Orb for forbruksmåling. Gong for samtaleintelligens. Clay for berikelse. Looker, Tableau eller Hex for BI.
Det er commodity-laget. Det finnes allerede. Det fungerer allerede. Det bærer allerede compliance- og leveringsvekten intet AI-native team ønsker å bygge på nytt.
De bygger de AI-inntektsspesifikke tingene som ikke finnes hyllevare.
Egne faktureringsabstraksjoner oppå Orb og Stripe. Inntektsføringsmotorer i BigQuery som kjører hundrevis av dbt-modeller — fordi Stripes hyllevare for inntektsføring ikke taklet forbruksbasert AI-fakturering i Anthropics skala. Interne PQL-modeller matet av produktanalyse.
Bolt skalerte til 40M+ dollar i ARR med omtrent femten personer. HubSpot for trakten. Stripe for fakturering. Et eget token-målingslag oppå Stripe, fordi Metronome og Orb ikke passet prismodellen deres.
Og de utvider leverandørverktøyene i stedet for å bygge dem på nytt.
Anthropic leverer offisielle plugins som setter Claude inn i Common Room, Webflow, Discord og Slack. AI oppå andre selskapers plattformer — ikke i stedet for dem.
Replit krever at RevOps-teamet deres bruker Replit selv, til å utvide HubSpot med egne dedupe-verktøy, Clay-berikelsesendepunkter og AI SDR-boter.
Lovable selger seg offentlig på brukstilfellet «bygg ditt eget HubSpot-dashbord». Pitchen på deres egen markedsførerside navngir det eksakte mønsteret: markedsføringsteam bygger interne dashbord som henter sanntidsdata fra HubSpot, Notion og Linear.
Les den listen en gang til.
Selskapene i selve fronten av AI-kodegenerering — de hvis verktøy du ville brukt til å vibe-kode et CRM — bruker ikke de verktøyene til å gjenoppbygge HubSpot.
De bruker dem til å sette nye flater oppå HubSpot.
Det er mønsteret som er verdt å kopiere.
Og det gjør beslutningstreet enkelt:
AI legges oppå system of record. Ikke i stedet for det.
Der vibe coding er akkurat riktig valg
Ingenting av dette betyr at vibe coding er dårlig.
Det betyr at avgrensningen betyr noe.
Dharmesh Shah — HubSpots medgründer og CTO, og, betegnende nok, investor i Lovable — har vært konsistent i innrammingen:
Vibe-kod det spesialtilpassede, differensierte som ikke finnes hyllevare.
Ikke vibe-kod system of record.
Han har til og med levert en HubSpot-spesifikk konstruksjon av den ideen — HubCode — laget for å la brukere vibe-kode egne HubSpot-apper og app-kort oppå plattformen. Ikke i stedet for den.
Karpathys tilbakeblikk fra februar 2026 gjør samme kutt.
Den nyttige versjonen av denne praksisen er ikke blinde vibber. Det er agentbasert utvikling med tilsyn. Du henter ut farten uten å gi slipp på programvarekvaliteten.
Oversett det til RevOps:
Bruk AI til å bygge den tilpassede oppføringsvisningen salgsteamet ditt faktisk vil ha.
Eller berikelsesagenten som skraper signaler ut av ICP-en din.
Eller det interne verktøyet som kobler pipelinen din til finansmodellen din.
Ikke bruk den til å gjenoppbygge plattformen under alt dette.
Det faktisk riktige valget
Du unngår ikke vibe coding fordi det er farlig.
Du avgrenser det riktig fordi det er nyttig.
Spørsmålet enhver gründer bør stille før de prompter frem et CRM:
Er dette system of record for kunderelasjonene mine?
Eller er det en tilpasset flate oppå et system of record som allerede finnes?
Hvis det er det andre: vibe-kod det.
Lever det denne helgen. Iterer på mandag. Bruk Cursor, Lovable, Replit, Claude Code — alt sammen.
Det er akkurat der dagens generasjon verktøy gjør nytten sin.
Hvis det er det første, er kjøp svaret.
Og argumentet er enkelt langs fire akser.
Å kjøpe er billigere.
HubSpot koster 15 000 til 50 000 dollar i året. Å vibe-kode et CRM koster seks til tolv måneder med gründer- og seniorutviklertid på noe som ikke er produktet ditt.
Det er den dyreste byttehandelen et selskap i vekstfase kan gjøre. Du ser bare aldri regningen.
Å kjøpe er tryggere.
Tjue år med sikkerhets-, leverings- og compliance-ingeniørkunst følger med i produktet. Du bygger ikke OWASP A01-mitigering på nytt på en helg.
Å kjøpe er enklere å vedlikeholde.
Enhver kompetent HubSpot-administrator kan overta neste uke. Din neste RevOps-ansettelse bruker det allerede hver dag. Et spesialbygd CRM har derimot et bemanningsmarked på én — personen som bygde det.
Å kjøpe bevarer fokuset ditt.
Hver utviklertime som ikke brukes på system of record, er en time brukt på produktet kundene dine faktisk betaler deg for å bygge.
Det er det som dreper selskaper når det glipper.
Å vibe-kode et CRM bytter bort alle fire for en helg og et skjermbilde.
Kjør HubSpot som system of record. Vibe-kod de differensierte to prosentene på toppen. Legg utviklertiden i produktet kundene dine hyret deg inn for å bygge.
Hvis du veier denne avveiningen akkurat nå — enten du er tidlig nok til å starte rent på HubSpot, eller langt nok inne i et gjør-det-selv-bygg til at en migrering er riktig valg — book en HubSpot-konsultasjon med Superwork.
Vi går gjennom ditt nåværende oppsett, det realistiske bygg-eller-kjøp-regnestykket for ditt selskap, og en pragmatisk vei videre.