CTO as a Service

No‑code, low‑code eller egen kode

En hånd trykker på en tablet med en uskarp bookingformular ved disken i et lille cykelværksted

No-code er værktøjer, hvor man bygger en applikation i en visuel brugerflade uden at programmere. Low-code er det samme med mulighed for at tilføje kode, hvor værktøjet ikke rækker. Egen kode betyder, at udviklere skriver programmet med almindelige programmeringssprog. No-code bærer ofte fint, når I skal afprøve en idé, bruge produktet internt eller betjene de første kunder. Grænsen kommer, når produktet får krav, platformen ikke kan opfylde, eller når afhængigheden af platformen begynder at skade forretningen.

Sådan skelner I de tre

Forskellen handler i praksis om tre ting: hvem der kan arbejde i løsningen, hvor frit den kan formes, og hvem der ejer grundlaget.

  • No-code kan bruges af en stifter eller en produktansvarlig. Friheden er begrænset til det, platformen tilbyder, og applikationen lever på platformen.
  • Low-code kræver som regel en person med teknisk indsigt. Friheden er større, og afhængigheden af platformen består.
  • Egen kode kræver udviklere. Friheden er næsten ubegrænset, og I skal selv tage ansvar for drift, sikkerhed og vedligehold.

AI-værktøjer, der skriver rigtig kode ud fra en beskrivelse, har gjort grænsen mere flydende. Det emne behandles for sig under produkter bygget med AI.

Hvor no-code bærer godt

No-code passer, når jeres første spørgsmål er, om nogen vil bruge produktet. Så tæller det at komme hurtigt i kontakt med kunder langt mere end en fleksibel opbygning. Det passer også til interne værktøjer, kundeportaler med enkle arbejdsgange og produkter, hvor værdien ligger i en proces frem for i et særligt stykke teknik.

Tre forhold gør no-code til et stærkt valg i starten:

  1. I kan selv lave rettelser, mens I lærer af kunderne.
  2. Standardfunktioner som login, formularer og betaling er allerede løst.
  3. Det koster en uges arbejde at tage fejl, hvor egen kode ofte koster en måneds.

Hvad I skal afprøve, og hvad der kan vente, kan I læse om under skæringen af første version.

Tegn på, at produktet er vokset fra platformen

Tegnene viser sig sjældent på én gang. Gå listen igennem, når I har betalende kunder:

  • Kernefunktionen må laves med omveje. Det, der gør jeres produkt særligt, kræver stadig flere krumspring.
  • Hastigheden falder med mængden af data. Sider, der var hurtige, bliver træge, og I kan ikke se ind i årsagen.
  • Kunderne stiller krav, I ikke kan svare på. En større kunde spørger, hvor data opbevares, hvem der kan se dem, og om login kan ske via deres eget system.
  • Regningen følger brugerne uforudsigeligt. Platformens betaling vokser, så økonomien i produktet bliver svær at planlægge.
  • Ændringer er blevet farlige. Ingen tør rette, fordi ændringen ikke kan afprøves adskilt fra det, kunderne bruger.

Ét tegn er en opgave, der skal løses. Flere på samme tid betyder, at I bør planlægge et skifte, inden en kunde tvinger jer.

Inden I vælger: fem spørgsmål til platformen

Spørgsmålene er nemme at stille nu og svære at få svar på senere. Læs platformens vilkår direkte, for de ændrer sig.

  1. Kan I eksportere jeres data i et format, andre kan bruge?
  2. Kan logikken eller koden følge med ud, eller bliver den tilbage?
  3. Hvor ligger data, og kan det oplyses til en kunde?
  4. Hvem ejer kontoen, og kan flere personer få adgang med hvert sit login?
  5. Hvad sker der med jeres produkt, hvis platformen ændrer vilkår eller lukker?

Svaret på spørgsmål to er ofte nej. Det er acceptabelt, så længe I ved det og har beskrevet, hvordan produktet virker, for så bliver no-code-versionen en meget præcis specifikation for den næste.

Når I skal videre

Et skifte behøver ikke ske på én gang. Tre veje er almindelige:

  • Blive og rydde op. Mange produkter kan holde længere med bedre struktur og færre særlige løsninger.
  • Flytte en del. Den tunge del bygges i kode, og resten bliver i platformen, forbundet via en integration.
  • Bygge forfra. Den første version bruges som specifikation, og data flyttes bagefter.

Når valget er taget, står I med de samme spørgsmål som andre, der skal have bygget noget, se freelancer, bureau eller eget team og teknologivalg til MVP’en. En erfaren teknisk leder kan hjælpe med at læse tegnene og afgøre, hvilken af de tre veje der passer. Det er sjældent en stor opgave, og den sparer ofte en forhastet ombygning.

Det skal I lade være med

  • At starte med egen kode af vane · spørg, hvad I reelt skal lære først.
  • At vælge platform uden at læse eksportvilkårene · I skal kende udgangen på forhånd.
  • At blive i no-code af stolthed · når kunderne mærker grænsen, er det tid til at flytte.

Det skal I kræve af den eksterne

  • ☐ En anbefaling, der passer til jeres fase, også når den lyder på no-code.
  • ☐ Et skriftligt overblik over grænserne i den valgte platform.
  • ☐ Klare tegn, I selv kan holde øje med, for hvornår I skal skifte.
  • ☐ En enkel plan for, hvordan data kan komme med.

Senest gennemgået: november 2026.

Næste skridt

Læs også: Kan vi selv bygge det med AI? · Bygge, købe eller integrere

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Mangler I en CTO?

Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.