No-code- og low-code-udviklere: hvad kan de, og hvor stopper det?

En no-code-udvikler bygger apps, interne værktøjer og automatiseringer i visuelle værktøjer som Bubble, Webflow, Make og Zapier i stedet for at skrive koden fra bunden. Det er ofte det billigste rigtige valg når du skal teste en idé, binde systemer sammen eller give få medarbejdere et internt værktøj. Grænsen nås typisk når løsningen skal vokse, håndtere komplekse rettigheder og følsomme data, eller når du skal eje den og kunne flytte den.

Jeg skriver selv kode og lever af det, så jeg er ikke neutral. Derfor vil jeg være tydelig om to ting: hvornår en no-code-specialist er et bedre køb end mig, og hvornår det er tid til at skifte til kode.

Den korte version

Min tommelfingerregel er enkel. Brug no-code så længe du stadig er ved at finde ud af hvad løsningen skal kunne. Skift til kode når du ved det og løsningen er blevet noget din forretning ikke kan undvære.

No-code-udvikleren er én rolle blandt mange. Hvor den passer ind blandt de andre, kan du se i min oversigt over 12 typer udviklere og hvad de laver.

No-code eller low-code: hvad er forskellen?

Begge typer udviklere bygger software uden at starte med en tom kodefil. Forskellen er hvad de gør når værktøjet ikke kan mere.

En no-code-udvikler arbejder i en visuel editor. Skærmbilleder trækkes på plads, data defineres i tabeller, og logikken bygges som workflows: når brugeren klikker her, så gem det her og send en mail. Kan værktøjet ikke det du vil, er svaret en omvej, et plugin eller et ekstra værktøj.

En low-code-udvikler arbejder også visuelt, men skriver kode der hvor værktøjet stopper. I Microsofts Power Apps skrives logikken i formelsproget Power Fx, og i Retool kan man skrive JavaScript og SQL direkte. Det giver mere frihed og kræver en mere teknisk profil. Bruger din virksomhed Microsoft 365, er Power Apps ofte det naturlige sted at starte med interne værktøjer.

Fire typiske profiler

• Appbyggeren laver webapps med login, database og betaling i Bubble eller et lignende værktøj. Det er tættest på et rigtigt produkt.
• Hjemmesidebyggeren designer og bygger markedsføringssider i Webflow eller Framer.
• Automatiseringsspecialisten binder systemer sammen i Make, Zapier eller n8n, fx fra webshop til regnskab og CRM.
• Byggeren af interne værktøjer sætter oversigter, formularer og godkendelser op oven på Airtable, et regneark eller en database med Softr, Glide, Retool eller Power Apps.

Spørg hvilken af dem du taler med. En dygtig Webflow-designer er ikke nødvendigvis den rigtige til en Bubble-app med betaling og brugerroller.

AI-værktøjer som Lovable og Bolt bliver ofte nævnt i samme åndedrag, men de er noget tredje. De genererer rigtig kode som du kan få ud i dit eget repository (kodearkiv). Det gør overgangen anderledes, og det vender jeg tilbage til nedenfor.

Hvornår no-code er det billigste rigtige valg

Jeg anbefaler en no-code-specialist frem for en udvikler som mig når:

• Du skal finde ud af om nogen vil bruge løsningen. En prototype med rigtige brugere lærer dig mere end en kravspecifikation, og den er billig at smide ud igen.
• Opgaven er at binde systemer sammen som allerede kan forbindes i Make eller Zapier. Et specialudviklet integrationsprojekt betaler sig sjældent hvis en standardforbindelse kan klare det.
• Løsningen er intern, har få brugere og ingen følsomme data. Så er risikoen lav, og et abonnement pr. bruger er overskueligt.
• Du vil kunne rette tekster, felter og flows selv bagefter. I et godt opsat værktøj kan en ikke-teknisk medarbejder lave små ændringer uden at vente på nogen.
• Budgettet er lille, og tidsfristen er kort.

Timepriserne for no-code-freelancere svinger meget, fra billige profiler på de internationale markedspladser til erfarne specialister der ligger tæt på almindelige udviklere. Besparelsen ligger sjældent i timeprisen. Den ligger i at login, database, hosting og formularer er færdige fra start. Derfor kræver projektet langt færre timer.

Passer det meste af listen på dig, er mit ærlige råd at du skal tale med en no-code-specialist og ikke med mig. Det er bedre at høre det nu end efter et forprojekt.

Hvor stopper det? Tegn på at no-code ikke slår til

No-code holder ikke op med at virke fra den ene dag til den anden. Det bliver gradvist dyrere og mere besværligt. Det er de tegn jeg holder øje med:

• Regningen vokser hurtigere end forretningen fordi platformen afregner efter forbrug.
• Rettighederne bliver komplicerede: kunder med egne brugere, roller pr. firma og data som kun nogle må se.
• Du gemmer persondata og kan ikke svare præcist på hvor de ligger og hvem der har adgang.
• Der er så mange workflows og automatiseringer at ingen tør ændre noget, og fejl opdages først når en kunde klager.
• Du bruger mere tid på omveje i værktøjet end på at bygge nyt.
• Investorer, store kunder eller en kommende køber spørger hvem der ejer teknologien.

Prisen er det tegn flest overser fordi den sniger sig ind. Bubble måler forbrug i "workload units", Zapier i opgaver og Make i credits. Ifølge Bubbles prisside koster planerne 59-549 dollar om måneden ved årlig betaling før du når Enterprise. Zapiers prisside viser samme mønster: Pro-planen starter ved 19,99 dollar om måneden for 750 opgaver ved årlig betaling, og prisen stiger med antallet. Ingen af delene er dyre hver for sig, men flere brugere og flere automatiseringer giver en regning der kun går én vej.

Du lejer, du ejer ikke

Det sidste tegn hænger sammen med det vigtigste forbehold ved no-code. Bubble skriver selv i sin manual om ejerskab af app og data at apps kun kan køre på Bubbles platform. Flytter du, skal logikken bygges forfra. Dine data kan eksporteres som CSV eller hentes via API'et. Valg af hostingplacering står desuden kun under Enterprise-planen på prissiden. Kræver dine kunder at data ligger i EU, skal du undersøge det før du bygger.

At leje er fint til en prototype. Det er et problem for et produkt du skal bygge en virksomhed på.

Sådan foregår overgangen fra no-code til kode

Det vigtigste at forstå er at skiftet er en genopbygning og ikke en konvertering. Til gengæld starter du med en fordel de fleste projekter ikke har: en fungerende app som rigtige brugere har brugt. Sådan ville jeg gribe det an:

1. Beskriv hvad appen faktisk gør. Gå alle sider og workflows igennem, og skriv ned hvem der gør hvad, hvilke regler der gælder og hvilke systemer appen taler med. Tag skærmbilleder af det hele. Det bliver specifikationen.
2. Få dine data ud, og ryd op. Eksportér tabellerne, og find dubletter, tomme felter og data ingen bruger. En ny datamodel er en god anledning til at rydde op.
3. Skær ned før du bygger. Fjern de funktioner brugerne ikke bruger. Den kodede version bør være mindre end no-code-versionen, ikke større.
4. Behold det der virker. Markedsføringssiden kan sagtens blive i Webflow, og interne automatiseringer kan blive i Make. Det er kerneproduktet der skal flyttes, ikke nødvendigvis alt.
5. Byg ved siden af, og lad den gamle version køre. Brugerne mærker ingenting før den nye version er testet med rigtige data.
6. Planlæg selve skiftet. Adgangskoder kan som regel ikke flyttes med, så regn med at brugerne skal vælge en ny ved første login. Kører betalinger gennem din egen Stripe-konto, kan kunder og abonnementer blive hvor de er. Opsig først det gamle abonnement når den nye version har kørt stabilt et stykke tid.

Fordi beslutningerne om hvad appen skal kunne, allerede er truffet, er en genopbygning som regel lettere at estimere end et projekt der starter fra en idé. Er produktet ikke for stort, kan én fullstack-udvikler bygge hele første version så du kun har én at tale med.

Når prototypen er AI-genereret

Er din prototype bygget i Lovable, Bolt eller et lignende værktøj, ser overgangen anderledes ud. Lovable kan fx synkronisere koden til GitHub. Du har altså selve koden. Opgaven er derfor sjældent at starte forfra, men at få en udvikler til at gennemgå sikkerhed, datamodel og drift. Det har jeg skrevet en hel guide om: sådan gør du en AI-prototype klar til rigtige brugere.

Sådan vælger du en no-code-udvikler

Er du landet på no-code, så vælg ud fra opgaven og ikke ud fra værktøjet. En god no-code-udvikler siger det når et værktøj ikke passer, også selv om det er det værktøj vedkommende kan bedst. Bed om eksempler der ligner dit projekt, og prøv dem selv på mobilen.

Spørg også ind til hvad der sker om to år. Den bedste no-code-udvikler bygger med tanke på at en anden skal kunne overtage, og kan fortælle dig hvornår det er tid til at gå videre. Den rolle hvor nogen tænker med på den lange bane, har jeg beskrevet i teknisk partner over for leverandør. Om du skal vælge en freelancer eller et no-code-bureau, afhænger mest af omfanget, og det gennemgår jeg i min sammenligning af freelancer og bureau.

Næste skridt

Er du stadig ved at finde ud af hvad din løsning skal kunne, så find en no-code-specialist og brug tjeklisten ovenfor. Det er den hurtigste og billigste måde at lære hvad brugerne faktisk vil have.

Kan du genkende flere af tegnene på at du er ved grænsen, eller skal løsningen være et produkt kunder betaler for, så se hvordan jeg udvikler SaaS-produkter fra bunden. Større projekter starter med et forprojekt til fast pris hvor din no-code-version bruges som grundlag, og du ejer koden fra første dag.

Ofte stillede spørgsmål

Kan en no-code-app klare mange brugere?+

Ofte ja, og længere end mange tror. Problemet er sjældent at appen går helt i stå. Det er snarere at den bliver langsom ved store datamængder og tung logik og at forbrugsprisen stiger. Hvor grænsen går, afhænger af værktøjet og af hvordan appen er bygget. En erfaren no-code-udvikler kan ofte rykke grænsen ved at strukturere data og workflows bedre før det bliver nødvendigt at skifte.

Er no-code sikkert nok til persondata?+

Det kan det være, men ansvaret er dit. Du skal vide hvor data ligger og hvem der har adgang, og du skal have en databehandleraftale med leverandøren. I mange no-code-værktøjer skal adgangsregler sættes aktivt op, ellers kan data være synlige for flere end tiltænkt. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme oplysninger.

Kan jeg lære no-code selv i stedet for at hyre en?+

Ja, til enkle opgaver. Simple automatiseringer i Zapier eller Make og oversigter i Softr kan de fleste lære at bygge på kort tid. Bubble har en stejlere læringskurve fordi du reelt designer en database og forretningslogik. En god mellemvej er at hyre en no-code-udvikler til at sætte strukturen op og selv bygge videre på den bagefter.

Kan du hjælpe med min Bubble- eller Webflow-løsning?+

Det afhænger af opgaven. Jeg arbejder i kode, primært Laravel og React/Next.js, så til at bygge videre i selve værktøjet får du typisk mere for pengene hos en specialist i det. Skal løsningen flyttes over i kode, have en backend den kan tale med, eller vil du have vurderet om tiden er inde til at skifte, kan jeg hjælpe. Skriv kort hvad du har.