Å skape fremragende programvare
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Michele Cimmino
feb 27, 2026 • 10 min read
95 prosent av AI-pilotprosjektene gir ikke avkastning. That statistic, cited by aggregated industry data, should be the starting point for every conversation about AI development. Not because AI does not work — it does — but because the way most companies approach AI development is fundamentally broken.
PwCs CEO-undersøkelse fra 2026 viste at 56 prosent av administrerende direktørene oppgir at de ikke har fått noe avkastning på sine AI-investeringer. En undersøkelse fra IBMs administrerende direktør bekrefter at bare 251 av 230 AI-initiativ gir forventet avkastning, og at bare 161 av 230 har blitt utvidet til hele virksomheten. Deloittes rapport «State of AI 2026» påpeker at selv om kunstig intelligens nå går fra å være på eksperimentstadiet til å bli tatt i bruk i stor skala i bedrifter, har de fleste selskaper fortsatt ikke funnet ut hvordan de skal hente ut verdi av sine investeringer i kunstig intelligens.
Likevel finnes det et mønster som er verdt å studere midt i dette kaoset av mislykkede AI-initiativer. De 12 prosentene av konsernsjefene som faktisk tjener på kunstig intelligens har én ting til felles: de prøvde ikke å gjøre det umulige. De utviklet først et minimum viable product – et fokusert, validert proof of concept som kostet mellom 40 000 og 100 000 i stedet for 500 000 – og skalerte bare det som fungerte. De validerte hypotesen før de investerte i stor skala. De testet med ekte brukere før de erklærte seier. De bygde noe lite som faktisk fungerte før de bygde noe stort som kanskje ikke ville fungere.
Denne veiledningen handler om hvordan du kan etterligne deres tilnærming. Hvordan du kan utvikle et AI-MVP som validerer ideen din, viser reell verdi, tiltrekker seg investorer eller intern oppslutning, og legger grunnlaget for videre oppskalering – uten å bruke seks- eller syvsifrede beløp på en uprøvd hypotese.
En AI-MVP er et produkt med den minimale funksjonaliteten som trengs for å teste om AI gir reell verdi for et bestemt bruksområde. Det er ikke en prototype. En prototype viser at noe er teknisk mulig. En MVP viser at noe er kommersielt levedyktig – at virkelige brukere ønsker det, vil bruke det og er villige til å betale for det.
En AI-MVP er heller ikke en demo. Demoer er laget for å imponere. De viser det beste tenkelige scenariet med utvalgte data under kontrollerte forhold. En MVP er laget for å lære. Den viser hva som faktisk skjer når AI-en møter ekte data fra ekte brukere under virkelige forhold. Denne forskjellen er enormt viktig, fordi det er i gapet mellom demo-ytelse og produksjonsytelse at de fleste AI-prosjekter går under.
For å være konkret når det gjelder omfanget, inneholder en godt utformet AI-MVP én sentral AI-funksjon som løser det konkrete problemet du prøver å løse. Den inneholder ikke tre eller fem AI-funksjoner. Én. Den viktigste. Den som, hvis den fungerer, beviser forretningsmodellen. Den inkluderer et funksjonelt brukergrensesnitt – ikke et vakkert et, men et som er brukbart nok til at testbrukere kan fullføre oppgavene sine uten hjelp. Den inkluderer integrasjon med én eller to viktige datakilder – dataene AI-en faktisk trenger for å fungere, ikke alle datakilder du kanskje vil koble til en dag. Den inkluderer grunnleggende autentisering og, hvis relevant, flerbrukerfunksjonalitet, slik at ulike brukere eller organisasjoner kan teste uavhengig av hverandre. Den inkluderer distribusjon på skyinfrastruktur, slik at brukerne kan få tilgang til den uten å installere noe. Og den inkluderer tilstrekkelig overvåking og analyse til å måle om AI-en faktisk leverer verdi.
Det som ikke inngår, er like viktig. Det inkluderer ikke støtte for alle spesielle tilfeller. Det inkluderer ikke alle funksjonene i utviklingsplanen din. Det inkluderer ikke et fullt utarbeidet designsystem. Det inkluderer ikke infrastruktur for samsvar på bedriftsnivå (men hvis du retter deg mot det europeiske markedet, er grunnleggende GDPR-samsvar ufravikelig fra dag én, og du bør tenke på kravene i EUs AI-lov allerede fra arkitekturfasen). Det inkluderer ikke skalerbarheten som trengs for å håndtere en million brukere. Det inkluderer nok til å validere hypotesen. Verken mer eller mindre.
Å utvikle et AI-MVP som faktisk fungerer, krever disiplin – disiplin til å validere før man bygger, til å fokusere før man utvider og til å lære før man skalerer opp. Den femtrinnsprosessen som beskrives her, gjenspeiler den tilnærmingen som skiller vellykkede AI-initiativer fra de 95% som mislykkes.
Det første trinnet er problemvalidering, og dette skjer før det skrives en eneste linje med kode. Den vanligste årsaken til at AI-prosjekter mislykkes, er ikke av teknisk art – det skyldes at problemet ikke var godt nok definert, eller at AI ikke var den riktige løsningen. Problemvalidering krever at man besvarer fire spørsmål på en konkret og ærlig måte. Hva er det eksakte forretningsproblemet du løser? Hvem opplever dette problemet, og hvordan håndterer de det i dag? Hvordan ville en vellykket AI-løsning se ut fra brukerens perspektiv – hvilke beslutninger ville den ta, hvilken informasjon ville den gi, hvilke handlinger ville den automatisere? Og viktigst av alt: krever dette problemet faktisk AI, eller ville en enklere tilnærming (regelmotor, automatisering av arbeidsflyt, bedre datavisualisering) gi samme verdi til lavere kostnader og med mindre kompleksitet?
La oss bygge noe ekstraordinært sammen.
Stol på Lasting Dynamics for enestående programvarekvalitet.
Dette siste spørsmålet er ubehagelig, men avgjørende. AI tilfører verdi når problemet dreier seg om mønstergjenkjenning i komplekse data, prognoser under usikkerhet, forståelse av naturlig språk, visuell tolkning eller beslutningstaking som krever at mange variabler vurderes samtidig. Hvis problemet kan løses med deterministisk logikk – hvis-så-regler, beslutningstrær, enkle beregninger – så tilfører AI kostnader og kompleksitet uten å tilføre verdi. Ved å hoppe over denne valideringen ender bedrifter opp med AI-drevne løsninger på problemer som ikke trengte AI.
Det andre trinnet er datavurdering. AI-modeller lærer av data, og kvaliteten og tilgjengeligheten på dataene dine avgjør hva AI-en din kan oppnå. Datavurderingen stiller følgende spørsmål: Hvilke data finnes som er relevante for problemet? Hvor ligger de? Hvor rene er de? Hvor mye er det? Hvordan er de strukturert? Er de representative for forholdene AI-en vil møte i produksjonen? Kan du få tilgang til dem innenfor prosjektets tidsramme, eller vil datainnsamlingen i seg selv bli et prosjekt?
Dataklarhet er det området hvor AI-MVP-er oftest støter på uventede utfordringer. Bedrifter tror ofte at de har de dataene de trenger, bare for å oppdage at disse er spredt på tvers av systemer som ikke kommuniserer med hverandre, lagret i formater som krever omfattende bearbeiding, mangler viktige felt, er skjevt på måter som svekker modellens ytelse, eller rett og slett ikke er omfattende nok for den tilnærmingen de hadde tenkt seg. En erfaren AI-utviklingspartner vurderer dataklarheten i løpet av den første uken og justerer tilnærmingen deretter – kanskje ved å bruke overføringslæring for å kompensere for begrensede data, eller ved å bruke generering av syntetiske data for å utvide de virkelige datasettene.
Det tredje trinnet er valg av modell. I 2026 har du flere alternativer enn noensinne når det gjelder AI-komponenten i MVP-en din. Du kan bruke et API for grunnleggende modeller (OpenAI, Anthropic, Mistral, Google) som resonnementmotor, noe som gir deg kraftige funksjoner med minimal utviklingsinnsats. Du kan finjustere en åpen kildekodemodell (Llama, Mixtral, Falcon) på dine domenespesifikke data, noe som gir deg mer kontroll og lavere marginalkostnader. Eller du kan trene en tilpasset modell fra bunnen av, noe som gir deg maksimal optimalisering for ditt spesifikke bruksområde, men krever mer data, mer tid og mer ekspertise.
For de fleste MVP-er er det riktig å starte med et API for grunnleggende modeller. Utviklingskostnadene er lavest, tiden frem til implementering er kortest, og ytelsen på generelle oppgaver er utmerket. Hvis MVP-en bekrefter forretningsmodellen, kan du deretter vurdere om finjustering eller tilpasset opplæring vil forbedre ytelsen, redusere kostnadene eller imøtekomme krav til personvern i produksjonsversjonen. Å starte med den mest komplekse tilnærmingen for en MVP er det samme som å bygge et herskapshus for å teste om du liker nabolaget – dyrt, tidkrevende og helt feil.
Det fjerde trinnet er å utvikle selve MVP-en, og her er det avgjørende prinsippet å holde seg til omfanget. De mest vellykkede AI-MVP-ene utvikles på åtte til tolv uker av team på tre til fem personer. De fokuserer utelukkende på kjernen i AI-funksjonaliteten, motstår fristelsen til å legge til tilleggsfunksjoner og lanserer noe som fungerer, fremfor noe som er perfekt. Den tekniske tilnærmingen er iterativ: bygg en fungerende end-to-end-pipeline i løpet av de to første ukene (selv om AI-komponenten i utgangspunktet bare er en enkel heuristikk), og forbedre deretter AI-funksjonaliteten gradvis mens du opprettholder et fungerende produkt i hvert trinn.
Det femte trinnet er å gjennomføre tester med ekte brukere og måle resultatene opp mot forhåndsdefinerte suksessindikatorer. Det er her de fleste AI-prosjekter som har kommet så langt, likevel mislykkes, fordi de måler feil ting. De måler modellens nøyaktighet på testdatasett i stedet for brukertilfredshet. De måler teknisk ytelse i stedet for forretningsmessig effekt. De måler antall leverte funksjoner i stedet for antall løste problemer.
Effektiv MVP-testing krever at man definerer suksessmål før man utvikler MVP-en – mål som gjenspeiler forretningsverdi, ikke teknisk ytelse. Hvis AI-en skal redusere responstiden i kundeservice, må man måle responstiden. Hvis den skal forbedre feiloppdagelsen, måler du oppdagelsesfrekvensen og andelen falske positive i produksjonsforhold. Hvis den skal generere salgsmuligheter, måler du kvaliteten på mulighetene og konverteringsfrekvensen. Sammenlign disse indikatorene med referanseverdien (hvordan prosessen fungerer uten AI) og avgjør om forbedringen rettferdiggjør fortsatt investering.
Kostnaden for et AI-MVP varierer avhengig av kompleksiteten, men prisintervallet er godt dokumentert i flere bransjekilder. Her er en realistisk oversikt over kostnadene for et typisk AI-MVP utviklet av et erfarent utviklingsteam.
Fra idé til lansering lager vi skalerbar programvare som er skreddersydd til dine forretningsbehov.
Samarbeid med oss for å akselerere veksten din.
| Komponent | Anslått kostnad | Andel |
|---|---|---|
| Validering av problemer og vurdering av data | $5K – $10K | 10% |
| Arkitektur og modellvalg | $3K – $8K | 7% |
| Databehandling (rensing, datastrømmer, integrasjon) | $10K – $25K | 25% |
| Utvikling av AI/ML (modellering, finjustering, inferens) | $10K – $25K | 25% |
| Applikasjonsutvikling (brukergrensesnitt, backend, API) | $8K – $20K | 20% |
| Testing, implementering og overvåkingskonfigurasjon | $4K – $12K | 13% |
| Totalt | $40K – $100K | 100% |
Disse tallene samsvarer med intervallet 1–24–40–100 000 som fremgår av bransjeanalyser av utviklingskostnadene for AI i 2026.
Tidsplanen er like viktig. Det tar åtte til tolv uker å utvikle en AI-MVP med klart definert omfang, fra oppstart til et produkt som er klart for distribusjon. De to første ukene fokuserer på problemvalidering, datavurdering og arkitekturbeslutninger. I uke tre og fire etableres datapipeline og modellutviklingen starter. Uke fem til åtte er kjernen i utviklingssprinten, hvor applikasjonen bygges rundt AI-funksjonaliteten. Uke ni og ti brukes til testing med reelle data, måling av ytelse og identifisering av problemer. Uke elleve og tolv brukes til finjusteringer, sluttesting og implementering.
Hvis man sammenligner dette med alternativet – å utvikle et fullverdig produkt før man har validert hypotesen – blir det tydelig hvorfor MVP-tilnærmingen fungerer. En fullverdig AI-SaaS-plattform koster mellom 240 000 og 4,5 millioner dollar og tar 6–18 måneder å utvikle. Hvis hypotesen er feil – hvis brukerne ikke vil ha produktet, hvis AI-en ikke leverer tilstrekkelig nøyaktighet, hvis markedet ikke er klart – har du brukt hundretusener eller millioner av dollar på å lære noe du kunne ha lært for $50K på tre måneder.
Feilfrekvensen for 95% i AI-pilotprosjekter er ikke tilfeldig. De samme feilene gjentar seg på tvers av bransjer, bedriftsstørrelser og AI-applikasjoner. Det er billigere å oppdage dem før man setter i gang, enn å oppdage dem etter at man har investert.
Den første og vanligste feilen er å utvikle AI før man har kartlagt problemet. Dette kan ta mange former: en gründer som er betatt av en teknologi og utvikler en løsning på jakt etter et problem, et selskap som leser om en konkurrents AI-satsing og skynder seg å etterligne den uten å forstå forretningsgrunnlaget, eller et innovasjonsteam som setter likhetstegn mellom å utvikle AI og å drive innovasjon. Løsningen er enkel, men krever disiplin: bruk de to første ukene på å snakke med potensielle brukere, ikke på å skrive kode. Forstå problemet grundig før du foreslår en løsning. Hvis du ikke kan formulere det spesifikke forretningsproblemet AI-en din skal løse, den spesifikke verdien den vil skape og den spesifikke måleparameteren som vil fortelle deg at den fungerer, er du ikke klar til å utvikle.
Den andre feilen er å overse datakvaliteten. AI-modeller som er trent på dårlige data, gir dårlige resultater med høy sikkerhet, noe som er verre enn å ikke gi noen resultater i det hele tatt. Bedrifter som hopper over datavurderingen og skynder seg å trene modellene, oppdager dette på den harde måten når modellene deres presterer strålende på treningsdataene, men elendig på produksjonsdataene. Løsningen er å vurdere dataklarheten før man forplikter seg til en teknisk tilnærming, budsjettere 25% av MVP-utviklingsarbeidet til dataingeniørarbeid, og være villig til å justere tilnærmingen – inkludert valg av modell – basert på dataene man faktisk har, snarere enn dataene man ønsker man hadde.
Den tredje feilen er å overkonstruere MVP-en. Dette er perfeksjonistfellen: AI-modellen må være toppmoderne, brukergrensesnittet må være vakkert, arkitekturen må kunne håndtere en million brukere, og koden må være av bedriftsklasse. Resultatet er et prosjekt som tar ni måneder i stedet for tre, koster $300K i stedet for $80K, og gir deg den samme læringen som du ville fått fra den enklere versjonen. Løsningen er å omfavne ufullkommenhet i læringens tjeneste. MVP-ens oppgave er å validere hypotesen, ikke å vinne designpriser. Lever noe brukbart, lær av tilbakemeldinger fra brukerne, og invester i finpuss først etter at du har bekreftet at produktet er verdt å finpusse.
Den fjerde feilen er å måle på feil ting. Modellnøyaktighet er et teknisk mål, ikke et forretningsmessig mål. En modell med en nøyaktighet på 90% som sparer brukerne 30 minutter per dag, er mer verdifull enn en modell med en nøyaktighet på 98% som sparer brukerne 2 minutter per dag. Løsningen er å definere suksessmål i forretningsmessige termer før man bygger MVP-en, og å evaluere MVP-en opp mot disse målene – ikke opp mot tekniske referanseverdier som høres imponerende ut, men som ikke korrelerer med verdi.
Den femte feilen er å unnlate å planlegge for gapet mellom MVP og oppskalering. En MVP som bekrefter hypotesen, er bare begynnelsen, ikke slutten. Bedrifter som utvikler en MVP, erklærer suksess og umiddelbart setter den i full drift, opplever ofte at det som fungerte for femti testbrukere, slutter å fungere når antallet øker til fem tusen. Løsningen er å planlegge MVP-en med skalering i tankene – ved å bruke arkitekturer og plattformer som kan vokse – samtidig som man bare bygger det som trengs for validering. Dette er en balanse, ikke en motsetning: man bygger ikke for skalering, men man designer for det.
Vi designer og bygger digitale produkter av høy kvalitet som skiller seg ut.
Pålitelighet, ytelse og innovasjon i alle ledd.
Når en MVP bekrefter hypotesen – når brukerne tar den i bruk, tallene forbedres og forretningsgrunnlaget bekreftes – er neste fase oppskalering. Denne overgangen krever en egen planleggingsprosess, fordi utfordringene ved oppskalering er annerledes enn utfordringene ved validering.
Å skalere et AI-produkt krever vanligvis at man forbedrer modellens nøyaktighet ved hjelp av ytterligere treningsdata og mer sofistikerte arkitekturer, bygger inn robusthet mot spesielle tilfeller som MVP-versjonen ikke møtte, implementerer sikkerhet, samsvar og og overvåking på bedriftsnivå, å legge til integrasjoner med flere systemer og datakilder, å utvikle administrasjons- og styringsfunksjoner for organisasjonsdistribusjon, samt å bygge infrastrukturen for å håndtere belastning på produksjonsnivå på en pålitelig måte.
Kostnaden ved å skalere fra MVP til vekstprodukt er vanligvis to til fire ganger så høy som MVP-kostnaden — $100K-300K over fire til seks måneder. Skalering fra vekstprodukt til bedriftsplattform legger til ytterligere $200K–$4,5M+ over seks til atten måneder, avhengig av omfang. Dette er tallene som gjør MVP-tilnærmingen så økonomisk attraktiv: i stedet for å investere $500K+ på forhånd i en uvaliderte hypotese, investerer du $50K-80K for å validere, og investerer deretter i stor skala kun i produkter som har vist reell verdi for reelle brukere.
For bedrifter som retter seg mot det europeiske markedet, må skalering ta hensyn til lovkrav helt fra starten av. EUs AI-lov trer i kraft i sin helhet i august 2026, og ethvert AI-system som tar beslutninger som berører mennesker (ansettelser, kreditt, helsetjenester) må oppfylle kravene for høyrisiko, herunder dokumentasjon, loggføring, åpenhet og menneskelig tilsyn. Å bygge disse funksjonene inn i MVP-arkitekturen – selv om de ikke er fullt implementert i selve MVP-en – sikrer at skalering ikke krever kostbar ombygging av arkitekturen senere.
Lasting Dynamics har utviklet dusinvis av AI-MVP-er for oppstartsbedrifter og store selskaper over hele Europa. Vår tilnærming er basert på dataene: Vi validerer AI-hypotesen i løpet av seks til åtte uker med et fungerende produkt, tester det med ekte brukere, måler resultatene opp mot forretningsmål og skalerer kun det som fungerer. Vi har sett altfor mange selskaper bruke $500K på AI-prosjekter som burde vært $50K MVP-er først. Vår utviklingsprosess starter med grundig problemvalidering, investerer riktig i dataingeniørarbeid, bygger for produksjonsvirkeligheten fra første sprint og designer for europeisk regelverkssamsvar fra arkitekturfasen. Resultatet er ikke den billigste AI-MVP-en på markedet – det er den som har størst sannsynlighet for å lykkes, og i en verden hvor 95% av AI-pilotprosjekter mislykkes, er sannsynligheten for suksess den eneste metrikken som teller.
Forvandle dristige ideer til kraftfulle applikasjoner.
Let’s create software that makes an impact together.
Michele Cimmino
Jeg tror på hardt arbeid og daglig engasjement som den eneste måten å oppnå resultater på. Jeg føler en uforklarlig dragning mot kvalitet, og når det gjelder programvare, er det denne motivasjonen som gjør at jeg og teamet mitt har et sterkt grep om smidig praksis og kontinuerlige prosessevalueringer. Jeg har en sterk konkurranseinnstilling til alt jeg tar fatt på - på den måten at jeg ikke slutter å jobbe før jeg har nådd toppen, og når jeg først er der, begynner jeg å jobbe for å beholde posisjonen.
