Det korta svaret: ja, det går att bygga en app utan att kunna koda, och det tar en kväll att komma till något som fungerar. Det långa svaret är att "utan kod" inte betyder utan arbete. Du slipper syntaxen. Du slipper inte tänka.
Den här guiden går igenom hur du gör i praktiken, vilka verktyg som duger till vad, och var folk brukar fastna. Den är skriven för dig som driver något litet och har en idé du vill testa, inte för dig som vill bli utvecklare.
Vad "utan kod" faktiskt betyder
Det finns två familjer av verktyg och de blandas ihop hela tiden.
Den första är byggklossverktygen. Du drar block på en yta och kopplar ihop dem. Inget du gör kan gå sönder på ett sätt du inte förstår, men du kan heller aldrig gå utanför det verktyget tänkt ut åt dig.
Den andra är AI-byggarna. Du beskriver vad du vill ha på vanlig svenska, och AI:n skriver koden åt dig. Du ser koden om du vill, men du behöver inte röra den. Skillnaden mot byggklossarna är att taket är mycket högre, och att du äger resultatet.
För en app som ska göra något eget är det den andra familjen som gäller. Det är också där de senaste två åren har hänt allt.
Börja med vad appen ska göra, inte med verktyget
Det vanligaste misstaget är att öppna ett verktyg och börja klicka. Du får något snyggt på tjugo minuter och sedan står du stilla i tre veckor.
Skriv i stället ner tre saker innan du öppnar något:
Vem använder appen, och gör hen det på mobilen eller vid en dator? En app som ska användas stående i en skåpbil ser inte ut som en app som ska användas vid ett skrivbord.
Vad är det enda som måste fungera för att appen ska vara värd något? Inte allt du kan tänka dig — det enda. En tidrapporteringsapp måste kunna spara en timme på ett projekt. Allt annat är utsmyckning.
Vad händer med informationen sedan? Ska den läsas av dig, mejlas någonstans, hamna i bokföringen? Svaret avgör hur mycket maskineri du behöver bakom.
De tre svaren är hela din kravspecifikation. De ryms på en post-it och de sparar dig veckor.
Tre sorters appar, och vad de kräver
Appen som bara visar något. En prislista, en kalkylator, ett formulär som mejlar dig svaret. Det här är enklast och du kan vara klar samma kväll. Ingen databas behövs, ingen inloggning.
Appen som sparar något. Kunder, bokningar, timmar, protokoll. Nu behöver du en databas och en inloggning, för informationen ska ligga kvar och inte vara synlig för vem som helst. Det är ett steg upp i svårighet, men det är fortfarande en kväll eller två.
Appen som gör något åt någon annan. Skickar fakturor, påminner kunder, hämtar data från ett annat system. Här kommer automationsverktyg och kopplingar in, och det är först här det börjar bli riktigt jobbigt om du inte har hjälp.
Var ärlig med vilken sort du bygger. Nästan alla tror att de bygger den tredje och behöver egentligen den andra.
Så bygger du första versionen
Jag använder Lovable(annonslänk) till det här, för det är byggt för precis den här arbetsgången och det är på svenska hela vägen om du skriver på svenska. Det finns andra som gör ungefär samma sak, och de ligger samlade på verktygssidan.
Arbetsgången är densamma oavsett verktyg.
Skriv en första prompt som beskriver helheten. Inte "bygg en app åt mig" utan tre stycken: vad appen gör, vem som använder den, och hur det ska kännas. Nämn att den ska fungera på mobilen. Nämn på svenska att texterna ska vara på svenska, annars blir de på engelska.
Titta på vad du får och ändra en sak i taget. Frestelsen är att skriva en lång lista med tolv ändringar. Gör inte det. Ett önskemål per gång, titta på resultatet, gå vidare. Det går fortare i praktiken även om det känns långsammare.
Beskriv problemet, inte lösningen. "Knappen syns inte på mobilen" ger ett bättre resultat än "gör knappen bredare och flytta upp den". AI:n vet mer om layout än du gör. Den vet ingenting om vad som ser fel ut hos dig.
Spara en version när något fungerar. Alla de här verktygen har historik. Använd den. Det är skillnaden mellan en dålig kväll och en förlorad vecka.
Databasen är där de flesta fastnar
När appen ska spara något behöver du en databas, och det låter värre än det är. En databas är listor med rader och kolumner. Kunder är en lista. Bokningar är en lista. Varje bokning pekar på en kund.
Det du ska tänka på, och det som AI:n inte gissar rätt åt dig, är vem som får läsa vad. Om appen har inloggning ska varje användare se sina egna rader och ingen annans. Det är inte något du kan hoppas på — det ska du säga uttryckligen när du bygger, och du ska testa det efteråt genom att logga in som två olika användare.
Testa det på riktigt. Skapa två konton, lägg in en rad med det ena, logga in med det andra och se efter. Det tar fem minuter och det är den enda kontrollen som spelar roll innan du släpper in någon annan.
Att ta betalt
Ska appen kosta pengar kopplar du in en betalväxel. Stripe är standard och fungerar i Sverige, Klarna finns om dina kunder förväntar sig det, och Swish går att lösa men är krångligare än folk tror.
Räkna med att betalningsdelen tar lika lång tid som resten av appen. Inte för att det är svårt att koppla in, utan för att du behöver bestämma vad som händer när någon avbryter, när ett kort går ut, och när någon vill ha pengarna tillbaka. Det är affärsbeslut, inte tekniska beslut, och ingen AI tar dem åt dig.
Publicera och låt någon annan testa
En app som bara du har sett är inte testad. Publicera på en egen adress, skicka länken till tre personer som liknar dina tänkta användare och be dem göra en enda sak utan att du säger hur.
Sitt bredvid om du kan. Det du ser de första två minuterna är mer värt än allt du själv tänkt ut på en månad. Nästan alltid handlar det om att något inte heter det de trodde, eller att en knapp sitter där de inte tittar.
Ett exempel på hur det kan se ut: Flytthjälp.com är byggd precis så här, en kväll åt gången, och publicerad långt innan den kändes färdig. Den samlar sådant man måste ta tag i vid en flytt, som att säga upp abonnemang, ändra adress och räkna på rutavdraget. Den ärliga delen av exemplet är att bygget gick fort medan besökarna inte gjorde det — sajten har funnits i några månader och tar fortfarande emot sina första från Google. Det är den vanliga ordningen, och det är bättre att veta det innan än efter.
Vad det kostar att hålla igång
Fyra kostnader, och de kommer i den här ordningen.
Verktyget du bygger i har oftast en gratisnivå som räcker för att prova och en månadsavgift när du bygger på riktigt. Domänen kostar en slant om året. Databas och drift ingår ofta i verktyget till en början, men blir en egen post när appen växer. Och betalväxeln tar sin del av varje transaktion.
Priserna ändras hela tiden, så jag skriver inte ut några här. Titta på verktygets egen prissida innan du bestämmer dig, och räkna på vad appen ska tjäna innan du räknar på vad den kostar.
Vanliga fel
Att bygga allt på en gång. Den enda funktionen som spelar roll, först. Resten när någon frågat efter den.
Att aldrig publicera. En app i utkastläge är en idé. Publicera fult och ändra sedan.
Att inte testa inloggningen. Se stycket om databasen. Det här är det enda felet i listan som kan skada någon annan än dig.
Att välja verktyg först. Vad appen ska göra avgör verktyget. Aldrig tvärtom.
Att sluta när det blir tråkigt. Det blir tråkigt ungefär vid det tredje ändringsvarvet. Det är också då de flesta appar som blir bra blir bra.
Nästa steg
Sätt dig en kväll med de tre frågorna högst upp och svara på dem. Öppna sedan verktyget och skriv din första prompt. Har du kommit dit har du gjort det som de flesta aldrig gör.
Vill du ha någon som går bredvid finns kurserna här nedan. De är gratis att läsa.