Sådan forhandler du med en udvikler uden at ende med dårligere kvalitet

Den bedste måde at forhandle med en udvikler på er at lade timeprisen være og i stedet forhandle om det der bestemmer den samlede regning: hvor meget der skal bygges, i hvilken rækkefølge og på hvilke vilkår. Pres på timeprisen giver sjældent et billigere projekt, men ofte et dårligere, fordi besparelsen bliver hentet et sted du ikke kan se. Omfang, faseopdeling, betalingsvilkår og din egen indsats er de håndtag der faktisk flytter prisen.

Jeg er selv freelanceudvikler og sidder altså på den anden side af bordet, så læs med det forbehold. Det følgende er det jeg selv ville gøre som køber, og det der typisk giver en udvikler plads til at sænke prisen uden at sænke niveauet.

Den korte version: hvad flytter prisen?

Tabellen er en grov sortering. Har du endnu ikke fundet en udvikler at forhandle med, så start med min guide til at hyre en udvikler. Resten af indlægget går ud fra at du har et tilbud foran dig, og at det er højere end du havde håbet.

Hvorfor pres på timeprisen sjældent gør projektet billigere

Prisen på et udviklingsprojekt er timepris gange timer. De fleste forhandler kun om den første faktor, men den anden er næsten altid den største og mest usikre.

Tag et tænkt regneeksempel. Et projekt er estimeret til 200 timer til 900 kr. i timen, altså 180.000 kr. ekskl. moms. Får du 10 % rabat på timeprisen, sparer du 18.000 kr. Udskyder du i stedet to funktioner der tilsammen udgør 40 timer, sparer du 36.000 kr., og ingen arbejder billigere end før. Løber projektet bagefter 15 % over estimatet, er hele timeprisrabatten væk igen.

Når du presser timeprisen, sker der typisk en af tre ting:

• Udvikleren siger nej. Det er det bedste udfald, for så ved du hvor du står.
• Udvikleren siger ja og henter det et andet sted. Estimatet vokser lidt, der bliver skrevet færre test, eller afklaringen bliver kortere. Du kan ikke se det i tilbuddet, men du mærker det om et år.
• Udvikleren siger ja og prioriterer dig lavere. En freelancer med flere kunder bruger sin bedste tid på dem der betaler fuld pris.

Det betyder ikke at timeprisen er hellig. Ligger den markant over det normale niveau for den type udvikler, er det rimeligt at spørge ind til den. Vil du vide hvad der er normalt, har jeg samlet typiske timepriser for freelanceudviklere i Danmark.

Sådan forhandler du med en udvikler i seks trin

Trinene står i den rækkefølge jeg ville tage dem. De første tre flytter typisk mest.

1. Sig dit budget højt

Mange holder budgettet hemmeligt af frygt for at udvikleren bare fylder det ud. I praksis gør hemmeligholdelsen mere skade. Udvikleren gætter, laver et tilbud på hele ønskelisten, og I bruger to runder på at finde ud af at I er langt fra hinanden.

Siger du "vi har 150.000 kr. til første version", kan en seriøs udvikler svare på det spørgsmål du egentlig har: hvad kan jeg få for de penge? Det er en langt mere brugbar samtale end "kan du gøre det billigere?". Rammer et tilbud præcis dit budget, så spørg hvad der er valgt fra. Et ærligt svar kommer altid med en liste over fravalg.

2. Skær i omfanget, ikke i kvaliteten

Omfanget er det stærkeste håndtag du har. Gå ønskelisten igennem sammen med udvikleren, og sortér hver funktion i tre bunker: skal med før lancering, skal med senere, og rart at have.

De dyre ting er sjældent dem du forventer. Ofte er det de små ønsker med mange undtagelser: flere brugerroller med forskellige rettigheder, import fra gamle systemer, avancerede filtre, rapporter der skal kunne eksporteres til alle formater, eller et login der skal virke på tre forskellige måder. Spørg udvikleren direkte: "Hvilke tre ting på listen koster mest i forhold til hvad de giver?" Det spørgsmål sparer ofte mere end nogen rabat.

Beskriv også problemet frem for løsningen. "Kunderne skal kunne se deres ordrer" kan løses på mange måder, og nogle af dem er langt billigere end det skærmbillede du har tegnet. Har du brug for en struktur til det, så brug min skabelon til en projektbeskrivelse der giver brugbare tilbud.

3. Del projektet op i faser

Et tilbud på et helt projekt indeholder næsten altid et risikotillæg. Udvikleren ved ikke alt endnu og lægger derfor luft ind, især ved fast pris. Jo mere usikkerhed, jo mere luft.

Den bedste måde at fjerne luften på er at dele arbejdet op:

1. Forprojekt: et kort, betalt forløb hvor I afklarer krav, tekniske valg og risici. Resultatet er en plan og en pris på næste fase.
2. Første version: det mindste der kan bruges af rigtige brugere.
3. Næste faser: prissat hver for sig når I ved mere.

Jeg starter selv større projekter med et betalt forprojekt til fast pris, netop fordi det gør resten af prisen mere præcis. For dig betyder det at du kun binder dig til det næste skridt og kan stoppe eller skifte retning uden at have betalt for et helt system. Det kan føles som en ekstra udgift, men pengene går til at fjerne den usikkerhed du ellers betaler for gennem et risikotillæg.

4. Brug betalingsvilkår som forhandlingskort

Betalingsvilkår koster dig ofte meget lidt, men betyder meget for en freelancer. En udvikler der venter 60 dage på sine penge, finansierer i praksis dit projekt imens. Den risiko bliver prissat, enten i timeprisen eller i lysten til at tage opgaven.

Det kan du bruge:

• Tilbyd en forudbetaling ved opstart, fx en del af første fase.
• Betal efter delleverancer i stedet for ét stort beløb til sidst.
• Betal hurtigt. En betalingsfrist på 8 dage i stedet for 30 er en reel fordel for en enkeltmandsvirksomhed.
• Bind dig til et fast antal timer om måneden over en længere periode. Forudsigelig indtjening er noget en freelancer kan være villig til at give en bedre pris for.

Går du den anden vej, bliver projektet dyrere. Lange betalingsfrister og betaling først når alt er godkendt, flytter risiko over på udvikleren. Mellem virksomheder må en aftalt betalingsfrist som udgangspunkt højst være 30 dage. En længere frist kræver at leverandøren udtrykkeligt har godkendt den, og at den ikke er urimelig over for leverandøren, jf. rentelovens § 3 a. En udvikler der accepterer 90 dage, har med andre ord gjort dig en tjeneste, og den er sjældent gratis.

5. Byt tid for pris

Hastværk er dyrt. En hård tidsfrist betyder at udvikleren skal rydde kalenderen, sige nej til andre opgaver og måske arbejde om aftenen. Har du ikke en reel tidsfrist, så sig det. En udvikler der kan lægge dit projekt ind hvor der er plads, uden at svigte andre kunder, har god grund til at give en lavere pris.

Vær også ærlig over for dig selv. En lancering der "skal" ske før sommerferien, men lige så godt kunne ske i september, koster måske mere end den er værd.

6. Tag selv de opgaver du kan løse

En del af timerne i et projekt går ikke til kode, men til at vente, spørge og rette. Dem kan du skære ned:

• Lever tekster, billeder og testdata færdige og til tiden.
• Udpeg én kontaktperson der kan træffe beslutninger inden for et døgn eller to.
• Test løbende, og giv samlet feedback i stedet for ti mails.
• Saml ændringsønsker, og tag dem i én runde.

Det lyder af lidt, men efter min erfaring er langsomme svar og uklare beslutninger blandt de mest almindelige grunde til at et estimat skrider. Spørg udvikleren hvilke opgaver du kan tage, og hvad det betyder for prisen.

Det du aldrig skal forhandle væk

Nogle besparelser ser fine ud i tilbuddet og bliver dyre bagefter. Sænker en udvikler prisen uden at noget forsvinder fra omfanget, så spørg hvad der er forsvundet. Svaret er ofte et af disse punkter:

• Automatiske test af de vigtigste funktioner. Uden dem bliver hver fremtidig ændring langsommere og mere risikabel.
• Sikkerhed og opdateringer: håndtering af adgangskoder, rettigheder, backup og opdatering af framework og pakker.
• Dokumentation og overdragelse, så en anden udvikler kan overtage hvis det bliver nødvendigt.
• Dit ejerskab af koden og adgangen til repository (kodearkiv), hosting og domæner. Hos mig ejer kunden koden fra første dag, og det bør være standard hos alle du hyrer. Tjek at det står i aftalen, fx med min tjekliste til kontrakten med en freelanceudvikler.
• En realistisk buffer. Et estimat uden luft er ikke billigere, bare mere optimistisk.

Hvornår du skal stoppe med at forhandle

Min tommelfingerregel er at forhandling kan lukke et hul på 10-20 %. Er afstanden mellem dit budget og tilbuddene langt større, er udvikleren sjældent problemet. Så er projektet for stort til budgettet, og løsningen er en mindre første version, en længere tidsplan eller en anden type løsning.

Her er tre situationer hvor jeg ville stoppe:

• Udvikleren kan ikke forklare sit estimat. Kan ingen fortælle dig hvad timerne går til, kan du heller ikke forhandle på et oplyst grundlag. Mine spørgsmål du kan stille en udvikler før du hyrer hjælper dig med at få det frem.
• Prisen er det eneste I taler om. Så har du endnu ikke fundet ud af hvad du køber.
• I er uenige om kvalitet. Vil du skære test og dokumentation væk, og vil udvikleren ikke, så lyt til udvikleren, eller find en der passer til det niveau du reelt har brug for.

En ærlig indrømmelse fra min side: er opgaven lille, velafgrænset og ikke forretningskritisk, kan en billigere udvikler eller et færdigt værktøj være det rigtige valg. Det gælder fx en enkel landingsside eller en engangsimport af data. Du behøver ikke en erfaren freelancer til alt, og det er bedre at vælge billigt med åbne øjne end at presse en dyr udvikler ned i en pris der ikke holder.

Næste skridt: forbered forhandlingen

Gå listen igennem før du sætter dig til forhandlingsbordet. Den tager en halv time og kan spare dig mere end en rabat.

Vil du se hvordan jeg selv griber det an, kan du læse om mine priser og hvordan jeg prissætter projekter.

Ofte stillede spørgsmål

Er det uhøfligt at bede en freelanceudvikler om rabat?+

Nej, det er helt almindeligt at spørge. Det der virker bedst, er at spørge hvad der skal til for at nå et bestemt beløb, frem for bare at bede om en lavere timepris. Så kan udvikleren foreslå fravalg, faser eller andre vilkår, og I ender med en pris der holder, i stedet for en rabat der bliver hentet hjem et andet sted.

Kan man forhandle en fast pris ned?+

Ja, men sjældent ved at presse tallet direkte. En fast pris indeholder et tillæg for usikkerhed, og det tillæg falder når usikkerheden gør. En grundigere projektbeskrivelse, et forprojekt eller en mindre første fase giver udvikleren mindre at gardere sig imod, og så kan prisen komme ned uden at kvaliteten skal betale for det.

Skal jeg bruge et billigere tilbud som forhandlingskort?+

Det kan du godt, men vær konkret. Fortæl hvad det andet tilbud indeholder, og spørg hvor forskellen ligger. Ofte dækker to tilbud ikke det samme: det ene har test, dokumentation eller projektledelse med, det andet ikke. Bruger du kun beløbet som løftestang, risikerer du at sammenligne to forskellige projekter.

Hvornår i forløbet er det bedst at forhandle?+

Før du skriver under, og mens omfanget stadig kan formes. Når aftalen er indgået, er det svært at fjerne noget uden at genforhandle hele planen, og nye ønsker undervejs koster typisk mere end hvis de var med fra start. Får du lavet et forprojekt, er det bedste tidspunkt lige efter: så er kravene afklaret, estimatet er mere præcist, og du kan vælge indholdet af første fase på et oplyst grundlag.