Skapa app utan programmering: när räcker en appbyggare?

Vad en appbyggare är

En appbyggare, eller no-code-verktyg, låter dig sätta ihop en app av färdiga block i webbläsaren: listor, formulär, kartor, inloggning och en enkel databas. Du drar och släpper, kopplar fälten till ett kalkylark eller verktygets egen databas och publicerar. Vissa verktyg skapar bara webbappar, andra kan paketera appen för App Store och Google Play.

Det finns också mellanformer, så kallade low-code-verktyg, där man kan skriva egen kod i vissa delar. De ger mer frihet men kräver att någon i teamet kan programmera. Gemensamt för alla är att appen körs på leverantörens plattform och följer leverantörens villkor, vilket är det viktigaste att förstå innan ni väljer.

När no-code räcker

En appbyggare är ett bra val när följande stämmer:

• Ni vill testa en idé snabbt. En klickbar version på några dagar kan visa om någon alls vill använda appen, innan ni investerar mer.
• Appen är intern. En inventeringslista, en checklista för personal eller ett enkelt rapportformulär behöver sällan mer än verktygets block.
• Antalet användare är litet. Tiotals eller några hundra användare klarar de flesta verktyg.
• Logiken är enkel. Visa, lägga till, ändra och ta bort poster i en tabell.
• Utseendet behöver inte sticka ut. Mallarna ser ordentliga ut men liknar varandra.

Där appbyggare slår i taket

Problemen dyker sällan upp första veckan. De kommer när appen börjar användas på riktigt.

Ägande och export

Hos de flesta appbyggare äger ni innehållet men inte appen. Den går bara att köra inne i verktyget. Vill ni byta leverantör eller ta över utvecklingen själva går det ofta inte att exportera fungerande källkod; i bästa fall får ni ut data som en fil. Läs villkoren om export innan ni bygger något affärskritiskt.

Prestanda

Appar från blockbyggare laddar ofta mer än de behöver och känns trögare än en app byggd för telefonen, särskilt med långa listor, bilder och svag mobiltäckning. Offline-läge saknas eller är begränsat.

Logik och integrationer

Så fort appen behöver regler som inte finns som färdigt block, till exempel prisberäkning, bokning med resurser, olika roller med olika rättigheter eller koppling till Fortnox, BankID eller ett affärssystem, blir lösningarna krångliga eller omöjliga.

Butikskrav

Apple avvisar appar som bara är en paketerad webbsida utan egen funktion. Appar byggda med mallar kan också fastna på att de ser ut som många andra appar. Läs mer i guiden om att publicera i App Store.

Säkerhet och persondata

Ni styr sällan var data lagras eller hur behörigheter fungerar i detalj. För appar med kunduppgifter behöver ni ett personuppgiftsbiträdesavtal med leverantören och veta i vilket land servrarna står. Finjusterad behörighet, till exempel att en anställd bara ser sina egna kunder, är ofta svår att bygga med färdiga block.

Beroende av leverantören

Ändrar verktyget sina villkor, höjer priset eller läggs ner, följer er app med. Ni kan inte välja att stanna kvar på en äldre version eller flytta appen till en annan server.

Månadsavgifter som växer

Prismodellen bygger ofta på antal användare, antal poster eller vilka funktioner som är upplåsta. Det som kostade lite under testet kan bli en betydande månadskostnad när appen växer, och den avgiften försvinner aldrig.

Jämförelse: appbyggare eller egenutvecklad app

Räkneexempel: månadsavgift mot egen app

Exempel: en förening använder en appbyggare som kostar 1 500 kr i månaden när antalet medlemmar växer. På fem år blir det 90 000 kr, och appen är fortfarande hyrd. En egenutvecklad enklare app kostar 49 000–150 000 kr och därefter underhåll om ni vill ha det. Räkneexemplet visar inte att det ena alltid är billigare, bara att den löpande avgiften behöver räknas in. Jämför med er egen situation i priskalkylatorn.

Frågor att ställa innan ni väljer verktyg

Om ni bestämmer er för en appbyggare, gå igenom de här frågorna innan ni lägger in data och bjuder in användare:

1. Vad kostar verktyget vid tio gånger så många användare som i dag?
2. Kan vi exportera all data i ett öppet format, och hur ofta?
3. Kan appen publiceras i App Store och Google Play under vårt företags namn?
4. Var lagras data, och finns ett personuppgiftsbiträdesavtal?
5. Fungerar appen utan täckning, och i så fall vilka delar?
6. Vad händer med appen om vi slutar betala?

Kan ni inte få tydliga svar på fråga 2 och 6 bör appen inte bli affärskritisk.

Spara svaren tillsammans med en lista över vad appen gör i dag. Om ni senare går över till en egenutvecklad app blir den listan början på kravspecifikationen, och den visar vilka funktioner användarna faktiskt använder och vilka som kan vänta till en senare version.

En vettig väg: börja enkelt, bygg rätt när idén håller

Många gör så här:

1. Bygg en prototyp i ett no-code-verktyg eller en klickbar prototyp i Figma och visa den för tio riktiga användare.
2. Skriv ner vad som fungerade och vad som saknades.
3. När idén håller: ta fram en kravspecifikation och bygg en MVP som ni äger.

Prototypen är inte bortkastad. Den blir underlag för designen och sparar tid i förstudien. Vill ni hellre lära er koda själva finns guiden utveckla app själv. Ett mellanting är en webbapp eller PWA, som är billigare än en app i butikerna men ändå egen kod.