Udvikle internt værktøj, build vs buy guide for SMV (3 stier)

Indholdsfortegnelse

• Tre stier, ikke to
• Sti 1, købe SaaS som-den-er
• Sti 2, bygge fra bunden
• Sti 3, bygge oven på en platform
• Decision framework, 6 spørgsmål
• Hvornår no-code er nok (og hvornår ikke)
• Konkrete eksempler på de tre veje
• Ofte stillede spørgsmål om at udvikle internt værktøj
• Læs også

Når en virksomhed beslutter at den har brug for et internt værktøj, præsenterer markedet to standardvalg. Køb noget standard, eller byg det selv fra bunden. Sandheden er, at der er tre stier, og den tredje (bygge oven på en eksisterende platform) er ofte den rigtige for danske SMV’er.

Denne guide går igennem hvornår det giver mening at udvikle internt værktøj, hvornår det er bedre at købe en standardløsning, og hvornår en mellemvej er den rigtige. Vi præsenterer en beslutningsramme på 6 spørgsmål, konkrete eksempler på hver vej, og en realistisk vurdering af hvornår no-code-værktøjer som Airtable, Notion eller Make er tilstrækkelige.

Overvejer I at konsolidere stacken eller bygge skræddersyet? Decree har bygget hele platformen selv. Hvis I har en niche-proces, bygger vi den ind. Se vores løsninger eller book en samtale.

Tre stier, ikke to

Den klassiske build-vs-buy-debat er for snæver. Den antager, at I enten får et færdigt produkt og lever med dets begrænsninger, eller bygger noget fra bunden med fuld frihed og fuld omkostning. Begge ekstremer rammer sjældent det rigtige punkt for en SMV med 50 til 500 ansatte.

I praksis findes der tre stier.

Hvilken sti der er rigtig, afhænger af tre faktorer: hvor specifik jeres proces er, hvor strategisk værktøjet er for jeres forretning, og hvor stor jeres organisation er. Vi gennemgår hver sti før vi når til selve beslutningsrammen.

Sti 1, købe SaaS som-den-er

Det enkleste valg. I køber et standardprodukt fra en leverandør, tilpasser den minimale konfiguration der er mulig, og lever med produktets begrænsninger.

Hvornår det er rigtigt

• Processen er generisk. Standardværktøjet matcher 80-90 procent af jeres behov uden tilpasning
• Leverandøren har lang track record. Produktet har eksisteret i 5+ år, har flere tusinde kunder, og opdateres regelmæssigt
• Compliance og hosting er acceptable. Data ligger hvor I kan acceptere det (EU-cloud for GDPR-følsomme processer)
• Skiftomkostning er lav. Hvis værktøjet ikke fungerer, kan I migrere uden katastrofe

Hvor det går galt

Den primære fejl er at acceptere et standardværktøj, der dækker 60 procent af behovet, og bygge skyggeprocesser i Excel, e-mail og Slack til at dække de resterende 40 procent. Det er den værste af alle verdener: I betaler for værktøjet, men sparer ikke tiden, og data er fragmenteret.

Den anden fejl er at undervurdere total cost of ownership. Et SaaS-produkt med listepris på 500 kr per bruger per måned koster ikke 500 kr per bruger per måned. Det koster også integrationsarbejde, brugeradoption, vedligeholdelse af konfiguration, og leverandørstyring. Læs mere om dette i it-konsolidering SMV ROI-regnestykket.

Eksempler på processer, hvor køb-SaaS er rigtigt

• Lønsystem (lokal lovgivning er specialiseret nok til at det ikke er værd at bygge)
• HR-stamdata-system for SMV (BambooHR-klassen er moden)
• Helpdesk for IT-support (Zendesk-klassen)
• Bogføring og fakturering (lovgivningskrav gør standardprodukter konkurrencedygtige)
• Nyhedsbreve og marketing-automation til generiske kampagner

Sti 2, bygge fra bunden

Den dyreste og mest tidskrævende vej, men den giver fuld kontrol. I bygger en kodebase fra bunden med eget design, egen datamodel, eget infrastrukturlag og eget driftshold.

Hvornår det er rigtigt

• Værktøjet er strategisk. Det skaber konkurrencefordel, og I vil ikke dele det med markedet
• Processen er ekstremt specifik. Ingen standardprodukt dækker mere end 30-40 procent
• I har eller kan opbygge teknisk kapacitet. I har eller kan ansætte de udviklere, der skal vedligeholde løsningen i 5-10 år
• Skala retfærdiggør det. Værktøjet bruges af nok mennesker eller skaber nok værdi til at investeringen tjenes hjem

Hvor det går galt

Den klassiske fejl er at undervurdere drift og vedligeholdelse. En custom-bygget løsning kræver typisk 20 til 40 procent af den oprindelige byggepris i årlig vedligeholdelse. Det betyder, at en løsning, der koster 2 mio kr at bygge, koster 400.000 til 800.000 kr om året i vedligeholdelse. Bygget i 2024, betyder det at totalomkostningen frem til 2029 er 4 til 6 mio kr, ikke 2.

Den anden fejl er at undervurdere tidsrammen. Et “6 måneders projekt” bliver typisk til 12. Et “1 års projekt” bliver typisk til 2. Det betyder, at den forretningsproces I forsøger at understøtte, har ændret sig undervejs, og det færdige værktøj rammer det forkerte mål.

Eksempler på processer, hvor build-fra-bunden er rigtigt

• Trading-systemer for finansielle institutioner
• Specialiserede produktionsstyringssystemer
• Branche-specifik regulatorisk software (medico, forsvar, atomenergi)
• Konkurrencehemmelig logistikoptimering for store distributørvirksomheder
• Specifikke maskinlæringssystemer, der er kerneproduktet

For en typisk dansk SMV i en ikke-specialiseret branche er det sjældent at sti 2 er det rigtige valg.

Sti 3, bygge oven på en platform

Den oversete mellemvej. I bygger custom logik, men I bygger den oven på en eksisterende platform, der leverer backend, identity, datalagring, kommunikation og drift. I betaler kun for jeres specifikke logik, ikke for det infrastrukturlag, der kræves for at understøtte den.

Hvornår det er rigtigt

• I har en eller flere processer, der er specifikke for jeres forretning men ikke kerneproduktet
• I vil ikke ansætte et udviklingsteam internt
• I bruger allerede en samlet platform eller planlægger at gøre det
• Tidsrammen er kritisk. I har brug for løsningen om 3-6 måneder, ikke 12-18

Hvad I sparer

Hvis platformen allerede leverer brugerstyring, datalagring, autorisation, mail, signering, dokumenter og notifikationer, betaler I kun for den proces, der er unik for jer. Det reducerer typisk omkostningen med 50 til 70 procent sammenlignet med build-fra-bunden, og halverer eller bedre tidsrammen.

Eksempel: en kundeservice-portal med custom workflow, integreret signering, dokumentupload og notifikation til kunden. Bygget fra bunden: 1,5 mio kr og 9 måneder. Bygget oven på en platform med signering, dokumenter og notifikationer på plads: 400.000 kr og 4 måneder.

Decrees skræddersyede SaaS er bygget netop til denne sti. Vi har platformen (mail, signering, dokumenter, CRM, telefoni, identity), og vi bygger den specifikke logik, der gør den til jeres løsning. Se vores samlede platform for at forstå, hvad der allerede ligger der.

Hvor det går galt

Den primære risiko er platformafhængighed. Hvis platformleverandøren skifter retning, hæver priserne markant eller går ned, er I afhængige af dem. Det er en reel risiko, og den skal styres med kontraktsbestemmelser om dataportabilitet, eksportformater og en exit-strategi.

Den anden risiko er at platformens begrænsninger sætter begrænsninger på jeres logik. Hvis platformen ikke understøtter en specifik integration eller en specifik datatype, kan det være svært at bygge oven på den. Vurder dette grundigt inden I forpligter jer.

Decision framework, 6 spørgsmål

For at vælge mellem de tre stier, så besvar disse seks spørgsmål.

1. Hvor specifik er processen for jeres forretning?

Hvis processen er generisk (regnskab, CRM-grundfunktion, helpdesk), så går I til sti 1. Hvis processen er ekstremt specifik (kerneprodukt, konkurrencehemmelig logik), så går I til sti 2 eller 3. Vurder ærligt: er processen reelt unik, eller har I bare arbejdet med den så længe, at I tror den er unik?

2. Er værktøjet strategisk eller operationelt?

Strategiske værktøjer (det, der differentierer jeres forretning) bør bygges. Operationelle værktøjer (det, alle virksomheder skal have) bør købes. En mellemkategori findes: forretningsspecifikke processer, der ikke er kerneproduktet, men som er en del af jeres unikke value proposition. Disse hører typisk til sti 3.

3. Hvor mange brugere har værktøjet, og hvor stor er volumen?

Et værktøj brugt af 10 personer 2 gange om ugen retfærdiggør sjældent en custom-bygget løsning. Et værktøj brugt af 200 personer dagligt gør. Tærsklen er typisk 50+ daglige aktive brugere eller 500+ månedlige transaktioner.

4. Har I teknisk kapacitet til at vedligeholde en custom løsning?

Hvis I har et internt udviklingsteam (eller kan opbygge et), er sti 2 en mulighed. Hvis I ikke har det, og I ikke vil opbygge det, er sti 1 eller 3 de eneste reelle valg. Det er en strategisk beslutning, ikke kun en teknisk.

5. Hvor følsom er processen for compliance, hosting og datasuverænitet?

Hvis I behandler følsomme persondata, sundhedsdata, eller andre data der har strenge hosting-krav, så bestemmer det leverandørvalget. Et amerikansk SaaS-produkt under CLOUD Act er måske ikke en option for jer. Sti 3 oven på en EU-baseret platform kan være den eneste reelle vej. Læs mere om Decrees DPA og hvordan vi håndterer dette.

6. Hvor hurtigt skal I have løsningen i drift?

Hvornår no-code er nok (og hvornår ikke)

En vigtig understi er no-code-værktøjerne (Airtable, Notion, Make, Zapier, Bubble, Microsoft Power Apps). De er ofte et perfekt mellemskridt mellem “ingen løsning” og “rigtig udvikling”.

Hvor no-code virker

• Prototype eller pilot. Test om processen reelt har det forventede output, før I investerer i bygget løsning
• Lavfrekvent intern proces. Tjeklister, projektplanlægning, simpel CRM for små teams
• Database-lignende behov uden komplekse relationer. Kontaktliste, opgaveliste, simpel inventory
• Lavt brugerantal (under 20 daglige aktive) og acceptable krav til UX
• Procesautomation mellem standardprodukter. Zapier eller Make der flytter data mellem SaaS

Hvor no-code ikke er nok

• Mange daglige brugere (over 50) hvor performance og UX bliver problemer
• Komplekse forretningsregler som ikke kan udtrykkes i no-code-værktøjets logik
• Integrationskrav til legacy-systemer som ikke har færdige connectors
• Compliance-krav der kræver kontrol over hosting, kryptering, audit-spor
• Skalering ud over hundredvis af brugere hvor licensomkostningen eksploderer
• Kerneprocesser hvor stabilitet og leverandørafhængighed er kritisk

Den klassiske rejse er: start med no-code som prototype eller MVP. Hvis processen viser sig at være vigtig nok og bruges nok, så migrer til en bygget løsning (typisk sti 3 oven på en platform). Hvis processen ikke viser sig at være vigtig nok, så har I sparet udviklingsbudgettet.

En advarsel om no-code-kompleksitet

Der er en kritisk grænse, hvor en no-code-løsning vokser sig så kompleks, at den koster mere at vedligeholde end en bygget løsning. Vi har set Airtable-bases med 30+ tabeller og 200+ formler, der har taget halvdelen af en operations-medarbejders tid bare at holde i live. Hvis I når dette punkt, er no-code blevet dyrere end alternativet, og I skal migrere.

Konkrete eksempler på de tre veje

For at gøre det konkret, her er tre virksomhedseksempler og hvilken sti, der ville være rigtig for hver.

Eksempel 1, en serviceformidler (50 ansatte)

Forretning: serviceformidler til vedligehold på erhvervsejendomme. 50 ansatte, hvoraf 30 er servicemontører.

Behov: arbejdsstyringssystem hvor montører får tildelt opgaver, dokumenterer arbejdet, indsamler underskrifter, og rapporterer tilbage.

Anbefaling: sti 3 (byg oven på platform). Mange standardprodukter findes (ServiceMax, Salesforce Field Service), men prisen for en SMV på 50 ansatte er prohibitiv (typisk 1500-3000 kr per bruger per måned). Bygget oven på en platform med eksisterende dokument-, CRM- og kommunikationsmoduler kan en specifik løsning bygges for 400.000-600.000 kr og være i drift på 4 måneder.

Eksempel 2, en advokatvirksomhed (120 ansatte)

Forretning: advokatkontor med fokus på erhvervsret. 120 ansatte.

Behov: sagsstyringssystem med specifik logik for danske retsregler, integration til Domstolsstyrelsen, og dokumenthåndtering.

Anbefaling: sti 1 (køb SaaS). Branchen har modne sagsstyringssystemer (Penneo, Lex, Akta) med specifik dansk integration. Custom-udvikling er sjældent ROI-positivt, fordi standardprodukterne allerede dækker 90 procent af behovet, og branchekendskabet i leverandørerne er svært at matche internt.

Eksempel 3, en teknisk konsulentvirksomhed (180 ansatte)

Forretning: teknisk rådgivning på industri- og infrastrukturprojekter. 180 ansatte.

Behov: timeregistrerings- og fakturerings-system med specifik logik for projektportefølje, fast pris vs timer, milepælsfakturering.

Anbefaling: sti 1 + sti 3. Brug et standardprodukt til timeregistrering og fakturering (sti 1, f.eks. TimeLog eller Penneo), og byg en lille custom-overlay til den specifikke milepæls- og porteføljelogik (sti 3 oven på en platform). Total omkostning er typisk 250.000-400.000 kr i sti 3, plus standard SaaS-licens for sti 1. Tilbagebetaling typisk under 14 måneder.

Læs mere om de konkrete løsninger vi har bygget for at se eksempler på sti 3 i praksis.

Ofte stillede spørgsmål om at udvikle internt værktøj

Hvor stor en virksomhed skal man være, før det kan betale sig at bygge selv?

Ikke et spørgsmål om størrelse alene. En virksomhed med 30 ansatte i en specialiseret branche kan have ROI på en custom løsning, hvis processen er kritisk og standardprodukter ikke findes. En virksomhed med 500 ansatte i en generisk branche bør sjældent bygge selv. Vurder behovets specifikitet før virksomhedens størrelse.

Hvad er den typiske fordeling af kost til udvikling vs vedligeholdelse?

Tommelfingerregel: vedligeholdelse er 20-30 procent af den oprindelige byggepris pr. år. Det betyder, at en løsning bygget for 1 mio kr vil koste 200.000-300.000 kr om året i vedligeholdelse. Over 5 år er den samlede TCO typisk 2 til 2,5 gange byggeprisen. Glem aldrig vedligeholdelsen i regnestykket.

Kan vi købe SaaS og custom-udvikle samtidigt?

Ja, og det er ofte den rigtige løsning. Køb standardværktøj for de generiske dele (regnskab, HR, mail), og byg custom for den specifikke proces, der differentierer jer. Vigtigt: undgå at custom-løsningen kræver dyb integration med standardværktøjet, fordi standardværktøjet kan ændre sig på en måde, der bryder integrationen.

Hvor lang tid tager en typisk sti 3 (byg oven på platform)?

For en velscoped løsning med 5-10 hovedfunktioner er typisk 3-6 måneder fra projektstart til produktion. Tidsrammen forudsætter, at platformen allerede er på plads. Hvis platformen skal etableres samtidigt, fordobles tidsrammen typisk.

Hvad sker der hvis platformleverandøren går konkurs?

Det er en reel risiko og bør indgå i beslutningen. Mitigation: vælg en leverandør med dokumenteret dataportabilitet, undgå proprietære dataformater, sikre eksportkapacitet i kontrakten, og overvej en escrow-aftale for kildekoden hvis det er kritisk. For en dansk leverandør med EU-hosting er risikoen ofte lavere end for et amerikansk SaaS-produkt under CLOUD Act, men ikke nul.

Hvordan ved vi om vi har vurderet processen rigtigt?

Det er svært at vide før I har bygget eller købt. Den bedste mitigation er at starte med en pilot eller MVP. Køb SaaS for et lille team i 3 måneder, eller byg en simpel første version af custom-løsningen og lad et lille team bruge den. Den faktiske brug afslører, hvad der virker og hvad der mangler. Big bang-implementeringer fra dag 1 er den klassiske kilde til fejlinvesteringer.

Læs også

• Skræddersyet SaaS-platform vs standard software, build vs buy-guide
• Skræddersyet SaaS-udvikling, sådan arbejder vi
• Decree-platformen, hele stakken samlet
• Vores løsninger, alle moduler
• It-konsolidering SMV, ROI-regnestykket

Vil du samle din virksomheds digitale rygrad hos én dansk leverandør? Decree bygger og driver hele stakken (mail, signering, telefoni, CRM, dokumenter, eLearning) plus skræddersyede SaaS-platforme og mobilapps. Alt hostet i EU, CLOUD Act-fri, samlet i én DPA. Se platformen eller kontakt os for en samtale.