Har du funderat på att bygga ett CRM-system i Lovable? Det kan dra ner dyra kostnader, och som du troligen vet är fakturorna som dyker upp i inboxen från stora CRM-program som Salesforce och HubSpot inte så roliga att öppna. Dock kommer det med lite komplikationer, tro mig, jag har gjort det några gånger. Denna artikel går igenom vad du ska tänka på och hur du ska göra för att bygga ditt eget skräddarsydda CRM-system, utifrån erfarenheter jag har fått med mig som utvecklare, entreprenör och CRM-byggare i Lovable.

Sätt upp databasen och backenden

Backenden och databasen är något som du bör fundera på innan du sätter igång. Många går direkt till Lovables inbyggda backend, Cloud. Cloud är egentligen en förenklad version av Supabase som bor inne i Lovable. Det går fantastiskt bra att använda om du bara bygger prototyper, men om du är seriös med att bygga ditt CRM skulle jag starkt avråda från detta, på grund av bristande kontroll och säkerhetsluckor.

Så hur ska man kunna koppla ett externt backend-program? Detta görs smidigast genom att du kopplar ditt projekt till GitHub, sparar ned koden lokalt på din dator och gör kopplingen till backenden genom att skriva kod. Dock är detta såklart svårt om du inte har någon teknisk bakgrund. Så om du har absolut noll erfarenhet av kodning är detta ett bra tillfälle att ta in en extern konsult.

Backend-program jag rekommenderar: för mindre projekt rekommenderar jag Supabase, med inbyggd PostgreSQL-databas. Gratisversionen är väldigt generös, du får plats med upp till 50 000 aktiva användare per månad och 500 MB databaslagring innan du behöver betala något alls, vilket räcker gott och väl för de flesta småföretag i uppstartsfasen. Däremot, om du behöver större säkerhet, fler funktioner eller växer förbi den nivån, rekommenderar jag större verktyg som exempelvis AWS RDS eller Google Cloud SQL, men då pratar vi en helt annan nivå av komplexitet och du bör absolut ha en utvecklare med dig på den resan.

Vibe-coda ditt CRM, så gör du det säkert

Det här är sökordet alla pratar om just nu, och jag förstår varför. Fler och fler grundare sätter sig ner en kväll, öppnar Lovable och bygger ett CRM på några timmar som hade kostat hundratusentals kronor att beställa av en byrå för några år sen. Men det är just här som problemen börjar, för att bygga snabbt och att bygga säkert är sällan samma sak, och det är den biten som glöms bort när man är inne i flowet.

Så innan du går vidare, låt mig visa hur de tre delarna faktiskt hänger ihop, för det är lättare att förstå säkerheten när man ser helheten:

Frontend är det besökaren ser och klickar på, backend bearbetar allt som händer i bakgrunden, och databasen lagrar informationen. Det är i kommunikationen mellan dessa tre delarna som säkerhetsluckorna oftast dyker upp, inte i själva delarna för sig.

Skydda ditt CRM på rätt nivå

Här är det viktigt att skilja på vad som faktiskt skyddar vad, för det här är stället där jag ser flest missförstånd. Ditt Lovable-byggda CRM pratar med databasen via Supabases API, inte via en direkt databasanslutning. Det betyder att den absolut viktigaste skyddsnivån är Row Level Security, RLS, alltså policys som styr exakt vilka rader i databasen en inloggad användare får läsa eller ändra. Utan korrekt inställda RLS-policys spelar det ingen roll vad du låser ner på annat håll, för det är fortfarande det här API:et din app faktiskt använder, och det är öppet så fort någon har rätt (offentliga) nyckel. Det här är en av de vanligaste sårbarheterna jag hittar när jag granskar Lovable-byggda system, så be din utvecklare gå igenom att RLS är korrekt aktiverat på varje tabell innan du går live.

Sen finns det ett extra lager du kan lägga på: IP-whitelisting, som Supabase kallar Network Restrictions. Det är en riktig funktion och den tar bara några minuter att sätta upp under databasinställningarna. Men var medveten om vad den faktiskt gör: den skyddar bara den direkta databasanslutningen, inte API:et, inloggningen eller filhanteringen som din app använder i vardagen. Den är alltså mest värdefull om du eller ditt team någon gång kopplar upp er direkt mot databasen, till exempel via ett analysverktyg. Den ersätter aldrig RLS, den kompletterar den.

Har du ingen utvecklare själv? Då behöver du inte förstå tekniken bakom för att komma igång, du behöver bara ställa rätt krav. Skicka detta till den Lovable-konsult eller frilansare du anlitar: "Kan du bekräfta att RLS är aktiverat och korrekt konfigurerat på samtliga tabeller, och sätta upp Network Restrictions på databasen?" Två meningar, och du har täckt de två viktigaste skyddslagren innan systemet går live.

Var ska du hosta det?

Här skiljer sig meningarna åt. Om du vill gå ännu ett steg längre i säkerhet finns Supabases egen PrivateLink-lösning, som kopplar din databas privat mot AWS utan att trafiken går via den öppna webben. Det är dock ett steg för när du vuxit ur grundskyddet, RLS plus eventuell IP-whitelisting, snarare än något du behöver börja med.

Glöm inte användarvänligheten

Något jag ser gång på gång är att grundare blir så fokuserade på funktioner och säkerhet att de glömmer bort vem som faktiskt ska sitta och använda systemet varje dag. Ett CRM som är tekniskt perfekt men jobbigt att navigera i kommer aldrig bli använt på riktigt, hur mycket pengar du än sparade på att bygga det själv.

Fråga dig själv vilka som ska klicka runt i det här. Är det ett ungt säljteam som är vant vid appar och gränssnitt, eller är det seniora medarbetare som kanske inte är lika digitala? Det förändrar hur du bör designa det. Större knappar, tydligare kontraster och färre klick för att komma till det viktiga är exempel på saker som gör enorm skillnad för den senare gruppen, men som ofta prioriteras bort helt i vibe-codingens tempo.

Ett bra tips är att sätta dig ner med den eller de som ska använda systemet innan du börjar bygga UI:t, och faktiskt fråga hur de vill klicka sig fram. Det tar tio minuter och sparar dig många omarbetningar längre fram.