Hvornår bør man vælge specialudviklet software?

Inden vi taler om hvornår man skal bygge selv, er det værd at sige hvornår man ikke skal: i størstedelen af tilfældene. CRM, regnskab, projektstyring, helpdesk, e-mail, kalender, mødebooking, fakturering, dokumenthåndtering — hvis I gør noget der ligner det andre virksomheder gør, er der typisk et standardprodukt der løser det 80–90% rigtigt.

De resterende 10–20% er sjældent værd at bygge for. Standardsoftware har en hel branches læring bagt ind: integrationer der virker, et community der diskuterer fejlene før jer, opdateringer der kommer uden at I skal bestille dem, og en pris der allerede er presset af konkurrence. At bygge selv for at undgå et lille kompromis er en af de dyreste fejl en SMV kan lave.

Bevisbyrden ligger derfor på "byg selv" — ikke på "køb hylde". Hvis I ikke kan formulere klart hvad I får ud af at eje koden, som I ikke kan få på anden vis, er svaret oftest at I ikke skal bygge.

Tærsklen mellem standard og custom er sjældent en pludselig ting. Den lister sig på. I starter med at lave et workaround. Så et til. Så bliver der bygget en integration udenom værktøjet. Så er der pludselig tre personer der bruger 10–20% af deres tid på at holde Notion, Airtable og en Zapier-flow i live, fordi den oprindelige løsning ikke længere passer.

Det er på det punkt — ikke før — at samtalen om custom giver mening. Tærsklen rammes når jeres måde at arbejde på reelt afviger fra hvad standardværktøjet er designet til, og når den afvigelse er en forretningsmæssig styrke I gerne vil dyrke. Hvis afvigelsen blot er irriterende, men ikke giver jer en forretningsmæssig fordel, er det stadig forkert at bygge.

Vi tester typisk tærsklen med tre spørgsmål: Er det workaround vi har bygget op blevet en del af kerneprocessen? Bremser det os i at lave det vi reelt vil differentiere os på? Og — det vigtigste — er der nogen i organisationen der er klar til at eje en custom løsning i fem år, ikke bare bestille den?

Når folk sammenligner standard og custom, sammenligner de næsten altid licensomkostning mod udviklingsbudget. Det er forkert. Custom har ingen licens, men det har drift, vedligehold, opdateringer, sikkerhedspatches, monitorering, fejlretning, ændringsønsker og — vigtigst — afhængighed af de mennesker der ved hvor knapperne er.

Et godt custom-projekt regner med at den reelle ejerskabs-omkostning over fem år er en multiplum af build-omkostningen. Det er ikke skræmmetaktik, det er bare hvordan software fungerer. En platform der står oppe i fem år har skiftet stack-versioner, fået nye integrationer, set ti omgange compliance-krav og fået revideret features. Alt det skal gøres af nogen.

Standardsoftware fjerner den byrde og lægger den hos leverandøren. Du betaler licens i stedet — men du betaler også i form af mindre kontrol, langsommere ændringer, og at du er en af mange kunder leverandøren prioriterer mellem. Det er en ærlig byttehandel; den er bare værd at lave bevidst.