Gå til indhold

No-code-platforme (Bubble, Softr, Glide): hvor langt kan du komme?

Hvor langt kan en no-code-platform som Bubble, Softr eller Glide tage dig? Ærlig guide til pris ved vækst, hastighed, ejerskab og hvornår kode overtager.

Af

Freelance full-stack udvikler

Udgivet
Læsetid
12 min.
Indhold i indlægget8

En no-code-platform som Bubble, Softr eller Glide kan tage dig længere end mange udviklere vil indrømme: fra den første prototype til betalende kunder, en kundeportal eller et internt værktøj som hele firmaet bruger. Grænsen kommer sjældent som en mur. Den kommer som en månedlig regning der vokser med brugerne, en app der bliver langsom når data hober sig op, og opdagelsen af at du ikke kan tage appen med dig når du vil videre.

Jeg skriver selv kode og lever af det, så jeg har en interesse i hvor grænsen går. Derfor handler guiden lige så meget om hvornår du skal blive i no-code, som om hvornår du skal lade være.

Den korte version

Bubble, Softr og Glide: hvad de er bedst til, og hvor de typisk stopper
BubbleSoftrGlide
Bedst tilWebapps med login, database, betaling og egen forretningslogik, fx en MVP af et SaaS-produkt eller en markedspladsKundeportaler, medlemsområder og interne værktøjer oven på data du allerede harMobilvenlige apps til medarbejdere, fx opgaver, lager og registreringer ude hos kunden
Hvor dine data liggerI Bubbles egen databaseI Softrs egen database eller en kilde som Airtable eller Google SheetsI Glides egne tabeller eller et regneark som Google Sheets eller Excel
Hvad du betaler forPlan plus forbrug målt i workload unitsPlan plus antal brugere, records og automatiske handlingerPlan plus brugere og updates (ændringer i data)
Hvor grænsen typisk mærkesForbrugsprisen, hastighed ved tunge søgninger og flere der bygger på samme appMange eksterne brugere og logik der ikke passer ind i de færdige blokkeMange rækker og mange ændringer i data
Kan du tage appen med?Nej, kun data (CSV eller API)Nej, men data kan ligge i din egen kildeNej, men data kan ligge i dit eget regneark

Min beslutningsregel er enkel. Brug no-code så længe du stadig lærer hvad løsningen skal kunne, og så længe den månedlige regning er lavere end prisen for at eje og vedligeholde en kodet version. Skift når en af de to ting holder op med at være sand.

No-code er én af fire veje til din egen løsning. Hvordan den står mod en færdig standardløsning, at kode selv eller at få noget udviklet, har jeg samlet i guiden til at lave din egen platform.

Hvad no-code-platforme faktisk er gode til

Det er let for en udvikler at affeje no-code. Det gør jeg ikke. Til mange opgaver er det det billigste rigtige valg, og den største fordel er ikke engang prisen. Det er at du kan ændre løsningen selv, samme dag som en kunde siger noget du ikke havde forudset.

Uden en linje kode kan du realistisk nå disse ting:

  • En MVP (første version af et produkt) med login, betaling via Stripe og de første betalende kunder. Bubble er bygget til netop det.
  • En kundeportal hvor dine kunder logger ind og ser ordrer, dokumenter eller status. Softr er stærk her, især når data allerede ligger i Airtable eller et regneark.
  • Et internt værktøj til medarbejdere der er på farten: tjeklister, registreringer, lageroptælling. Glide er lavet til telefonen og til folk der ikke vil læse en manual.
  • Et første skridt væk fra et regneark der er blevet for skrøbeligt. De typiske tegn har jeg samlet i 11 tegn på at din virksomhed er vokset ud af Excel, og en Softr- eller Glide-app oven på det samme regneark er ofte det billigste første skridt.

Fælles for dem er at du lærer hurtigt. En no-code-app som rigtige brugere har klikket rundt i, fortæller dig mere om hvad der skal bygges, end en kravspecifikation kan.

Bubble, Softr og Glide: hvor langt rækker hver af dem?

Priserne nedenfor er hentet fra platformenes egne prissider i oktober 2026. Alle tre afregner i dollar og ændrer jævnligt planerne, så tjek dem selv før du vælger.

Bubble: længst, men med en forbrugsmåler

Bubble er den mest fleksible af de tre. Du designer selv databasen, bygger logikken som workflows (automatiske handlingsforløb) og kan kalde eksterne API'er. Det er tættest på et rigtigt softwareprodukt, og derfor har Bubble også den stejleste læringskurve.

Ifølge Bubbles prisside koster Starter 59 dollar om måneden, Growth 209 og Team 549 ved årlig betaling. Planerne inkluderer 175.000, 250.000 og 500.000 workload units om måneden. Workload units er Bubbles mål for hvor meget arbejde serveren udfører, fx søgninger i databasen, workflows og API-kald. Bruger du mere, køber du ekstra eller går en plan op.

To ting er værd at hæfte sig ved. Forbruget afhænger af hvordan appen er bygget, så to apps med lige mange brugere kan have meget forskellige regninger. Og prisen stiger også med teamet: Starter har én person der kan redigere appen, Growth to og Team fem. Skal tre personer bygge samtidig, er du på Team-planen.

Bubble kan sagtens bære en MVP med betalende kunder. Spørgsmålet er sjældent om den kan, men hvad det koster, og hvor afhængig du vil være.

Softr: stærk til portaler, prissat efter brugere

Softr bygger brugerflader oven på data. Du sætter sider sammen af færdige blokke som lister, formularer og detaljevisninger, og du styrer hvem der må se hvad.

På Softrs prisside koster Basic 19 dollar, Pro 99 og Business 329 om måneden ved årlig betaling. Softr skelner mellem interne brugere med samme maildomæne som dig og eksterne brugere. Pro inkluderer 10 interne og 50 eksterne, Business 30 interne og 100 eksterne. Softrs egen database kan rumme 50.000 records (rækker) på Basic, 500.000 på Pro og 1 million på Business. Egen kode og API-forbindelser kræver Pro.

Det betyder at en kundeportal til 40 kunder er billig, mens en portal til 400 kunder bliver en markant større post, fordi du betaler for ekstra brugere oveni Business-planen. Logikken er også mere begrænset end i Bubble. Passer din proces ikke ind i blokkene, ender du med omveje.

Hvornår en kundeportal bør udvikles, og hvornår en færdig løsning er nok, har jeg skrevet om i kundeportal: custom-udviklet eller white-label.

Glide: hurtigst til medarbejderapps

Glide gør et regneark til en app der fungerer godt på telefonen. Det er det hurtigste af de tre at komme i gang med, og det passer til interne apps hvor medarbejdere registrerer, krydser af og slår op.

Tallene her er fra Glide Classics prisside, altså det oprindelige Glide. Business-planen koster 199 dollar om måneden ved årlig betaling og inkluderer 30 brugere, 5.000 updates og op til 100.000 rækker i Glides skalerbare tabeller. Kilder som Google Sheets er begrænset til 25.000 rækker. Ekstra brugere koster 5 dollar om måneden ved årlig betaling, og ekstra updates 2 cent stykket.

Glide har samtidig lanceret GlideOS, et nyt AI-baseret produkt hvor planerne bygger på credits. Ifølge Glides prisside er det et selvstændigt produkt med eget abonnement. Det er ikke et problem i sig selv, men det minder dig om at det er platformen der bestemmer retningen, ikke dig.

De tre grænser hvor kode overtager

No-code holder sjældent op med at virke fra den ene dag til den anden. Det bliver gradvist dyrere, langsommere eller mere risikabelt. Det er de tre grænser jeg kigger efter.

Pris ved vækst

Et regneeksempel med Glide Classic: 80 medarbejdere laver hver 10 registreringer om dagen, 21 arbejdsdage om måneden. Tæller hver registrering som én update, giver det omkring 16.800 updates om måneden. På Business-planen bliver det 199 dollar for planen, 250 dollar for de 50 ekstra brugere og cirka 236 dollar for de ekstra updates. I alt omkring 685 dollar om måneden, eller over 8.000 dollar om året.

Det kan sagtens være en god handel. Pointen er at regningen vokser med brugen. En kodet løsning flytter udgiften: den koster mere at bygge og skal vedligeholdes, men driftsprisen stiger ikke på samme måde med hver ny bruger. Hvordan du regner de to modeller op mod hinanden, gennemgår jeg i skræddersyet software vs standardsoftware.

Hastighed og store datamængder

En no-code-platform er bygget til at være generel, og det koster når data vokser. De typiske symptomer er lister der er flere sekunder om at indlæse, søgninger og filtre der bliver langsomme ved mange tusinde rækker, og automatiseringer der står i kø. Bygger appen på et regneark, kommer synkroniseringen oveni.

Meget kan forbedres ved at strukturere data bedre, og en erfaren no-code-udvikler kan ofte rykke grænsen. Men du bestemmer ikke selv over serveren, databasen eller caching (mellemlagring af resultater). Hos Bubble står en server der kan tilpasses, kun på Enterprise-planen.

Test er en grænse for sig. De fleste no-code-platforme har begrænsede muligheder for automatiske test, så hver ændring skal afprøves i hånden. Det går med én der bygger og få brugere. Det bliver risikabelt når flere bygger, og kunderne betaler.

Ejerskab og flytbarhed

Bubble skriver selv i sin manual om ejerskab af app og data at du ejer design og brugerdata, mens Bubble ejer den underliggende kode, og at apps kun kan køre på Bubbles platform. Data kan eksporteres som CSV eller hentes via API'et. Bubble lover også at frigive sin kildekode som open source hvis firmaet lukker. Det er et fornuftigt sikkerhedsnet, men det er ikke det samme som at kunne flytte i morgen.

Softr og Glide har en fordel her. Lægger du data i din egen Airtable eller dit eget regneark, ejer du data fuldt ud. Selve appen, altså skærme, rettigheder og logik, skal stadig bygges forfra et andet sted.

Ejerskab bliver konkret i tre situationer: når en stor kunde kræver at data ligger i EU (hos Bubble står valg af hostingplacering kun under Enterprise), når en investor eller køber spørger hvem der ejer teknologien, og når platformen ændrer pris eller produkt.

Sådan tester du om din idé kan blive i no-code

Det dyreste er at opdage grænsen efter et halvt års arbejde. Brug en uge eller to på at presse platformen før du bygger det hele:

  1. Skriv kerneflowet ned på én side. Hvem logger ind, hvad gør de, og hvad sker der bagefter? Skriv også de regler ned der afhænger af hvilken kunde eller rolle brugeren har. Det er dem der oftest sprænger rammerne.
  2. Byg den sværeste skærm først. Ikke forsiden, men skærmen med rettigheder, beregninger eller flest datakilder. Kan platformen klare den uden omveje, kan den sandsynligvis også klare resten.
  3. Test med realistiske datamængder. Importér et års data, eller lav testdata i samme omfang, og se hvordan lister og søgninger opfører sig på en almindelig telefon.
  4. Regn prisen ud ved ti gange så mange brugere. Brug prissiden og din egen forventning til brugere, rækker og forbrug. Kan du leve med det tal, er du godt på vej.
  5. Tjek hvad du ejer. Står kontoen i dit firmas navn, kan data eksporteres, og kører betalinger gennem din egen Stripe-konto? Så kan kunder og abonnementer blive hvor de er hvis du skifter.
  6. Bestem på forhånd hvornår du skal videre. Skriv en konkret udløser ned, fx et beløb på den månedlige regning, et antal brugere eller et krav fra en kunde. Så bliver skiftet en plan og ikke en panikbeslutning.

Før du vælger en no-code-platform

  • Kerneflowet kan bygges uden plugins eller omveje
  • Den sværeste skærm er bygget og testet
  • Appen er afprøvet med et realistisk datasæt på mobil
  • Prisen er regnet ud ved ti gange så mange brugere
  • Kontoen står i firmaets navn, ikke i en medarbejders eller freelancers
  • Data kan eksporteres, og du har prøvet det
  • Betalinger kører gennem din egen Stripe-konto
  • Du ved hvor data ligger, og har en databehandleraftale med leverandøren
  • Workflows og datamodel er beskrevet så en anden kan overtage
  • Der er en skrevet udløser for hvornår løsningen skal flyttes

Når du skal videre: fra no-code til kode

Skiftet er en genopbygning, ikke en konvertering. Ingen af de tre platforme giver dig kode du kan arbejde videre i. Til gengæld har du noget de fleste nye projekter mangler: en fungerende app, rigtige brugere og en klar idé om hvad der ikke skal med.

Du behøver ikke flytte alt på én gang. En mellemvej er at kerneproduktet bliver kodet, mens et internt overblik bliver i Softr eller Glide oven på den nye database, hvis platformen kan forbinde til den. Eller omvendt: Bubble-appen bliver stående, mens den tungeste del flyttes over i en selvstændig backend (serverdel) som appen kalder via et API. Begge dele kan købe dig tid.

Selve flytningen, fra dokumentation af workflows til brugere der skal vælge ny adgangskode, har jeg beskrevet trin for trin i guiden om no-code-udviklere og overgangen til kode. Er det en markedsplads du har bygget i Bubble, er der særlige ting at tænke på, og dem finder du i guiden til at udvikle en tosidet markedsplads.

Næste skridt

Er du stadig ved at finde ud af hvad brugerne vil have, så bliv i no-code, brug tjeklisten og skriv din udløser ned. Det er den billigste måde at lære på.

Har du ramt en af grænserne, eller skal løsningen være et produkt kunder betaler for i mange år, så se min ydelse til udvikling af SaaS-produkter. Større projekter starter med et forprojekt til fast pris hvor din no-code-app bruges som grundlag, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Kan jeg skifte fra Glide eller Softr til Bubble i stedet for til kode?

Ja, og det kan være et fornuftigt mellemtrin. Er du vokset ud af de færdige blokke, men ændrer du stadig meget i produktet, får du mere frihed i Bubble uden at betale for udvikling. Regn bare med at det også er en genopbygning, og at du bytter én platformsafhængighed ud med en anden. Gør det kun hvis du ikke allerede ved at du skal have kode inden for et år eller to.

Hvad er forskellen på no-code og AI-appbyggere som Lovable og Bolt?

Den største forskel er at AI-appbyggere genererer rigtig kode som du kan få ud i dit eget repository (kodearkiv). Du er altså ikke låst til platformen på samme måde. Til gengæld får du også ansvaret for koden: sikkerhed, datamodel og drift skal nogen kunne gennemgå og vedligeholde. No-code skjuler den kompleksitet for dig. Det gør AI-værktøjerne ikke.

Kan data ligge i EU når jeg bruger en no-code-platform?

Det afhænger af platformen og planen. Hos Bubble står valg af hostingplacering kun under Enterprise-planen, så på de almindelige planer bestemmer du det ikke selv. Tjek altid leverandørens databehandleraftale og liste over underdatabehandlere, og spørg dine største kunder hvilke krav de stiller. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme oplysninger.

Hvad koster det at bygge en no-code-app om til kode?

Det afhænger af hvor meget appen gør, men det er som regel lettere at estimere end et projekt der starter fra en idé. Beslutningerne om skærme, roller og regler er allerede truffet, og du kan ofte skære funktioner fra som ingen bruger. Den mest præcise vej til et tal er et kort forprojekt hvor en udvikler gennemgår appen og giver en fast pris på første version.