Ja, til et vist punkt. En stifter uden udviklerbaggrund kan i dag bygge en fungerende første version med AI og vise den til rigtige kunder. Det ændrer ikke, at nogen skal eje arkitekturen, sikkerheden og driften, når der kommer betalende kunder. AI skriver koden, og leverandørerne af værktøjerne skriver i deres vilkår, at ansvaret for resultatet ligger hos jer. Det brugbare spørgsmål er derfor, hvilken af de tre faser I befinder jer i, og hvad næste fase kræver.
Fase 1: Idéen skal prøves
Her kan I komme langt alene. Målet er at lære, om nogen vil have produktet. Det, der tæller, er, at I kan vise et kerneflow og få reaktioner. I kan bruge en app-bygger, opdigtede data og et testlogin. Fejl koster jer lidt tid, og I kan smide det hele væk.
Der skal ingen CTO til i denne fase. Hold fast i to ting: læg ikke rigtige persondata ind, og hold styr på, hvad I lærer. Læringen er det vigtigste, I får ud af fasen. Hvad begrebet vibe coding dækker, er forklaret i hvad vibe coding er.
Fase 2: De første kunder bruger det
Nu bliver det alvor. Nogen er afhængig af, at produktet virker, og I opbevarer data, der tilhører andre. Mange stiftere kan fortsat selv bygge funktioner. Til gengæld dukker de spørgsmål op, som AI’en kun besvarer, hvis I ved, at de skal stilles:
- Kan én kundes data nå frem til en anden kunde?
- Hvad sker der med data, hvis værktøjet ændrer databasen?
- Hvem opdager det, når betalingen holder op med at virke?
- Hvordan ruller vi en dårlig ændring tilbage?
Her giver det mening at få en erfaren til at se på produktet i kort tid, uden at I behøver at ansætte nogen. Rækkefølgen er beskrevet i fra prototype til produkt.
Fase 3: Virksomheden afhænger af produktet
Når omsætningen hviler på produktet, skifter opgaven karakter. Kunder spørger om sikkerhed og oppetid. En stor kunde sender et spørgeskema. En fejl påvirker mange på én gang. Hver ændring skal testes, og nogen skal være til at få fat på, når noget går ned. Det kan ikke længere bæres af én person med en chat i browseren, også selv om personen er dygtig. I skal have en udvikler eller et team, og nogen skal lede det. Vælg mellem løsningerne med teknisk medstifter eller ekstern CTO.
Det, AI ikke tager fra jer
AI er god til at skrive kode og langt ringere til at stille de spørgsmål, I ikke selv har tænkt på. Fire ting bliver hos jer:
Arkitektur. Hvordan data er organiseret, og hvordan kunder er adskilt, er beslutninger, der bliver dyre at lave om. Værktøjet træffer dem gerne for jer, uden at I opdager det, og det træffer dem ud fra den seneste besked. Sjældent ud fra, hvor produktet skal hen om to år.
Sikkerhed. Den slags fejl, der er farlige, viser sig ikke på skærmen. De kendte svagheder står i eftersyn af AI-genereret kode.
Drift. Backup, overvågning, opdateringer og fornyelse af certifikater skal nogen have ansvar for, også i ferien.
Ansvar. Lovables og Cursors vilkår siger begge, at I selv skal vurdere det, værktøjet leverer. Kunderne vil desuden holde jer ansvarlige, uanset hvem eller hvad der har skrevet koden.
Spørgsmål, der kan vise, om I er klar til mere
Svar for jeres eget produkt:
- Hvor mange dages drift kan vi tåle at miste?
- Hvad sker der med virksomheden, hvis stifteren er væk i to uger?
- Har vi kunder med krav i kontrakten?
- Kan vi forklare produktets opbygning for en kundes IT-ansvarlige?
- Bruger vi mere tid på at rette gamle fejl end på at bygge nyt?
Er svarene svage på flere punkter, er I gået fra fase 2 til fase 3. Så er det næste skridt at få styr på tilstanden, før I bygger mere.
Når stifteren alligevel er den rette bygger
Der findes stiftere, der lærer hurtigt og gerne vil forstå det, værktøjet laver. For dem kan AI være en stor gevinst, også på længere sigt. Skiftet fra app-bygger til kodeværktøjer er ofte vejen, se typerne af værktøj. Betingelsen er, at I lærer at læse det, der bliver skrevet, og at I bruger versionsstyring og test. Bliver AI en genvej uden om forståelsen, flytter risikoen sig blot ud i fremtiden.
Pas også på tiden. En direktør, der bruger aftenerne på at rette fejl, bruger dem ikke på salg og kunder. Stifterens tid er virksomhedens knappeste ressource, og det er et godt argument for at slippe byggeriet på det rigtige tidspunkt.
Er I kommet dertil, hvor nogen skal lede teknologien, uden at I har råd eller behov for en fuldtidsansat, er det her, en fractional CTO kan bruges. Hos Nielco IT er rollen afgrænset til ledelse, leverandører, teknologivalg og team, mens selve kodearbejdet ligger hos jeres udviklere eller leverandør, og forløbet kan begynde med en gennemgang af produktet. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Spørgsmålet her er et andet end det, en virksomhed møder, når den overvejer, om en AI kan erstatte IT-rådgivning i hverdagen. Det er behandlet som spørgsmål til en AI om IT.
Det skal I lade være med
· At ansætte en fuldtids-CTO til en idé, ingen har prøvet. Lær først, om produktet har kunder.
· At lade værktøjet træffe datamodellen ubemærket. Bed det om at forklare den, og få den læst af en, der kan.
· At vente med hjælp, til en kunde er blevet ramt. Skiftet er langt billigere før.
· At gøre stifteren til eneste person, der kan ændre produktet. Det er en risiko, uanset om AI hjælper.
Det skal I kræve af den eksterne
- ☐ En ærlig vurdering af, hvilken fase I er i.
- ☐ Respekt for det, I selv har bygget.
- ☐ Besked, hvis det er for tidligt at bruge penge på teknisk ledelse.
- ☐ En kort opgørelse af, hvad næste fase kræver.
- ☐ Et råd om, hvordan stifteren bedst bruger værktøjerne fremover.
Kilder
- Lovable: Terms: brugerens ansvar for at vurdere AI-output. Læst november 2026.
- Cursor: Terms of Service: ansvar for at vurdere forslag. Læst november 2026.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ikke-teknisk stifter · No-code, low-code eller egen kode
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
