Vælg kendt teknologi, som jeres udviklere kan i forvejen, og som andre udviklere kan overtage. Brug tiden på de få beslutninger, der er dyre at ændre senere: datamodellen, adskillelsen mellem kunder, login og hvor data ligger. Næsten alt andet kan skiftes, når produktet har lært jer noget. En MVP, kort for minimum viable product, er den mindste version, der kan svare på, om kunderne vil have produktet. Den skal være lille og må gerne være ufærdig, men fundamentet under den skal kunne bære det næste skridt.
Teknologistak forklaret kort
En teknologistak, på engelsk tech stack, er summen af de byggeklodser, produktet består af. Typisk et sprog og et rammeværk til det, brugeren ser, et sprog og et rammeværk på serveren, en database og et sted at køre det hele. Der findes mange gode valg, og forskellene har sjældent betydning for, om en ny virksomhed klarer sig. Stifteren, der bruger måneder på diskussionen, spilder tid på det, kunderne aldrig ser.
Kendt frem for spændende
Nye teknologier er sjove, og udviklere kan have en personlig interesse i at prøve dem. Hold den interesse op mod fire spørgsmål:
- Kan teamet det allerede? Den teknologi, jeres folk kender, giver det hurtigste første år.
- Kan vi finde andre, der kan det? Hvis eneste udvikler stopper, skal der kunne findes en afløser.
- Er den bredt brugt og vedligeholdt? Der skal være et aktivt miljø, løbende sikkerhedsrettelser og gode biblioteker.
- Kan en AI-kodeassistent hjælpe godt i den? Udbredte teknologier giver bedre hjælp, og det betyder noget i dag.
Tegnet på et dårligt valg er, når begrundelsen handler om, hvad der er moderne, eller hvad store techvirksomheder bruger. De har andre problemer end I har. Er argumentet “det skal kunne skalere til millioner af brugere”, så spørg, hvor mange brugere produktet skal have det næste år. Det samme gælder forslag om mange små tjenester frem for ét samlet system, se monolit eller microservices.
De få valg, der er svære at ændre
Fire beslutninger bør have jeres opmærksomhed, også i en lille første version.
Datamodellen. Hvordan produktets begreber hænger sammen: kunde, bruger, ordre, abonnement. Kode kan skrives om. Data med en forkert struktur, som kunderne har fyldt op, er langt sværere at ændre. Tænk især på, om en bruger kan høre til flere virksomheder, for det spørgsmål dukker næsten altid op.
Kundeadskillelse. Hvordan én kundes data holdes adskilt fra andres. Det valg er uddybet i artiklen om delt system og egne installationer.
Login og identitet. Køb det i stedet for at bygge det. Store kunder vil senere kræve login gennem deres eget system, og det er lettere, når grundlaget er standard, se byg, køb eller integrer.
Hvor data ligger. Sælger I til virksomheder i Danmark, kommer spørgsmålet tidligt. Læs om valget i cloud og hosting til SaaS.
Flere detaljer står i artiklen om de dyre arkitekturbeslutninger.
De valg, der er lette at ændre
Giv jer selv lov til at træffe disse hurtigt: designsystem, værktøjer til test, udviklernes editor, overvågning, placering hos en bestemt udbyder, så længe I holder jer til almindelige byggeklodser. Beslut, skriv ned hvorfor, og kom videre. En kort beslutningsnote er nok, og formatet står i skriv de tekniske beslutninger ned.
Hvordan MVP’en undgår at blive smidt væk
Første version bliver smidt væk, når den er bygget, så ingen kan ændre den. Det skyldes sjældent det valgte sprog. Oftere er årsagen manglende struktur:
- Koden ligger i et versionsstyret lager, et repository, som virksomheden ejer.
- Der er et par automatiske test på det vigtigste flow.
- Udgivelse af en ny version er en rutine og ikke en begivenhed.
- Nøgler ligger uden for koden.
- Beslutningerne er skrevet ned.
Det tager få dage at etablere, og det er forskellen på et produkt, der kan vokse, og en demo. Hvad der hører med i første version, står i hvad der skal med, og hvad der skal ud.
Omvendt er det i orden at bygge en prototype, der er beregnet til at blive smidt ud, så længe alle ved det. Faren er prototypen, der får lov at leve videre, fordi den virker. Er den bygget med AI, se fra prototype til produkt.
Spørgsmål, stifteren kan stille uden at kunne kode
Bed den, der foreslår teknologien, om at svare på:
- Hvorfor dette valg, og hvad fravalgte I?
- Hvor mange andre udviklere kan overtage det her i landet?
- Hvad bliver dyrt at ændre om et år?
- Hvad er det værste, der kan ske, hvis valget viser sig forkert?
- Passer forslaget til netop jeres kunder, eller er det det, I altid bruger?
Det sidste spørgsmål er særligt nyttigt over for udviklingshuse. De vælger ofte det, de selv kan levere, og det kan være helt fint, så længe I ved, at det er grunden.
Kan I ikke vurdere svarene, er det en af de opgaver, en fractional CTO kan løse i et afgrænset forløb. Teknologivalg hører til det, Nielco IT påtager sig i rollen, sammen med ledelse, leverandører og team. Kodearbejdet bliver hos 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 for at imponere. Kunderne ser det ikke, og udviklerne kan blive færre at vælge imellem.
· At bygge til en skala, I ikke har. Løs den slags, når målingerne viser behovet.
· At bruge måneder på valget. En hurtig, begrundet beslutning slår en perfekt, der kommer for sent.
· At lade den eneste udvikler vælge noget, kun vedkommende kan. Så køber I en ny nøglepersonrisiko med.
Det skal I kræve af den eksterne
- ☐ En kort begrundelse for hvert stort valg, skrevet uden fagord.
- ☐ En liste over de beslutninger, der er svære at ændre.
- ☐ Anbefalinger uden bindinger til teknologileverandører.
- ☐ En vurdering af, hvor let det er at finde udviklere til valget.
- ☐ Beslutningsnoter, teamet selv kan arbejde videre med.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Freelancer, bureau eller eget team · App, webapp eller begge?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
