Leep.
HjemForretningsutviklingWeb & teknologiProsjekter
Kontakt
Logg inn
Leep.

Skreddersydde nettsider og webapplikasjoner for ambisiøse selskaper.

Navigasjon

  • Hjem
  • Prosjekter
  • Kontakt

Tjenester

  • Nettside
  • App
  • AI-implementering

Ressurser

  • Artikler
  • Ordbok

Kontakt

  • hello@leep.no

© 2026 Leep. Alle rettigheter reservert.

Tilbake til artikler
Forretningsstrategi9 min lesing

Bygge eller kjøpe: Programvarevalget de fleste bedrifter bommer på

For enkle, repetitive problemer er det ofte bedre å bygge din egen løsning enn å abonnere på enda et SaaS-verktøy. Slik vet du når du bør bygge i stedet for å kjøpe.

Martin Brandvoll
Martin BrandvollGrunnlegger & Sjefskonsulent
Publisert 23. januar 2025
Software development and decision making concept

Bygge eller Kjøpe: Programvarevalget de fleste bedrifter bommer på

Alle bedrifter treffer før eller senere den samme veggen. Du har et problem. Noe spiser opp tiden din. Kanskje du kopierer data fra ett sted til et annet, sender samme type e-post om og om igjen, eller oppdaterer kunder manuelt hver gang noe endrer seg på kontoen deres.

Så du gjør det alle gjør: du Googler. Plutselig har du femten faner åpne, og hver av dem lover å løse akkurat ditt problem for "bare" 299 kr i måneden per bruker.

Her er det ingen forteller deg: for mange av disse problemene er du bedre tjent med å bygge noe selv.

Ikke alltid. Men mye oftere enn folk flest tror.

Den skjulte kostnaden ved enda en app

La oss snakke om hva som faktisk skjer når du abonnerer på et nytt SaaS-verktøy.

Dag én føles bra. Onboardingen er smooth. Demoen viste akkurat det du trengte. Du løser problemet!

Spol frem seks måneder. Nå har du:

  • Enda et passord å huske (eller enda en oppføring i passordbehandleren)
  • Enda et dashboard å sjekke
  • Enda et sett med brukerrettigheter å håndtere når noen starter eller slutter
  • Enda en månedlig kostnad som fornyes automatisk enten du bruker det eller ikke
  • Enda en integrasjon som kanskje ryker når noen av de andre verktøyene dine oppdateres
  • Enda et selskap som kanskje blir kjøpt opp, endrer retning, eller skrur opp prisene
Og her kommer poenget: du bruker sannsynligvis bare 15% av det verktøyet faktisk kan gjøre. Du abonnerte på en fullverdig prosjektstyringsplattform når du egentlig bare trengte en måte å holde styr på hvilke fakturaer som var sendt ut. Men du fortsetter å betale på grunn av sunk cost-fellen: du har allerede investert tid i å sette det opp, så å forlate det føles som sløsing.

Når ferdigløsninger gir mening

Før jeg går videre, la meg være tydelig: det finnes absolutt situasjoner der det er riktig å kjøpe programvare.

Komplekse, spesialiserte områder. Regnskapssystem? Kjøp det. CRM med årevis av salgsmetodikk innebygd? Kjøp det. E-postinfrastruktur? Definitivt kjøp det. Disse verktøyene representerer tiår med domeneekspertise og edge cases du ikke vil oppdage på egen hånd.

Standardiserte behov. Kalenderplanlegging, videokonferanser, digital signering. Disse problemene er løst. Løsningene er billige. Å bygge ditt eget ville vært absurd.

Når teamet ditt faktisk vil bruke funksjonene. Hvis du genuint kommer til å utnytte 70%+ av det et verktøy tilbyr, og det integrerer godt med stacken din, og prisingen fungerer i skala... da er det kjøp.

Spørsmålet er ikke "bør vi noensinne kjøpe programvare?" Selvfølgelig ja. Spørsmålet er: strekker du deg etter et abonnement når en enkel skreddersydd løsning ville tjent deg bedre?

Tegnene på at du bør bygge i stedet

Her ser jeg bedrifter ta feil valg gang på gang.

Du løser ett spesifikt problem

Du sender en bekreftelsesmail hver gang en kundes ordre er sendt. Det er det. Det er hele greia.

Du trenger ikke en "kundekommunikasjonsplattform" til 2000 kr i måneden. Du trenger et script som trigger når ordrestatusen endrer seg i systemet ditt og sender en e-post via din eksisterende e-posttjeneste.

Tid å bygge: noen timer. Løpende kostnad: stort sett null. Vedlikehold: nesten ingenting, fordi det gjør én ting og den tingen endrer seg sjelden.

Du gjør det allerede manuelt (og det er forutsigbart)

Tenk på de repetitive oppgavene i bedriften din. De hvor noen på teamet kunne skrevet ned nøyaktige steg-for-steg-instruksjoner. Ting som:

  • "Når et nytt lead kommer inn, legg dem til i dette regnearket og send dem velkomstpakken"
  • "Hver fredag, hent salgstallene fra dashboardet og lim dem inn i ukesrapporten"
  • "Når et prosjekt er merket som ferdig, send e-post til kunden med de endelige leveransene"
Hvis du kan skrive en tydelig sjekkliste for det, kan du automatisere det. Og ofte er den automatiseringen enklere enn å lære og konfigurere et SaaS-verktøy som var designet for hundre andre brukstilfeller du ikke har.

Integrasjonen ville vært renere

Her er en som overrasker folk: egenutviklede løsninger integrerer ofte bedre enn hyllevare.

Hvorfor? Fordi du bygger dem til å fungere med DINE systemer. Ikke en generisk API som på en måte passer med hvordan du gjør ting hvis du myser.

Du har en database med kundeinfo. Du har et e-postsystem. Du har ordrehåndteringssystemet ditt. En egenutviklet løsning kan lese direkte fra databasen din, bruke ditt eksisterende e-postoppsett, og koble seg inn i ordresystemet ditt akkurat slik du trenger det.

I mellomtiden krever SaaS-alternativet at du setter opp Zapier-arbeidsflyter, konfigurerer webhooks, mapper felt som ikke helt matcher, og ber til at ingenting ryker når noen av disse systemene oppdateres.

Ekte eksempler du kanskje kjenner deg igjen i

La meg male noen bilder. Se om noen av disse høres kjent ut.

Fakturastatusoppdateringsproblemet

Situasjonen: Hver gang en faktura blir betalt, må noen oppdatere prosjektstatusen i PM-verktøyet ditt og varsle kundeansvarlig.

"Kjøp"-tilnærmingen: Abonner på en integrasjonsplattform. Konfigurer triggerne. Map feltene. Sett opp varslingsreglene. Betal 500 kr i måneden. Feilsøk når det tilfeldig slutter å fungere.

"Bygg"-tilnærmingen: Et lite script som overvåker betalingsbekreftelser (betalingsleverandøren din sender allerede webhooks), oppdaterer et felt i PM-verktøyet ditt (de har et API), og sender en Slack-melding (eller e-post) til kundeansvarlig.

En ettermiddag med arbeid. Gratis for alltid. Gjør akkurat det du trenger, ikke noe mer.

Kunde-onboarding-sjekklisten

Situasjonen: Nye kunder trenger en velkomstmail, innlogging til kundeportalen din, et oppstartsmøte booket, og infoen sin lagt til i CRM-et.

"Kjøp"-tilnærmingen: Onboarding-automatiseringsprogramvare! 1500 kr i måneden. Bruk to uker på å konfigurere det. Innse at det ikke integrerer med den spesifikke portalen din. Bygg workarounds.

"Bygg"-tilnærmingen: Et enkelt skjema som trigger når en ny kunde legges til. Det sender velkomstmailen fra en mal, oppretter portalkontoen deres, legger til en kalenderlenke for selvbooking, og pusher detaljene deres til CRM-et ditt. Alt med verktøyene du allerede har.

Ukesrapport-marerittet

Situasjonen: Hver mandag bruker noen to timer på å hente tall fra tre forskjellige dashboards, formatere dem, og sende sammendraget på e-post til ledelsen.

"Kjøp"-tilnærmingen: Business intelligence-plattform! Minimum 3000 kr i måneden. Data warehouse-oppsett. Dashboard-opplæring. Nå trenger du noen som kan SQL. På en eller annen måte ble dette et helt prosjekt.

"Bygg"-tilnærmingen: Et planlagt script som henter data via API-ene til de eksisterende verktøyene dine, formaterer tallene, og sender e-posten automatisk klokken 08 mandag morgen. Total oppsettid: en dag. Personen som pleide å gjøre dette manuelt bruker nå de to timene på noe mer verdifullt.

"Men vi er ikke tekniske"-innvendingen

Jeg hører dette konstant: "Det høres fint ut, men vi har ikke utviklere."

Godt poeng. Men tenk på dette:

Du har kanskje mer teknisk evne enn du tror. Verktøy som Airtable, Retool, eller til og med Google Apps Script lar folk med grunnleggende regnearkferdigheter bygge overraskende kapable automatiseringer. Det er ikke "programmering" i den skumle forstand.

Engangskostnaden ved å bygge slår den løpende kostnaden ved å abonnere. Å leie inn en utvikler i 10 timer til 1200 kr i timen er 12 000 kr. Det "enkle" SaaS-verktøyet til 1000 kr i måneden koster 12 000 kr i året. På cirka 12 måneder har du gått i null. Etter det sparer du penger hver måned mens de fortsatt betaler.

Egenutviklede løsninger er ofte enklere å vedlikeholde. De gjør én ting. Når noe ryker (sjelden), er det åpenbart hva som gikk galt. Ingen feilsøking av mystiske SaaS-plattformproblemer eller venting på at supportteamet deres skal svare.

Du kan alltid leie inn noen til å bygge det. Og nå eier du det. Ingen abonnement. Ingen prisøkninger. Ingen "vi endrer produktretning"-e-poster. Det er ditt.

Hvordan ta avgjørelsen

Her er et enkelt rammeverk:

Kjøp når:

  • Problemet er komplekst og veletablert (regnskap, CRM, e-postmarkedsføring)
  • Du genuint vil bruke mesteparten av funksjonene
  • Integrasjon er grei
  • Verktøyet har solid track record og et stabilt selskap bak seg
  • Teamet ditt kjenner det fra før
Bygg når:
  • Du løser ett spesifikt, veldefinert problem
  • Oppgaven er repetitiv og forutsigbar
  • Integrasjon med eksisterende verktøy er hovedverdien
  • Du ville bare brukt en liten brøkdel av et kommersielt verktøys funksjoner
  • Du vil unngå enda en avhengighet til en ekstern tjeneste
Spørsmål å stille:
  • "Hvor stor andel av dette verktøyet ville vi faktisk brukt?"
  • "Kunne vi forklart denne oppgaven som en enkel sjekkliste?"
  • "Ville en egenutviklet løsning integrert bedre med det vi allerede har?"
  • "Hva er totalkostnaden for abonnementet over 3 år vs. å bygge det én gang?"

Det store bildet

Det ligger noe dypere her. Hvert abonnement du legger til er en avhengighet. Et forhold til et annet selskap. Et veddemål på at de fortsetter å eksistere, holder prisene rimelige, og holder produktet relevant for dine behov. Og hvert abonnement har en alternativkostnad: de pengene kunne gått til noe du faktisk eier.

Hver egenutviklede løsning du bygger er en eiendel. Noe du eier. Noe som fungerer akkurat slik du trenger det, fordi du lagde det sånn.

Jeg sier ikke at du aldri skal abonnere på noe. Det ville vært latterlig. Jeg sier at default-tankegangen i bransjen vår har svingt for langt mot "det finnes sikkert en app for det."

Noen ganger er den beste løsningen den du bygger selv. Ikke fordi den er billigere (selv om den ofte er det). Ikke fordi den er raskere (selv om den kan være det). Men fordi den er din, den gjør akkurat det du trenger, og den kommer ikke med bagasjen av funksjoner du aldri vil bruke, integrasjoner du aldri vil konfigurere, og dashboards du aldri vil sjekke.

Neste gang du tar deg selv i å shoppe programvare for å løse et enkelt problem, stopp opp. Spør deg selv: kunne vi bare bygget dette?

Svaret kan overraske deg.

Del denne artikkelen:

Om forfatteren

Martin Brandvoll

Martin Brandvoll

Grunnlegger & Sjefskonsulent

Martin har 10+ års erfaring med å bygge bro mellom forretningsstrategi og teknisk implementering. Han spesialiserer seg på å hjelpe SMB-er med å utnytte teknologi for bærekraftig vekst.

Se alle artikler av Martin Brandvoll →

Innholdsfortegnelse

Del denne artikkelen

Relaterte artikler

Growth chart showing exponential improvement
Forretningsstrategi•8 min lesing

Rentes rente-effekten: Hvorfor små forbedringer slår store lanseringer

Oppdag hvorfor konsekvente 1% forbedringer gir massive resultater over tid, mens store lanseringer ofte skuffer. Et strategisk rammeverk for bærekraftig vekst.

Martin Brandvoll
Martin Brandvoll
10. des. 2025
Les mer
AI neural network visualization
Teknologi•6 min lesing

Hvordan AI transformerer småbedrifter i 2025

En praktisk guide til AI-applikasjoner som gir reell avkastning for SMB-er. Ingen hype, bare beviste bruksområder.

Martin Brandvoll
Martin Brandvoll
8. des. 2025
Les mer
Business handshake representing partnership
Forretningsstrategi•5 min lesing

Leverandør vs. Partner: Hvorfor tankesettet avgjør avkastningen

Markedet er fullt av byråer som selger timer. Vi selger resultater. Her er hvorfor det betyr noe.

Martin Brandvoll
Martin Brandvoll
1. des. 2025
Les mer

Få innsikt levert

Ukentlige artikler om forretningsstrategi, teknologi og bærekraftig vekst.

Ingen spam. Avslutt når som helst.