For noen år siden krevde det å bygge egen programvare et helt utviklerteam. I dag kan du som HR-leder med et konkret problem og en AI-assistent ha en fungerende prototype klar innen fredag.
Dermed er et gammelt spørsmål tilbake på agendaen: Bør du kjøpe et ferdig HR-system, eller bygge det selv?
Anders Holmberg, Chief Revenue Officer i Eletive, åpnet vårt digitale summit AI in HR 2026 med akkurat det spørsmålet. Han har mer enn 15 års erfaring fra SaaS-bransjen (programvare som tjeneste) og har arbeidet tett med produktteam gjennom hele karrieren. Her er de viktigste innsiktene fra sesjonen hans.
Å bygge har aldri vært enklere
Tallene er vanskelige å ignorere. Ifølge GitHubs rapport for 2025 ble det opprettet 121 millioner nye programvareprosjekter i løpet av året. Det er 230 nye prosjekter hvert eneste minutt. AI-skapte prosjekter vokste med 200 % på ett år.
Tidlig i år skapte dette uro blant investorer. Mange begynte å snakke om en «SaaS-apokalypse»: Hvis alle kan bygge sine egne verktøy, hvorfor skulle noen betale for programvare? Verdivurderingene for noen av de største SaaS-selskapene falt kraftig.
:format(png)/f/288714721386412/2170x725/1ac9204f88/buy-or-build-stats.png)
Likevel sluttet ikke selskaper å kjøpe programvare. Det offentlige SaaS-markedet har hentet inn igjen 40 % siden bunnen i februar. Programvareinvesteringene vokser fortsatt med 15,5 % i året (Gartner, 2026), og et gjennomsnittlig selskap bruker fortsatt rundt 300 verktøy (Zylo, 2026).
Svaret er sannsynligvis ikke enten kjøpe eller bygge – men begge deler, side om side. Det virkelige spørsmålet er når du bør gjøre hva.
Når det gir mening å bygge selv
Fire tegn på at egenutviklet løsning kan være riktig valg:
Logikken er unik for dere. Kompetanserammeverket, stillingsarkitekturen, reglene for intern mobilitet. I det øyeblikket en leverandør generaliserer dette, er det ikke lenger deres.
Omfanget er tydelig avgrenset. Én arbeidsflyt. Ét team. Én problemstilling. Dette kvartalet. Egenutviklingsprosjekter strander når de stille og rolig vokser seg til plattformer som er ment å leve i årevis.
Verdien ligger i data dere eier. Hvis det smarte er i selve dataene og AI kun er grensesnittet, er dere nærmere en bygge-beslutning enn dere kanskje tror.
Eierskap er avklart. Hvis dere ikke kan navngi personen og budsjettlinjen for 2029, bygger dere ikke – dere prototyper.
:format(png)/f/288714721386412/1411x665/3059d33bd4/build-or-buy-when-it-makes-sense-to-build.png)
Hva kan dette se ut som i HR? Kanskje en enkel mikro-spørreundersøkelse: Hvordan gikk kickoffen? Hvem vil delta på julebord? Hvem er årets medarbeider? Når det ikke er behov for anonymitet, trendanalyser eller kobling til organisasjonshierarkiet, løser en enkel egenutviklet løsning jobben.
Kanskje er det en rapportpakke til styret: en AI-agent som henter data fra flere systemer og setter dem sammen til kvartalsrapporten i deres eget format, hver gang. Eller en policy-assistent trent utelukkende på deres håndbok, avtaler og lokale regelverk.
Alle tre fungerer av samme grunn: verdien ligger i dataene, ikke i modellen.
Når det er smartere å kjøpe
Seks tegn på at et kjøpt HR-system er det riktige valget:
Problemet er det samme overalt. Lønn, rekruttering, compliance-rapportering, medarbeidersamtaler. Noen har sannsynligvis allerede løst dette bedre enn dere vil klare.
Dere trenger sammenligningsdata. Benchmark-data kan dere ikke bygge selv. Det er et datagrunnlag dere enten har eller ikke har. Innen ansattengasjement er det ofte her den virkelige innsikten sitter.
Regulatorisk og dataeksponering er omfattende. Dere kan bygge en GDPR-kompatibel applikasjon i dag. Det krevende er å holde den kompatibel etter hvert som regelverket endres. Hvis dere risikerer brudd på GDPR eller medarbeideres anonymitet, vil dere ha en leverandør som har dette som sin eneste jobb.
Modellene under endrer seg stadig. Noen ganger endrer resultatene seg umerkelig, og månedlige rapporter ser litt annerledes ut fra gang til gang. Leverandøren håndterer disse endringene for dere.
Kompetansen betyr mer enn programvaren. Kjøper dere løsningen, bærer noen andre implementering og adopsjon. Bygger dere selv, blir dere ekspertene. For alltid.
Dere vil at noen andre svarer når det oppstår problemer. Alle interne utviklingsprosjekter har en lanseringsfest. Svært få har support mandag morgen.
:format(png)/f/288714721386412/1393x656/c193ff539f/buy-or-build-when-to-buy.png)
Hva egenutviklig faktisk innebærer: et eksempel fra Eletive
I sommer bygde salgsteamet vårt et AI-verktøy som hjelper selgerne med å velge hvilke selskaper de bør kontakte, og som utkaster den første meldingen.
Det kobler verktøy vi allerede betaler for: HubSpot som CRM og kilde til sannhet, Apollo for selskapsdata, n8n for arbeidsflyter og Claude på toppen. Hver morgen oppdateres dataene basert på nylige hendelser og tidligere samtaler. AI-en velger ut selskapene som gir mest mening å kontakte og utformer en tilpasset melding. En selger finjusterer meldingen før den havner i e-postkøen.
Dette er sannsynligvis formen mange interne byggprosjekter vil ta fremover. Ikke «vi bygde vårt eget system», men «vi koblet sammen fire ting vi allerede eier for å løse et problem ingen selger et produkt for».
Den første prototypen tok noen dager, og den imponerte. Det føltes 90 % ferdig. De siste 10 % er der det virkelige arbeidet er. Hva skjer når en kontakt er i ferd med å forlate selskapet sitt? Når to selskaper er koblet sammen? Unntakshåndtering, datakvalitet, responstider, korrekt datainnlasting hver gang – ikke de fleste gangene – og opplæring tar tid.
Så langt har det tatt hundrevis av timer og to personer som jobber med det nesten på heltid. Mer enn vi håpet. Det er likevel verdt det. Målet er 25 % høyere output per selger. Det ga mening fordi vi hadde ressursene og dataene var unike for oss.
Lærdommen: å nå den første seieren er enkelt nå. Å nå den hundrede er akkurat like krevende som det alltid har vært.
Gikk du glipp av sesjonen? Se hele opptaket her.
Verktøyene ble enklere. Jobben rundt dem ble det ikke.
Å bygge handler om langt mer enn kode. Dere blir prosjektledere: omfang, rekkefølge, unntak, testing og utrulling. Dere eier dataarkitekturen: hvor dataene bor, hva som er kilden til sannhet, og hva som skjer når to systemer er uenige. Dere blir også produktledere, der dere tydelig definerer nøyaktig hvordan løsningen skal fungere – inkludert alle kanttilfeller dere helst vil slippe å tenke på.
AI bygger nøyaktig det dere ber om. Det krevende er å vite hva dere skal be om.
Ingen av valgene er én enkelt kostnadslinje
Bygger dere selv, må dere telle med hosting og modellkostnader, sikkerhetsrevisjoner, juridisk godkjenning, testing og endringsarbeid. Dere må telle med vedlikehold når API-en endrer seg under dere, og hvem som håndterer support. Dere bør også telle med «bus-faktoren»: hva skjer hvis personen som bygde løsningen slutter? Kanskje den største kostnaden av alle er alternativkostnaden. Driver dere en hamburgerrestaurant, brukes tiden best på burgerne.
Kjøper dere løsningen, har den også skjulte kostnader. Integrasjon, implementering, datamigrering, adopsjon og opplæring, administrasjonstid, leverandørstyring og byttekostnader hvis det ikke fungerer.
:format(png)/f/288714721386412/1401x538/4ee7ac5c6d/buy-or-build-neither-side-is-one-line-item.png)
Det er kostnader på begge sider. Den virkelige forskjellen er ikke pengene. Det er hvem som bærer kompetansen og risikoen.
Fremtiden er kjøpe og bygge
De fleste HR-team vil sannsynligvis kjøpe verktøy til kjernevirksomheten: ansattengasjement og Performance Management, rekruttering, HRIS, tids- og lønnssystemer. Disse verktøyene gir dere grensesnittet for daglig arbeid, datahåndtering og compliance, samt leverandørekspertise og support.
Oppå dette kommer et AI-lag som trygt kan få tilgang til dataene. Og oppå det igjen bygger dere egne interne applikasjoner og et analyselag som knytter systemene sammen. Mange selskaper beveger seg allerede i denne retningen.
Hvor du starter mandag morgen
Noen praktiske tips fra spørsmålsrunden:
Sjekk hva dere allerede betaler for. Bruker dere Microsoft eller Google, har dere sannsynligvis allerede AI-verktøy dere kan eksperimentere med.
Start med problemet, ikke verktøyet. Beskriv problemet for en AI-assistent og spør hvordan det kan løses.
Se på arbeidsflytverktøy. Å flytte data fra ett system til et annet er ofte der de første raske gevinstene finnes.
Hold det første prosjektet lavrisiko. Velg noe uten persondata. Når persondata er involvert, trekk inn juridisk avdeling tidlig.
Gikk du glipp av arrangementet? Se hele opptaket av AI in HR 2026: From People Insights to Business Impact



























:format(png)/f/288714721386412/1920x1080/c30273d5a6/blog_hero_buy-or-build-how-hr-leaders-can-make-smarter-tech-decisions-in-the-age-of-ai.png)
:format(png)/f/288714721386412/1920x1080/9c4553436b/blog_hero_the-people-leader-s-ai-playbook-five-principles-for-putting-ai-to-work-in-hr.png)
:format(png)/f/288714721386412/1920x1080/8e3fef2eca/blog_hero_how-to-turn-people-insights-into-business-impact-with-ai.png)
:format(png)/f/288714721386412/1920x1080/1a190a1f2e/blog_hero_from-measuring-engagement-to-acting-on-it-inside-eletive-s-ai-roadmap.png)