No-code eller custom-udvikling?
No-code rækker langt til interne værktøjer, enklere portaler og tidlige produkttests mens custom-udvikling er nødvendig ved følsomme data, unik forretningslogik, store volumener eller lang levetid. Regn på den samlede omkostning: No-code er billigt at starte med, men bærer platformsgebyrer, konsulentafhængighed og lock-in mens custom koster mere i starten og giver fuld kontrol over tid.
No-code-værktøjerne er modnet hurtigt, og til visse opgaver er de i dag det oplagte valg. Til andre er de en blindgyde man først opdager efter to år. Her er en nøgtern gennemgang af hvad no-code kan i 2026, hvad det koster over tid, og hvilke kriterier der bør styre valget.
Hvad kan no-code i produktion i 2026?
Mere end ryet blandt udviklere antyder, mindre end værktøjernes egne landingssider lover. I produktion fungerer no-code i dag godt til:
- Interne værktøjer: adminpaneler, sagsgange, enklere registre og dashboards.
- Formular- og procesflows: ansøgninger, onboarding, godkendelseskæder.
- Enklere kundeportaler og hjemmesider med standardfunktionalitet.
- Automatiseringer der forbinder færdige systemer via eksisterende integrationer.
- Tidlige produkttests: Valider efterspørgslen før I investerer i en rigtig løsning.
Grænserne går ved høj transaktionsvolumen, kompleks eller unik forretningslogik, avanceret brugeroplevelse, dybe integrationer med systemer uden færdige koblinger samt skrappe krav til ydeevne, sikkerhed og audit.
En risiko der er vokset i takt med værktøjerne, er skygge-IT: afdelinger der bygger deres egne no-code-løsninger uden at IT-afdelingen ved det. Værktøjerne er en styrke når løsningerne har en ejer, en plan for drift og vedligeholdelse og en plads i systemlandskabet. De er en tikkende omkostning når forretningskritiske flows viser sig at hænge på en app som ingen har ansvaret for.
Samlet omkostning over tid, ikke startomkostning
No-code vinder næsten altid på startomkostningen. Men tre poster kommer til over tid:
- Platformsgebyrer der ofte skalerer pr. bruger pr. måned: billigt med ti brugere, mærkbart med otte hundrede.
- Konsulentafhængighed: Avancerede løsninger kræver specialister i netop den platform, og deres timer koster som andre konsulenttimer.
- Exitomkostning: Logikken bor i platformen og følger ikke med ud. Skifter I spor, skal den bygges om fra bunden.
Custom-udvikling har den modsatte profil: højere startomkostning, men I ejer koden, betaler intet gebyr pr. bruger og kan skifte leverandør uden at starte forfra. Drift og vedligeholdelse ligger typisk på 15–25 procent af byggeomkostningen om året. Over tre til fem år krydser kurverne hinanden, og det sker tidligere jo flere brugere der kommer til.
Scenarie: portalen der voksede ud af platformen
En virksomhed bygger sin kundeportal i et no-code-værktøj: lancering på få uger og en lav månedlig omkostning. En helt rigtig beslutning, for behovet var ikke bevist, og platformen slog fint til.
To år senere ser det anderledes ud. Otte hundrede brugere gør gebyret pr. bruger mærkbart, ERP-systemet skal integreres dybere end platformens færdige kobling kan klare, og hvert nyt ønske kræver stadig flere konsulenttimer for at tvinge platformen derhen hvor den ikke vil. Virksomheden bygger om som custom, og det dyre er ikke selve den nye løsning, men at ingen del af logikken kan genbruges.
Moralen er ikke at no-code var forkert. Det var den rigtige start. Fejlen var at exitomkostningen aldrig var med i kalkulen.
Fire kriterier der afgør valget
| Kriterium | Taler for no-code | Taler for custom |
|---|---|---|
| Datafølsomhed | Ikke-følsomme eller interne data | Persondata, forretningskritiske data, auditkrav |
| Forretningslogik | Standardflows der ligner andres | Unik logik der er jeres konkurrencefordel |
| Volumen | Få brugere, lave transaktionsvolumener | Mange brugere, høj belastning, integrationspres |
| Levetid | Måneder til et par år, test og validering | Kernesystemer der skal leve i mange år |
Et enkelt tungtvejende “custom”-kriterium er ofte nok til at afgøre spørgsmålet: Det hjælper ikke at tre ud af fire peger mod no-code hvis forretningslogikken er selve konkurrencefordelen.
Ofte er svaret både og
De klogeste opsætninger kombinerer: Valider idéen i no-code og byg det om der viser sig at bære forretningen, eller lad en custom-bygget kerne være omgivet af no-code til interne værktøjer og rapporter. Samtidig har AI-assisteret udvikling sænket tærsklen for custom-løsninger, og det har gjort forskellen i startomkostning mindre end for nogle år siden. Det er værd at lave kalkulen igen, også selvom I lavede den for nylig.
Vi hos Weapp bygger custom når det tilfører værdi, og fraråder det når no-code er nok, for det er billigere for alle i det lange løb. Er du i tvivl om hvor jeres behov lander? Kontakt os, så tænker vi det igennem sammen.
Ofte stillede spørgsmål
Er no-code sikkert nok til persondata?
Det afhænger af platformen og af hvordan løsningen konfigureres, men ansvaret efter GDPR er altid jeres, uanset værktøj. Tjek hvor data opbevares, at der findes en databehandleraftale, og hvordan adgangsrettigheder styres. Til følsomme oplysninger vælger mange custom-udvikling netop for kontrollens skyld.
Kan man flytte fra no-code til custom senere?
Ja, men regn med at bygge nyt snarere end at flytte. Data kan som regel eksporteres, men forretningslogikken bor i platformen og skal bygges om fra bunden. Planlæg for den exitomkostning allerede når no-code vælges, så bliver den en bevidst beslutning i stedet for en overraskelse.
Hvad koster no-code sammenlignet med custom-udvikling?
Startomkostningen for no-code er ofte en brøkdel af en tilsvarende custom-løsning. Den samlede omkostning over tid afhænger af platformsgebyrer der skalerer med antallet af brugere, konsulenttid til avancerede tilpasninger og en eventuel ombygning ved exit. Sammenlign altid på en treårskalkule, ikke på startprisen.
Hvad er forskellen på no-code og low-code?
No-code bygger udelukkende på visuelle værktøjer uden programmering mens low-code tillader egen kode i hullerne hvor platformen ikke slår til. Low-code er dermed mere fleksibelt, men kræver udviklerkompetencer og deler samtidig no-codes afhængighed af platformens livscyklus og prissætning.
Hvornår er no-code det forkerte valg fra starten?
Når forretningslogikken er jeres konkurrencefordel, når volumenerne er store, når der kræves dybe integrationer, eller når produktet skal leve i mange år. Så bliver platformens begrænsninger et loft I rammer tidligt, og den lave startomkostning bliver byttet til en dyr ombygning.