Det börjar nästan alltid likadant.
En VD eller en produktansvarig har suttit en kväll med Lovable och på ett par timmar fått upp något som faktiskt ser ut som en riktig app. Det finns ett gränssnitt. Det finns en databas. Man kan klicka runt. Det funkar.
Känslan är euforisk, och det förstår vi. Att gå från en idé i huvudet till något klickbart på några timmar är en bedrift som hade tagit månader för tio år sedan.
Sen kommer måndagsmötet. Någon frågar: "Kan vi koppla det här mot Fortnox?" En annan undrar hur det ska fungera när 500 användare loggar in samtidigt. En tredje vill veta om säljteamet kan exportera rapporterna direkt till Power BI.
Och där börjar en annan sorts resa.
Varför Lovable är perfekt för prototyper men inte för produktion
Låt oss vara tydliga: Lovable är ett imponerande verktyg. Det är inte ett dåligt verktyg. Det är ett verktyg som är exceptionellt bra på exakt det det är byggt för, att snabbt generera en interaktiv prototyp som ser ut och känns som en riktig applikation.
Det är precis därför det är så värdefullt i tidiga skeden. Istället för att lägga tre månader på att skriva en kravspecifikation som ingen förstår, kan du på en dag bygga något konkret att visa styrelsen, testa med användare, eller använda som underlag i en upphandling. En Lovable-app är i praktiken den bästa interaktiva kravspecifikationen du kan ha.
Men en prototyp är en prototyp.
Skillnaden mellan en prototyp och ett produktionssystem är inte bara teknisk det är arkitektonisk. Ett produktionssystem måste hantera saker som:
- Skalbarhet: Vad händer när 50 användare blir 500? Eller 5 000?
- Felhantering: Vad sker när ett externt system inte svarar? Hamnar data i limbo, eller finns det en logik som hanterar det?
- Revisionshistorik och compliance: Vem ändrade vad, och när? Kan ni visa det för en revisor?
- Behörigheter på granulär nivå: Kan ni styra exakt vad varje användarroll får se och göra, ner på fältnivå?
Lovable kan generera kod som löser enkla varianter av dessa problem. Men ett system som ska leva i ett riktigt bolag, med riktiga processer och riktiga krav, behöver beslut som fattas av en människa med ansvar, inte genereras av en AI som gör sitt bästa.
Integrationer och databashantering: Där Lovable slår i taket
Den vanligaste frågan vi får från kunder som byggt en Lovable-app är varianter på samma tema: "Kan ni integrera det här med Fortnox? Kan vi skicka data från XY appen?"
Det korta svaret är ja. Men inte mot Lovable-appen.
En integration mot Fortnox, eller vilket affärssystem som helst, är inte en teknisk trivialitet. Det handlar om att förstå hur Fortnox datamodell ser ut, vad som händer när en faktura ändrar status, hur ni hanterar dubbelposter om synkroniseringen går fel mitt i natten, och vem som äger sanningen när systemen säger olika saker.
Det kräver en arkitektur som är designad för det från grunden. Det kräver att någon har tänkt igenom felscenarierna. Det kräver att det finns loggar, larm och en strategi för vad som händer när något går snett.
En AI-byggare som Lovable genererar kod baserat på din prompt. Den kan skapa en koppling som fungerar i ett demo. Men den har inte tänkt igenom vad som händer vid ett nätverksavbrott, en API ändring från Fortnox sida, eller när en användare råkar trigga en process i fel ordning.
Samma sak gäller Power BI-integrationer. Att exponera data till ett BI-verktyg låter enkelt, men det förutsätter att databasen är strukturerad på ett sätt som gör det möjligt att ställa meningsfulla frågor mot den. Det förutsätter att datamodellen är genomtänk, inte genererad.
Breaking changes och risken med AI-genererad kod
Det här är den del som håller IT-chefer vakna om natten, och med rätta.
När ni börjar bygga vidare på en Lovable-app och systemet växer i komplexitet, uppstår förr eller senare ett behov av en strukturell förändring i databasen. Kanske ska en tabell delas upp i två. Kanske ska en relation mellan entiteter ändras. Det är normalt i all systemutveckling, det kallas en "breaking change" eller en databasmigration.
I ett välbyggt system hanteras detta med versionshantering, migrationsskript och tester som körs innan något driftsätts. Det finns en process. Det finns en människa som förstår konsekvenserna av varje förändring.
I en AI-genererad kodbas är bilden mer oklar. Vem äger förståelsen för systemet? Kan ni med säkerhet säga att en AI-driven omstrukturering inte rör vid data den inte borde röra? Har ni en backup-strategi som ni faktiskt testat?
Vi pratar inte om hypotetiska skräckscenarier. Vi pratar om reella risker för bolag som har kunddata, orderhistorik eller finansiell information i sin applikation. En droppat tabell är inte ett programmeringsmisstag - det är en affärskris.
Det handlar inte om att AI är dåligt. Det handlar om att AI saknar ansvar. Det finns ingen som kan ställas till svars när ett genererat system fattar ett felaktigt beslut om er data. Det är skillnaden mellan ett verktyg och ett system.
Från PoC till skräddarsytt system: Så gör vi det på Burdy
Det är här Lovable-resan faktiskt kan bli en tillgång snarare än ett problem.
När ett bolag kommer till oss med en Lovable-app har de redan gjort en stor del av det tyngsta arbetet. De har validerat att idén är värd att bygga. De har konkretiserat vad systemet ska göra. De har i många fall redan fått feedback från framtida användare. Det är ovärderligt.
Vi behandlar Lovable-appen som vad den är: en avancerad kravspecifikation med ett gränssnitt. Sedan bygger vi det riktiga systemet.
Det innebär att vi fattar arkitektoniska beslut som en AI inte kan fatta. Vi väljer databasstruktur baserat på hur ni faktiskt arbetar, inte baserat på hur en prompt tolkades. Vi designar integrationer mot Fortnox, mot era affärssystem, mot Power BI, med felhantering och logik som speglar era processer. Vi sätter upp behörighetsstrukturer som matchar er organisation. Vi bygger med versionshantering, dokumentation och en kodbas som kan underhållas och vidareutvecklas utan att ni är beroende av oss för alltid.
Och vi gör det snabbare än vad det skulle ha tagit för fem år sedan, inte för att vi använder AI som ersättning för kompetens, utan för att vi använder AI som ett kvalitetsverktyg i händerna på utvecklare som förstår vad de bygger.
Skillnaden är enkel: i en AI-byggare styr AI:n. I ett system byggt av Burdy styr era processer.
Ett konkret exempel: Vi fick nyligen in ett bolag som hade byggt ett internt orderhanteringssystem i Lovable. Systemet fungerade utmärkt som demo. Men de ville integrera det mot Fortnox för fakturahantering och mot sitt lager-system för realtidsuppdateringar av lagersaldo. De hade också ett krav på att systemet skulle kunna hantera 200 parallella användare under deras säsongstoppar.
Vi tog deras Lovable-app som utgångspunkt, förstod vad de faktiskt behövde, och byggde systemet från grunden med rätt arkitektur. Integrationen mot Fortnox hanterar nu synkroniseringsfel automatiskt och loggar varje transaktion. Lagersaldot uppdateras i realtid med en kö-baserad lösning som inte tappar data vid belastningstoppar. Och behörighetsstrukturen är uppbyggd efter deras faktiska roller - inte en generisk admin/user-uppdelning.
Det är vad "produktionsskarp" faktiskt betyder.
Sammanfattning: Rätt verktyg för rätt fas
Lovable är inte fel. Det är rätt verktyg för fel fas om du försöker använda det hela vägen till produktion.
Bygg din prototyp i Lovable. Validera idén. Visa den för styrelsen. Samla feedback. Det är precis vad verktyget är gjort för, och det gör det bättre än något annat på marknaden just nu.
Men när du vet att idén håller, när du ska bygga något som ska hantera riktig kunddata, integreras med era affärssystem och skalas till hundratals användare - då behöver du ett system som är byggt med ansvar. Där era processer styr systemet, inte tvärtom.
Det är där vi kommer in. Vi har redan exporterat ut flertalet Lovable appar från Lovable och byggt vidare på dom till mer hållbara appar.
Vill du veta hur det här hade sett ut för ert bolag?