En ikke-teknisk stifter behøver ikke lære at programmere for at få et produkt bygget. Tre beslutninger skal på plads, før nogen skriver kode: hvad første version skal afprøve, hvem der bygger den, og hvem der ejer resultatet. Programmeringssprog, cloudplatform og arkitektur kan vente, til en med erfaring sidder med ved bordet. Her er rækkefølgen, og det lille stykke teknik, I selv skal kunne følge med i.
Første beslutning: hvad skal første version afprøve?
Mange stiftere begynder med en liste over funktioner. Begynd i stedet med den antagelse, forretningen hviler på. Vil kunderne betale for at få opgaven løst? Vil de skifte deres nuværende arbejdsgang ud? Kan I overhovedet få adgang til de data, løsningen kræver?
Skriv antagelsen ned i én sætning. Den afgør, hvor lidt der kan bygges, og den giver jer et sprog at tale med udviklere i. Forskellen på en prototype, et proof of concept og en MVP, altså den mindste version, der kan bruges af rigtige kunder, er forklaret under omfanget af første version.
Nogle antagelser kan afprøves helt uden kode, fx med samtaler, en tegnet brugerflade eller en manuel udgave af tjenesten, hvor I selv udfører arbejdet bag kulissen. Så meget bedre, for så bruger I udviklingstiden på det, der stadig er usikkert.
Anden beslutning: hvem bygger?
Der er fire veje: en teknisk medstifter, en første ansat udvikler, en freelancer eller et bureau. Hver af dem kræver noget forskelligt af jer i styring, og de efterlader viden forskellige steder, når samarbejdet slutter. Sammenligningen står i freelancer, bureau eller eget team, og valget mellem en medstifter og en ekstern leder i teknisk medstifter eller ekstern CTO.
Tre spørgsmål afklarer det meste:
- Er produktet selve forretningen i mange år frem, eller er det en støtte til en anden forretning?
- Hvor meget tid kan I selv lægge i at beslutte og teste hver uge?
- Hvem kan vurdere det, der bliver leveret, når I ikke selv kan læse koden?
Er svaret på det sidste “ingen”, er det hullet, I skal lukke først. Det kan gøres med en erfaren person, der hjælper med valget af dem, der bygger, og som læser med på de første leverancer. Se også, om no-code, low-code eller egen kode kan bære jer et stykke på vejen.
Tredje beslutning: hvem ejer det, der bliver bygget?
Denne beslutning koster næsten intet at træffe nu og meget at rette senere. Fra første dag bør virksomheden selv stå som ejer af domænet, cloudkontoen, kontoen i app-butikkerne og det repository, altså det kodearkiv, hvor koden ligger. Udviklerne får adgang gennem jeres konti, så I ikke står og beder om adgang til jeres eget produkt.
Rettighederne til koden er en aftale, og den skal være på plads, før arbejdet starter. Det tekniske ejerskab er beskrevet under kode og konti, og de konkrete aftaletekster er et spørgsmål til advokat.
Det, der kan vente
Tre ting fylder ofte tidligt og kan trygt udskydes:
- Det endelige teknologivalg. Spørg, hvorfor dem, der bygger, foreslår det, de gør, og lad det hvile. Vælg kendt teknologi, som flere kan overtage.
- Skalering til mange kunder. Første version skal tåle de første kunder.
- Fuld automatisering. Det, der sker sjældent, kan klares i hånden i starten.
Enkelte ting bør til gengæld med fra begyndelsen, selv om de ikke er synlige: backup af data, login, der er bygget ordentligt, og adskillelse af kundernes data. De er dyre at sætte ind bagefter.
Det, I selv skal forstå af teknikken
Fem begreber rækker langt, når I skal følge arbejdet:
- Repository: kodearkivet, der viser hver ændring, og hvem der lavede den.
- Testmiljø: en kopi af produktet, hvor nye ting afprøves uden at røre kunderne.
- Produktionsmiljø: den udgave, kunderne bruger.
- Integration: forbindelsen til et andet system, fx betaling eller bogføring.
- Teknisk gæld: hurtige løsninger, der senere skal betales tilbage med ekstra arbejde.
Med dem kan I stille de spørgsmål, der er beskrevet i sådan følger I fremdriften.
Hvornår en ekstern CTO giver mening
En fractional CTO er en erfaren teknisk leder på deltid. For en ikke-teknisk stifter er rollen mest værdifuld omkring de tre beslutninger ovenfor og de første leverancer. Har I endnu ingen idé om, hvem kunderne er, er det for tidligt, og tiden er bedre brugt på samtaler med dem. Det står uddybet i er det for tidligt med en CTO?.
Hvis I er klar til at tale om forløbet, begynder det hos Nielco IT med en gennemgang af, hvor I står, og derefter en fast aftale hver måned med et aftalt antal timer. Opgaven omfatter styring af leverandører, valg af teknologi og ledelse af teamet, og koden skrives af jeres udviklere. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At vælge teknologi først · lad produktets antagelse styre valget.
- At lade udvikleren oprette kontiene i eget navn · det er jeres virksomheds aktiver.
- At underskrive et tilbud, ingen uden for tilbudsgiveren har læst · få en anden til at se det igennem.
Det skal I kræve af den eksterne
- ☐ En forklaring af hvert teknisk valg, som I kan gengive for en kunde.
- ☐ En liste over de beslutninger, der kan vente, og dem, der ikke kan.
- ☐ Et overblik over konti og adgange i virksomhedens navn.
- ☐ Hjælp til at vurdere dem, der skal bygge, uden binding til en bestemt leverandør.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Sådan finder I en teknisk medstifter i Danmark · Første version er leveret: hvad nu?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
