Før I henter tilbud på en app, bør I have to sider klar, der beskriver brugerne, det vigtigste forløb i appen, de data, der indgår, de systemer, appen skal tale med, og det, der bevidst skal vente. Med den beskrivelse får I tilbud, der kan sammenlignes, og I undgår, at hvert udviklingshus gætter på noget forskelligt. En lang kravspecifikation er sjældent nødvendig. Hvad I skal have, er en klar beskrivelse af problemet, så leverandøren selv kan foreslå løsningen.
Hvorfor to sider er bedre end tyve
En kravspecifikation er en detaljeret liste over, hvad systemet skal kunne. Den giver tryghed, men i første version ved I endnu ikke nok til at skrive den. Lange lister låser jer til jeres gæt, og en leverandør kan levere det hele, uden at produktet løser noget for brugeren.
To sider tvinger jer til at vælge. De kan læses af en travl udvikler, og det bliver tydeligt, hvor uklarhederne ligger. Bliver der stillet spørgsmål, I ikke kan besvare, har I fundet noget, I skal afklare, inden I bruger penge på det.
De fem afsnit
1. Problemet og brugerne. Hvem bruger appen, og hvad prøver de at få gjort? Beskriv en eller to typer brugere konkret. “Håndværkeren, der skal skrive tid og materialer ind fra bilen” giver mere end “brugere i byggebranchen”.
2. Kerneflowet. Beskriv det vigtigste forløb trin for trin, sådan som brugeren oplever det. Ét forløb er nok. Tegn gerne skærmbilleder i hånden eller i et enkelt værktøj. Kerneflowet er det forløb, der skal virke, for at produktet har en grund til at findes.
3. Data. Hvilke oplysninger indgår? Hvem må se hvad? Er der personoplysninger eller oplysninger om helbred, børn eller betaling? Hvor kommer data fra, og hvad skal de bruges til bagefter?
4. Integrationer. En integration er en forbindelse til et andet system. Skal appen tale med bogføring, betaling, kort, login med MitID eller kundens eget system? Skriv, hvad der skal ske, og om I ved, at den anden part tillader det. Integrationer er ofte der, hvor projekter bliver større end ventet.
5. Det, der skal vente. Hvad er bevidst sprunget over? Listen er lige så vigtig som resten, for den forhindrer, at omfanget vokser af sig selv. Hjælp til at skære finder I i artiklen om første version.
Oplysninger, der gør tilbuddene sammenlignelige
Tilføj en kort ramme, som alle tilbudsgivere får i samme ordlyd:
- Skal det være en app fra app-butikkerne, en webapp eller begge? Hvis I er i tvivl, så skriv det, og bed om en anbefaling, se app, webapp eller begge?.
- Hvor mange brugere regner I med det første år, og er der travle perioder?
- Hvornår skal første version bruges af rigtige brugere, og hvorfor netop da?
- Hvem hos jer tager beslutninger, tester og svarer på spørgsmål, og hvor meget tid har de?
- Hvem skal drive og vedligeholde appen, når den er leveret?
Bed samtidig tilbudsgiverne svare på det samme: hvad der er med, hvad der ikke er med, hvilke antagelser de har gjort, hvem der arbejder på opgaven, og hvordan ændringer håndteres. Det, tilbudsgivere ofte udelader, er gennemgået i en second opinion på tilbuddet.
Et tænkt eksempel
En stifter vil lave en app til booking af trænere. Den første beskrivelse fylder en halv side med funktioner: chat, profiler, anmeldelser, betaling, kalender, notifikationer og tilbud. Efter en gennemskrivning står der i stedet: en træner lægger ledige tider ud, en kunde booker og betaler, begge får besked, og træneren får en liste over dagens bookinger. Chat og anmeldelser står under “skal vente”. Betaling sker via en færdig betalingsløsning. Nu kan tre leverandører regne på det samme. Eksemplet er tænkt.
Fejl, der koster mest senere
- At beskrive løsningen frem for behovet. Skriv, hvad brugeren skal opnå. Så kan en dygtig leverandør foreslå noget enklere.
- At glemme det, der ikke kan ses. Administration, support, rettigheder, sletning af data og opdateringer hører med.
- At spørge for mange. Vælg en håndfuld, der er relevante, og giv dem ordentlig tid.
- At tage ejerskab for givet. Skriv fra starten, at virksomheden skal eje kode, konti og domæne, se ejerskab til kode og konti.
Sådan bruger I beskrivelsen bagefter
De to sider stopper ikke med tilbuddet. De bliver grundlag for aftalen, for prioriteringerne undervejs og for testen af det, der bliver leveret. Sæt en dato på, og opdatér dem, når I ændrer noget, så I og leverandøren har det samme billede.
Har I ikke selv teknisk erfaring, er det her et godt sted at bruge nogle få timer på en fractional CTO, det vil sige en teknisk leder med erfaring, der arbejder på deltid. Beskrivelsen bliver skarpere, og I får en at spørge, når tilbuddene kommer ind.
Det skal I lade være med
- At sende en mail med “hvad koster en app?” · I får et gæt tilbage.
- At lade den første leverandør skrive beskrivelsen · så er tilbuddene ikke længere sammenlignelige.
- At lade “det, der skal vente” stå tom · omfanget vokser uden den liste.
Det skal I kræve af den eksterne
- ☐ Kritiske spørgsmål til jeres beskrivelse, også de ubehagelige.
- ☐ En kort liste over de tekniske antagelser, tilbudsgiverne skal tage stilling til.
- ☐ Ingen binding til de leverandører, der skal byde.
- ☐ Hjælp til at læse svarene, når tilbuddene ligger på bordet.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Ikke-teknisk stifter: sådan kommer produktet i gang · De tekniske krav, der skal med i udviklingsaftalen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
