No-code eller custom-utvikling?
No-code er ofte nok til interne verktøy, enklere portaler og tidlige produkttester, mens custom-utvikling kreves ved sensitive data, unik forretningslogikk, høye volumer eller lang levetid. Regn på totalkostnaden: No-code er billig å starte med, men medfører plattformavgifter, konsulentavhengighet og innlåsing, mens custom koster mer i starten og gir full kontroll over tid.
No-code-verktøyene har modnet raskt, og for noen oppgaver er de i dag det selvsagte valget. For andre er de en blindvei som først oppdages etter to år. Her er en nøktern gjennomgang av hva no-code klarer i 2026, hva det koster over tid, og hvilke kriterier som bør styre veivalget.
Hva klarer no-code i produksjon i 2026?
Mer enn ryktet blant utviklere tilsier, mindre enn verktøyenes egne landingssider lover. I produksjon fungerer no-code i dag godt til:
- Interne verktøy: adminpaneler, saksbehandling, enklere registre og dashbord.
- Skjema- og prosessflyt: søknader, onboarding, godkjenningskjeder.
- Enklere kundeportaler og nettsider med standardfunksjonalitet.
- Automatiseringer som kobler sammen ferdige systemer via eksisterende integrasjoner.
- Tidlige produkttester: valider etterspørselen før dere investerer i fullverdig utvikling.
Grensene går ved høyt transaksjonsvolum, kompleks eller unik forretningslogikk, avansert brukeropplevelse, dype integrasjoner mot systemer uten ferdige koblinger og strenge krav til ytelse, sikkerhet og sporbarhet.
En risiko som har vokst i takt med verktøyene, er skygge-IT: avdelinger som bygger egne no-code-løsninger uten at IT-avdelingen vet om det. Verktøyene er en styrke når løsningene har en eier, en forvaltningsplan og en plass i systemkartet, og en kostnad som vokser i det skjulte når forretningskritiske prosesser viser seg å avhenge av en app som ingen har ansvaret for.
Totalkostnad over tid, ikke startkostnad
No-code vinner nesten alltid på startkostnad. Men tre poster kommer til over tid:
- Plattformavgifter som ofte beregnes per bruker og måned: billig med ti brukere, merkbart med åtte hundre.
- Konsulentavhengighet: Avanserte løsninger krever spesialister på akkurat den plattformen, og de tar like mye betalt per time som andre konsulenter.
- Kostnaden ved å forlate plattformen: Logikken ligger i plattformen og kan ikke tas med ut. Bytter dere spor, må den bygges opp igjen fra grunnen.
Custom-utvikling har motsatt profil: høyere kostnad i starten, men dere eier koden, betaler ingen avgift per bruker og kan bytte leverandør uten å begynne på nytt. Forvaltningen ligger typisk på 15–25 prosent av utviklingskostnaden per år. Over tre til fem år krysser kurvene hverandre, og det skjer tidligere jo flere brukere det blir.
Scenario: portalen som vokste ut av plattformen
En virksomhet bygger kundeportalen sin i et no-code-verktøy: lansering på noen uker og en lav månedskostnad. En helt riktig beslutning: Behovet var ennå ikke bevist, og plattformen strakk godt til.
To år senere ser det annerledes ut. Åtte hundre brukere gjør avgiften per bruker merkbar, ERP-systemet skal integreres dypere enn plattformens ferdige kobling klarer, og hvert nytt ønske krever stadig flere konsulenttimer for å tvinge plattformen dit den ikke vil. Virksomheten bygger løsningen på nytt med custom-utvikling, og det som koster, er ikke selve nybygget, men at ingen del av logikken kan gjenbrukes.
Lærdommen er ikke at no-code var feil. Det var en riktig start. Feilen var at kostnaden ved å forlate plattformen aldri var med i kalkylen.
Fire kriterier som avgjør veivalget
| Kriterium | Taler for no-code | Taler for custom |
|---|---|---|
| Datasensitivitet | Ikke-sensitive eller interne data | Personopplysninger, forretningskritiske data, krav til sporbarhet |
| Forretningslogikk | Standardprosesser som ligner andres | Unik logikk som er konkurransefortrinnet deres |
| Volum | Få brukere, lave transaksjonsvolumer | Mange brukere, høy last, mange integrasjoner |
| Levetid | Måneder til et par år, test og validering | Kjernesystem som skal leve i mange år |
Ett eneste tungt «custom»-kriterium er ofte nok til å avgjøre saken. Det hjelper ikke at tre av fire peker mot no-code hvis forretningslogikken er selve konkurransefortrinnet.
Ofte er svaret begge deler
De klokeste oppleggene kombinerer: Valider ideen i no-code og bygg om det som viser seg å bære forretningen, eller la en custom-utviklet kjerne omgis av no-code til interne verktøy og rapporter. Samtidig har AI-assistert utvikling senket terskelen for custom-utvikling, noe som har gjort gapet i startkostnad mindre enn det var for noen år siden. Kalkylen er verdt å gjøre på nytt, selv om dere gjorde den nylig.
Vi i Weapp utvikler custom-løsninger når det gir verdi, og fraråder det når no-code er nok. Det er billigere for alle i lengden. Er dere usikre på hvor behovet deres havner? Ta kontakt, så drøfter vi det.
Ofte stilte spørsmål
Er no-code trygt nok for personopplysninger?
Det avhenger av plattformen og av hvordan løsningen konfigureres, men dere har alltid ansvaret etter GDPR, uansett verktøy. Sjekk hvor dataene lagres, at det finnes en databehandleravtale, og hvordan tilganger styres. For sensitive opplysninger velger mange custom-utvikling nettopp for kontrollens skyld.
Kan man gå fra no-code til custom senere?
Ja, men regn med å bygge på nytt, ikke å flytte. Dataene kan som regel eksporteres, men forretningslogikken ligger i plattformen og må bygges opp igjen fra grunnen. Planlegg for den kostnaden ved å forlate plattformen allerede når dere velger no-code, så blir den en bevisst beslutning i stedet for en overraskelse.
Hva koster no-code sammenlignet med custom-utvikling?
Startkostnaden for no-code er ofte en brøkdel av tilsvarende custom-utvikling. Totalkostnaden over tid avhenger av plattformavgifter som øker med antall brukere, konsulenttid til avanserte tilpasninger og en eventuell ombygging hvis dere forlater plattformen. Sammenlign alltid ut fra en treårskalkyle, ikke ut fra startprisen.
Hva er forskjellen på no-code og low-code?
No-code bygger helt på visuelle verktøy uten programmering, mens low-code tillater egen kode der plattformen ikke strekker til. Low-code er dermed mer fleksibelt, men krever utviklerkompetanse. Samtidig deler det no-codes avhengighet av plattformens livssyklus og prissetting.
Når er no-code feil valg helt fra starten?
Når forretningslogikken er konkurransefortrinnet deres, når volumene er høye, når det kreves dype integrasjoner, eller når produktet skal leve i mange år. Da blir plattformens begrensninger et tak dere når tidlig, og den lave startkostnaden byttes mot en dyr ombygging.