Build vs buy: når lønner det seg å bygge eget fagsystem?

Spørsmålet alle stiller, ingen svarer godt

På et tidspunkt i en organisasjons modning kommer spørsmålet: skal vi bygge eget system for dette, eller kjøpe en SaaS-løsning?

Standardsvaret er "kjøp, ikke bygg". Det er ofte riktig. Standardsvaret er også at det er feil i nesten alle interessante tilfeller, fordi de interessante tilfellene er nettopp der valget ikke er åpenbart.

Vi har sittet på begge sider av dette spørsmålet mange ganger. Som leverandør har vi bygget skreddersydde systemer der kunder kanskje burde valgt SaaS, og vi har sett SaaS-løsninger som har holdt kunder fast i flere år med voksende frustrasjon fordi alternativet, å bygge selv, virket overveldende. Her er rammen vi bruker når noen spør oss om de skal bygge eller kjøpe.

De fire scenariene

Det er fire typiske kjøp-eller-bygg-situasjoner:

1. Klar buy: generisk prosess, mange brukere

Hvis prosessen er det samme som tusenvis av andre selskaper trenger (regnskap, lønn, CRM for vanlig B2B-salg, e-post-marketing), og dere har mange brukere som skal bruke det, kjøp. SaaS-leverandører har investert mer i UX, sikkerhet, og kompabilitet enn dere klarer å bygge.

Eksempel: Hvis et selskap med 50 ansatte trenger regnskapsprogram, er svaret en etablert regnskaps-SaaS, ikke skreddersydd.

2. Klar build: unik prosess, kritisk for virksomheten

Hvis prosessen er kjernen i hva dere gjør, og ingen standardløsning matcher fordi dere har en unik tilnærming, bygg. Dette er sjeldnere enn folk tror, men når det er tilfelle, er det åpenbart.

Eksempel: Et helseforetak som vil tilby pasienter en helt ny type oppfølgings-løp som ikke finnes i standard pasientportaler. Dette er kjerne-tjeneste, og må passe deres modell.

3. Vanskelig: hybrid eller integrasjon

Mange selskaper er i mellomsjiktet: prosessen er ikke unik nok til å rettferdiggjøre full skreddersøm, men ikke generisk nok til at en SaaS dekker den fullstendig. Her er svaret oftest "buy + build": kjøp grunnplattformen, bygg integrasjons-laget og det unike på toppen.

Eksempel: Et logistikkfirma som bruker standard ERP, men bygger eget rute-optimaliseringsverktøy som henter data fra ERP-en.

4. Komplisert: eldre SaaS som ikke lenger passer

Dere har en SaaS som har vokst med dere i 5 år, men nå begrenser dere. Dere vurderer å bygge eget. Dette er den vanskeligste situasjonen, fordi inertia-kostnaden av å skifte er høy, samtidig som kostnaden av å fortsette uten å skifte også er høy.

Vår erfaring: hvis SaaS-en koster mer enn det dere ville brukt på egen utvikling i en typisk måned, og dere har klagd over begrensninger over lengre tid, er det på tide å vurdere å bygge eget.

De åtte spørsmålene som avgjør

I stedet for å gjette, gå gjennom disse spørsmålene med utviklingspartneren deres:

1. Hvor mange brukere skal systemet betjene?

Under 5: SaaS er nesten alltid riktig. Over 50: build vurderes seriøst. Mellom: kommer an på faktor 2–8.

2. Hvor mye av prosessen vil dere endre fra "standard"?

Hvis svaret er "10–20%", buy med tilpasninger. Hvis svaret er "over 50%", build.

3. Hvor mange integrasjoner med eksisterende systemer trengs?

Mer enn 3 komplekse integrasjoner taler for build, fordi SaaS gjør integrasjoner dyrt og rigid.

4. Hva er kost-rammen over 3 år?

Regn ut: SaaS-lisens × brukere × 36 måneder + integrasjons-arbeid + tilpasningskostnader. Sammenlign med initial build-kostnad + 3 års drift og videreutvikling. Build vinner ofte over en 3-årshorisont når SaaS-månedsregningen blir høy nok og tilpasningene mange nok.

5. Hvor unike er dataene og rapporteringene?

Hvis dere har behov for rapporter som SaaS ikke kan generere, og data dere ikke kan eksportere ut av SaaS-en, build.

6. Hva skjer hvis SaaS-leverandøren endrer pris eller funksjonalitet?

Hvis svaret er "vi har ikke noe valg", er dere allerede låst inne. Build gir kontroll over kursen.

7. Hva er deres kjernekompetanse?

Hvis prosessen er kjernen i hva dere konkurrerer på, build. Hvis det er en støtteprosess som dere bare må ha, buy hvis mulig.

8. Hvor mye eier dere av dataene?

SaaS-leverandører eier dataformatet. Det betyr at dere er låst til deres oppgraderinger, deres feilmeldinger, deres prismodell. Build gir full kontroll.

Slik ser regnestykket ut

Tenk deg en virksomhet med mange saksbehandlere som bruker en internasjonal SaaS for saksbehandling, med lisens per bruker per måned. Over en treårshorisont blir lisenskostnaden betydelig. Legg til tilpasninger som vedlikeholdes eksternt, og integrasjoner mot ERP-en som er rigide og brytes ved oppgraderinger.

Et forprosjekt avklarer hva et skreddersydd alternativ faktisk koster å bygge og drifte. I mange slike tilfeller ser vi at et eget system kan dekke det aller meste av behovet, til en samlet kostnad over tre år som er lavere enn å fortsette med SaaS pluss tilpasninger.

Regnestykket settes opp slik:

• SaaS: lisens × brukere × 36 måneder + tilpasninger og integrasjonsvedlikehold
• Build: initial byggekostnad + drift og videreutvikling over 3 år

For virksomheter med mange brukere og tunge tilpasninger kan forskjellen bli stor. Poenget er ikke et fasitsvar, men at regnestykket må settes opp konkret for deres situasjon.

Dette eksemplet er ikke universelt. For mindre virksomheter er regnestykket ofte motsatt. For mer komplekse kan gevinsten være større.

Hva folk ofte undervurderer

Tre kostnader vi konsekvent ser at folk undervurderer:

1. Tilpasnings-kostnaden av SaaS. De fleste større SaaS-løsninger trenger 6–18 måneders implementering, omfattende konsulent-bistand, og spesialopplæring av interne brukere. Dette koster ofte mer enn forprosjekt og første versjon av et build-alternativ.

2. Kostnaden av å forme virksomheten etter et SaaS-verktøy. Mange selskaper endrer reelle arbeidsflyter for å passe inn i hva SaaS-en støtter, ikke omvendt. Det er en skjult kostnad som ikke vises i SaaS-fakturaen.

3. Tap av kontroll over kursen. Når SaaS-en endrer prismodell, fjerner funksjoner, eller blir kjøpt opp og endret retning, har dere ingen påvirkning. For prosesser som er kritiske, er det en operasjonell risiko.

Og to kostnader folk ofte overvurderer:

1. Initial build-kostnad. De fleste antar at å bygge eget koster langt mer enn det faktisk gjør. Et MVP av et typisk fagsystem ligger ofte godt under det folk frykter. Det er fortsatt en investering, men sjelden i den størrelsesorden mange ser for seg.

2. Risiko for at det går galt. Et skreddersydd system bygget med en kompetent partner, fastpris etter forprosjekt, sprint-leveranse hver 2. uke, har relativt lav risiko. Risikoen kommer fra dårlig scope-styring, ikke fra det å bygge.

Vår anbefaling

Hvis dere er over 20 brukere på en intern prosess som er viktig for virksomheten, gjør gjennomgangen. Sett spesielt opp en kalkyle over 3 år, regn med både SaaS-lisens, tilpasninger, og kostnader av å forme prosessen etter SaaS-en.

Hvis tallene tilsier build, men dere er nervøs på risiko, start lite. Et forprosjekt koster 50–150k, og du eier resultatet, selv om dere velger å fortsette med SaaS. Det er den billigste forsikringen mot å ta feil beslutning.

Vi gjør slike vurderinger jevnlig, både for kunder som ender med å bygge, og for kunder som ender med å fortsette med SaaS. Vi anbefaler det som er rett, ikke det som gir oss mest arbeid. Send oss en kort linje hvis dere vil ha et utenfra-blikk på beslutningen.

Du kan også lese om hva vi tilbyr av systemutvikling, eller vår tilnærming som utviklingspartner.