Ekstern CTO
Bygge eller købe software til webshoppen?
Skal webshoppen bygge eget system eller købe en færdig løsning til søgning, priser, ERP-integration eller konfigurator? Kriterier, TCO-skabelon og vedligeholdelsesplan.
- Forfatter
- Kasper Stück
- Dato
- Læsetid
- 8 min
- Niveau
- Mellem
Du står med et konkret behov – bedre søgning, kundespecifikke priser, en produktkonfigurator eller en ERP-integration – og skal beslutte, om du køber en færdig løsning eller får noget bygget. Kort svar: Køb det, mange andre også har brug for. Byg det, der adskiller dig fra konkurrenterne, men kun hvis du har en plan for, hvem der vedligeholder det bagefter.
Denne artikel handler om de større systemvalg. Er det en mindre funktion i Shopify-temaet, så læs Shopify-app eller specialudvikling. Gælder valget hele platformen, så læs SaaS eller specialudviklet webshop.
Fem spørgsmål, der afgør det meste
| Spørgsmål | Peger mod køb | Peger mod at bygge |
|---|---|---|
| Adskiller funktionen dig fra konkurrenterne? | Nej, alle har behovet | Ja, det er en del af jeres fordel |
| Findes der en løsning, der dækker de vigtigste krav? | Ja | Nej, efter grundig undersøgelse |
| Ændrer regler eller sikkerhedskrav sig løbende? | Ja, for eksempel betaling og moms | Nej |
| Har du nogen til at vedligeholde koden? | Nej | Ja, med en plan for udskiftning |
| Hvor hurtigt skal det virke? | Inden for uger | Der er tid til at specificere og teste |
Hvis svarene peger i forskellige retninger, er det typisk vedligeholdelsen, der skal veje tungest.
Hvornår det giver mening at købe
Når behovet er almindeligt. Betaling, e-mailmarkedsføring, fragt, anmeldelser, søgning og kundeservice har tusindvis af webshops brug for. Leverandørerne har bygget og testet løsningerne på langt flere butikker, end du kan teste din egen på.
Når regler og sikkerhed ændrer sig. En betalingsløsning skal følge kortreglerne, stærk kundeautentifikation og sikkerhedsstandarder som PCI DSS. Det er ikke noget, en webshop bør bygge selv.
Når du har travlt. Hvis du vil teste, om en funktion overhovedet skaber værdi, er en færdig løsning den billigste måde at finde ud af det på.
Når du mangler teknisk kapacitet. Specialudvikling uden nogen, der kan stille krav og tage imod leverancen, ender ofte med et system, der ikke passer, ikke er dokumenteret og kun kan vedligeholdes af én leverandør.
Hvornår det giver mening at bygge
Når funktionen er jeres fordel. Det kan være en prislogik, der afspejler jeres aftaler med kunderne, eller en konfigurator med regler, som ingen standardløsning kan udtrykke. Hvis konkurrenterne kan få det samme ved at installere en app, er det ikke en fordel.
Når ingen løsning dækker kravene. Vær kritisk her. Undersøg flere alternativer, tal med leverandørerne om tilpasning, og spørg, om kravet er en reel forretningsregel eller en vane. Ofte kan en standardløsning med en afgrænset tilpasning dække behovet.
Når du kan vedligeholde det. Det er det vigtigste punkt. Specialudviklet kode skal opdateres, når de systemer, den taler med, ændrer sig, og den skal kunne overtages af en anden udvikler.
TCO: Sammenlign det samme over samme periode
Total Cost of Ownership er den samlede pris over hele levetiden. Brug skabelonen til begge muligheder over mindst tre år:
| Omkostning | Køb | Byg |
|---|---|---|
| Engangsomkostning | Implementering og opsætning | Specifikation, udvikling og test |
| Integration | Til webshop, ERP og andre systemer | Til webshop, ERP og andre systemer |
| Løbende licens eller drift | Abonnement, ofte efter forbrug | Hosting og overvågning |
| Vedligeholdelse | Tilpasninger og opdatering af integrationer | Fejlrettelser, opdateringer og sikkerhed |
| Intern tid | Oplæring og administration | Krav, test og opfølgning |
| Exit | Eksport af data og skift af leverandør | Overdragelse til en ny udvikler |
Brug leverandørernes aktuelle priser ved din volumen, og bed om tilbud på udvikling med en beskrivelse af, hvad der er med. Lav både et forventet og et dyrere scenarie. Udviklingsprojekter bliver oftere dyrere end billigere, og licenser stiger ofte med volumen.
Vedligeholdelse er den skjulte post
Specialudviklet kode har brug for:
- fejlrettelser, når noget går galt.
- opdateringer, når API’er og afhængigheder ændrer sig.
- sikkerhedsopdateringer.
- dokumentation, så en anden udvikler kan overtage.
- tilpasninger, når forretningen ændrer sig.
Beslut, før du bygger, hvem der gør det:
- En intern udvikler kender forretningen, men er en fast udgift og en nøgleperson.
- En fast aftale med en ekstern udvikler er fleksibel, men gør dig afhængig af én leverandør.
- En dokumenteret løsning med overdragelsesplan gør det muligt at skifte udvikler uden at starte forfra.
Uden en plan bliver koden til teknisk gæld, som ingen tør røre.
Tænkte eksempler
Søgning til en webshop med stort sortiment. Søgning med filtre og stavefejlsrettelse er et almindeligt behov. Jeg ville vælge en færdig søgeløsning og bruge udviklingstiden på at få produktdata og filtre i orden. Det er dem, søgningen afhænger af.
Kundespecifikke B2B-priser. Hvis prisreglerne kan udtrykkes som kataloger og rabatter, kan en standardløsning ofte dække dem. Shopify B2B har kataloger med egne priser på Basic, Grow, Advanced og Plus, men med begrænsninger på Basic, Grow og Advanced. Er reglerne jeres fordel og for komplekse til kataloger, kan en specialudviklet prisberegning give mening.
Eget indholdssystem. At bygge et eget CMS, fordi platformen virker begrænsende, er sjældent en god idé. Indhold er et almindeligt behov, og der findes mange løsninger. Find i stedet ud af, hvad begrænsningen præcis er.
Start med at købe, og byg, når du ved nok
En strategi, jeg ofte anbefaler, er at starte med en færdig løsning. Efter en periode ved du, hvilke funktioner der bruges, hvilke data der skal flyde, og hvor løsningen spænder ben. Så kan du specificere en egen løsning ud fra erfaring – eller konstatere, at den færdige løsning er god nok.
Tjek altid exit-muligheden, før du køber. Kan data eksporteres, og hvor afhængig bliver du af leverandøren? Se vælg integrationer, du kan komme videre fra.
Når beslutningen er stor, samler jeg krav, økonomi og driftsansvar i en platformstrategi. Skal der bygges, kan du læse om specialudviklede apps og integrationer.
FAQ - Ofte stillede spørgsmål
Hvornår bør jeg bygge selv i stedet for at købe?
Når funktionen er det, der adskiller dig fra konkurrenterne, når ingen færdig løsning dækker de vigtigste krav, og når du har nogen til at vedligeholde koden i årevis. Mangler det sidste, er svaret sjældent at bygge.
Hvornår bør jeg købe en færdig løsning?
Når mange virksomheder har samme behov, for eksempel betaling, e-mail, fragt og søgning, når regler og sikkerhed ændrer sig løbende, eller når du skal i gang hurtigt.
Hvordan regner jeg Total Cost of Ownership?
Læg alle omkostninger sammen over samme periode for begge muligheder: licens eller udvikling, implementering, integration, vedligeholdelse, intern tid og exit. Brug mindst tre år, og lav både et forventet og et dyrere scenarie.
Hvem skal vedligeholde specialudviklet kode?
Det skal være besluttet, før du bygger: en intern udvikler, en fast aftale med en ekstern udvikler eller en model, hvor flere kan overtage, fordi koden er dokumenteret. Ingen plan betyder teknisk gæld.
Kan jeg starte med at købe og bygge senere?
Ja, og det er ofte klogt. En færdig løsning viser, hvilke funktioner du faktisk bruger, så en senere specifikation bygger på erfaring i stedet for gæt.
Relaterede artikler
Shopify-app eller specialudvikling?
Det samme valg for mindre funktioner i Shopify-temaet
