Teknisk partner vs leverandør: hvorfor relationen betyder mere end timeprisen

Teknisk partner vs leverandør handler om ansvar og initiativ: en leverandør leverer det du bestiller, mens en teknisk partner tager medansvar for at du bestiller det rigtige, og siger til før et problem bliver dyrt. Derfor siger timeprisen meget lidt om hvad samarbejdet ender med at koste dig. De dyreste timer er dem der bliver brugt på det forkerte.

Jeg sælger selv den slags løbende samarbejde, så læs med det forbehold. Jeg har forsøgt at være lige så tydelig om hvornår en leverandør er det bedste valg.

Den korte version

Min tommelfingerregel: Kan du beskrive opgaven så præcist at to udviklere ville bygge det samme, og har du selv nogen der kan vurdere resultatet, er en leverandør det rigtige valg. Kører din forretning på systemet hver dag, og har du ikke selv det tekniske overblik, har du brug for en partner.

Rollen hænger ikke sammen med en bestemt titel. En freelancer, et bureau og et softwarehus kan alle være begge dele. Vil du have overblik over hvem der laver hvad, så start med min oversigt over de forskellige typer udviklere.

Ansvar og initiativ: den reelle forskel

De fleste opgaver kan løses af begge typer. Forskellen viser sig i alt det der ikke står i opgavebeskrivelsen.

Ansvar: hvem der står med problemet

En leverandør har ansvaret for at leverancen svarer til bestillingen. Beder du om en eksport til Excel, får du en eksport til Excel. Det er ikke dårlig service, det er aftalen.

En partner spørger først hvad eksporten skal bruges til. Viser det sig at din bogholder bruger en time hver måned på at taste tallene ind i regnskabsprogrammet, er en integration måske den bedre investering. Eller også er eksporten fin, bare med de kolonner bogholderen faktisk bruger. Pointen er ikke at partneren altid foreslår noget større. Ofte er det modsatte tilfældet: et godt spørgsmål kan spare dig for en hel funktion.

Medansvar betyder også at partneren tager hånd om det når noget går galt, selv når årsagen ligger et sted ingen havde aftalt at holde øje med. Det kan være et udløbet certifikat, en fuld disk på serveren eller en betalingsudbyder der har ændret sit API.

Initiativ: hvem der siger til først

En leverandør venter på næste bestilling. En partner kigger fremad og siger til om ting du ikke vidste at du skulle tænke på.

Et konkret eksempel: Laravel giver hver hovedversion fejlrettelser i 18 måneder og sikkerhedsopdateringer i 2 år, ifølge Laravels egen supportpolitik. Kører din platform på Laravel 12, er fejlrettelserne allerede stoppet i august 2026, og sikkerhedsopdateringerne stopper i februar 2027. En leverandør opgraderer når du beder om det. En partner har sat opgraderingen på planen i god tid og fortalt dig hvad den koster, før det haster.

Initiativ kræver tid. Partneren skal kunne bruge timer på at tænke over dit system, også når der ikke ligger en konkret opgave. Er der ikke plads til det i aftalen, ender selv en god partner med at arbejde som leverandør.

Hvorfor timeprisen er det forkerte sted at starte

Timeprisen er let at sammenligne, så det er den de fleste kigger på. Men den samlede pris for et system består af meget mere end timer gange pris:

• Timer brugt på det forkerte: bliver der bygget en funktion ingen bruger, eller skal den laves om fordi ingen stillede de rigtige spørgsmål, betaler du to gange.
• Din egen tid: med en leverandør er det dig der skriver opgaverne, prioriterer, tester og holder øje med opdateringer og sikkerhed. Den tid står ikke på en faktura, men den koster stadig.
• Overdragelser: bruger du en ny leverandør til hver opgave, skal hver ny udvikler sætte sig ind i koden forfra, og det betaler du for hver gang.
• Det der ikke blev gjort: manglende opdateringer, en backup der aldrig er blevet testet, og teknisk gæld (genveje i koden der gør senere ændringer dyrere) koster ingenting i dag. De koster den dag de rammer.

Et regneeksempel med runde tal: En opgave tager 100 timer, og leverandøren er 20 % billigere i timen. Du sparer altså det der svarer til 20 timers arbejde. Skal 30 timer laves om fordi opgaven blev misforstået, eller bruger du selv en uge på at koordinere og teste, er besparelsen væk.

Det betyder ikke at den dyreste udvikler altid er den billigste. Det betyder at du skal sammenligne hvad det koster at nå målet, ikke hvad en time koster. Vil du se hvad et system typisk kræver efter lanceringen, har jeg samlet det i min guide til drift og vedligehold af webapps.

Sådan ser et langvarigt samarbejde ud hos mig

Et løbende samarbejde med mig handler om systemer som en virksomhed er afhængig af i det daglige, fx en kundeportal, en intern platform eller en SaaS. Forløbet følger stort set de samme trin:

1. Før større opgaver starter jeg med et betalt forprojekt til fast pris. Her finder du og jeg ud af hvad der skal bygges, hvad der kan vente, og hvad det koster. Overtager jeg et eksisterende system, anbefaler jeg at starte med en gennemgang af kode og drift, så du får et ærligt billede af tilstanden før du binder dig.
2. Koden er din fra første dag. Den ligger i dit eget repository (kodearkiv), og jeg anbefaler at hosting, domæner og tredjepartstjenester står i dit navn. Det er forudsætningen for et sundt partnerskab: du skal kunne gå når som helst.
3. Du taler direkte med den der skriver koden, ikke med en projektleder, og du får svar inden for én hverdag. Det gør det muligt at træffe beslutninger på et kort opkald i stedet for på et statusmøde.
4. Prioriteringen følger en fast rytme. Min anbefaling er et kort, fast møde, fx en gang om måneden. Her gennemgår du og jeg hvad der er lavet, hvad der står for tur, og om der er risici du skal kende til, fx en version der snart mister sikkerhedsopdateringer.
5. Vedligehold er en del af aftalen. Opdateringer, overvågning og backup bør ikke være noget du selv skal huske at bestille. Du og jeg aftaler fra start hvad den faste del dækker, og hvad der prissættes særskilt, så prisen er gennemsigtig.

En god partner gør sig ikke uundværlig

Beslutninger og opsætning skal skrives ned undervejs, så en anden udvikler kan tage over hvis det bliver nødvendigt. Det er også det bedste værn mod den største ulempe ved at vælge en freelancer som partner: at du er afhængig af én person. Hvordan den risiko vejer mod et bureaus, har jeg gennemgået i freelancer vs bureau: pris, risiko og kvalitet.

Hvornår en leverandør er det rigtige valg

Ikke alle opgaver kræver en partner, og du skal ikke betale for en hvis du ikke har brug for en. En leverandør er ofte det bedste valg når:

• Opgaven er afgrænset og veldefineret, fx en landingsside efter et færdigt design, en dataimport eller en integration med en klar specifikation.
• Du har selv teknisk ledelse. Har du en CTO, en tech lead eller et internt team der træffer de tekniske beslutninger og bare mangler hænder, vil en partner der blander sig i arkitekturen tit være i vejen.
• Det er en engangsopgave. Skal løsningen ikke drives og videreudvikles bagefter, er der ikke meget at være partner om.
• Du har brug for en specialist til én ting, fx en penetrationstest eller en designopgave.

Der er også situationer hvor du har brug for mere end en partner kan give. Skal nogen eje den tekniske strategi på ledelsesniveau, deltage i ansættelser og stå over for investorer, er det en anden rolle. Den kan du læse om i mit indlæg om hvad en fractional CTO laver. Og partnerrollen kræver erfaring: en junior kan være en dygtig leverandør, men har sjældent overblikket til at se risici før de opstår. Forskellen har jeg beskrevet i junior, medior eller senior udvikler.

Til sidst om mig selv: Har du brug for flere udviklere på fuld tid, eller er dit system bygget i en teknologi uden for min stak (Laravel, PHP og JavaScript), er jeg ikke den rette partner. Så er du bedre stillet med et team eller en specialist i den teknologi.

Sådan tester du om en udvikler er en partner

Det er let at kalde sig partner. Det er sværere at opføre sig som en. Med de her fem trin kan du teste det før du binder dig:

1. Beskriv problemet, ikke løsningen. Fortæl hvad du vil opnå, og læg mærke til om udvikleren spørger ind til din forretning eller går direkte til timer og pris.
2. Spørg hvad de ville gøre anderledes. En partner har en mening og siger den, også når det betyder en mindre opgave og en mindre faktura.
3. Spørg ind til de kedelige ting. Hvordan håndteres opdateringer, backup, overvågning og dokumentation? Svaret viser om udvikleren tænker i drift eller kun i leverancer.
4. Start med en lille, betalt opgave. Fx en gennemgang af dit nuværende system eller en afgrænset forbedring. Se hvordan udvikleren kommunikerer, og om du får mere med hjem end det du bad om: en risiko du ikke kendte, eller et forslag til at gøre noget enklere.
5. Tjek hvem der ejer hvad. Koden, adgangene og dokumentationen skal være dine. Tøver udvikleren med at give dig det, er det et klart advarselstegn.

Næste skridt: har du brug for en partner?

Kan du sætte kryds ved de fleste, er det tid til at kigge efter en partner frem for en leverandør. Kan du kun sætte kryds ved et enkelt, er en leverandør med en klar opgavebeskrivelse sandsynligvis nok. På siden om vedligehold og videreudvikling kan du se hvordan jeg griber et løbende samarbejde an.

Ofte stillede spørgsmål

Hvad koster en teknisk partner om måneden?+

Det afhænger af systemets størrelse og hvor meget der skal udvikles. Prisen består typisk af en fast månedlig del til vedligehold, overvågning og sparring plus timer til videreudvikling efter behov. Bed om at få begge dele specificeret, så du kan se præcis hvad den faste del dækker, og hvornår der kommer en ekstra regning. Sammenlign derefter med hvad det koster dig selv at holde styr på det samme.

Hvad er forskellen på en teknisk partner og en teknisk medstifter?+

En teknisk medstifter ejer en del af virksomheden og deler risikoen, mens en teknisk partner bliver betalt for sit arbejde. Medstifteren er med i alle beslutninger og bliver typisk i mange år. Partneren kan være lige så engageret i dit system, men har ingen ejerandel og arbejder ofte for flere kunder. Skal nogen bygge og vedligeholde, er en partner som regel nok. Skal nogen være med til at bygge selve forretningen, er det en medstifter du leder efter.

Hvor lang binding bør en aftale med en teknisk partner have?+

Jeg anbefaler en løbende aftale med kort opsigelse, fx en til tre måneder. Et godt partnerskab skal holdes sammen af at det fungerer, ikke af en lang kontrakt. Sørg for at aftalen beskriver hvordan en overdragelse foregår, og at koden og adgangene allerede er dine. Så er det let at stoppe hvis samarbejdet ikke virker, og det giver tryghed for begge parter.

Hvad sker der hvis min tekniske partner bliver syg eller holder ferie?+

Det skal I aftale før I starter. Spørg hvordan akutte fejl bliver håndteret i ferier og ved sygdom, og om der er en kollega der kan træde til. Uanset svaret bør koden ligge i dit eget repository med opdateret dokumentation, så en anden udvikler kan overtage uden at starte forfra. Det er især vigtigt hvis din partner er en freelancer.