Hvordan velge riktig utviklingspartner — 7 spørsmål du bør stille
Å velge feil utviklingspartner er en av de dyreste feilene en virksomhet kan gjøre. Her er syv konkrete spørsmål som hjelper deg å skille seriøse leverandører fra de som bare selger timer.
De viktigste spørsmålene å stille en utviklingspartner handler om prosess, kodeeierskap, kvalitetspraksis, teamsammensetning og langsiktig støtte. Her er syv konkrete spørsmål — med grønne og røde flagg for hvert svar.
Det finnes tusenvis av software-selskaper i Norge. Priser varierer med en faktor på fem. Alle lover «kvalitet», «smidig utvikling» og «moderne teknologi». Hvordan skiller du de som faktisk leverer fra de som bare selger timer?
I denne artikkelen deler vi syv spørsmål du bør stille til potensielle utviklingspartnere — og hva svarene bør fortelle deg.
Hvorfor partnervalg er kritisk
Ifølge Standish Group sin CHAOS Report 2024 feiler 66 % av alle IT-prosjekter — enten ved å overskride budsjett, levere for sent, eller ikke møte behovene. Den vanligste årsaken er ikke teknologi, men kommunikasjon og feilaktig forståelse av kravene.
En god utviklingspartner reduserer risikoen for prosjektfiasko dramatisk. En dårlig partner kan koste deg hundretusener i bortkastet utvikling, plus forsinkelsen av å starte på nytt med noen andre.
Spørsmål 1: Hvordan starter dere et nytt prosjekt?
Hva du bør høre: At de starter med å forstå forretningsproblemet — ikke teknologien. En god partner bruker tid på å kartlegge prosesser, brukere og mål før de foreslår en løsning.
Rødt flagg: Hvis de hopper rett til teknologivalg, estimater eller wireframes i første møte uten å ha forstått problemet, er det et tegn på at de vil bygge det de kan, ikke det du trenger.
I UNOS SOFTWARE AS starter vi alltid med forretningsanalyse. Da vi bygde Splice, tilbrakte vi uker på trafikkskoler før vi skrev en eneste kodelinje. Den investeringen i domeneforståelse ble avgjørende for produktets suksess.
Spørsmål 2: Hvem eier koden?
Hva du bør høre: «Du eier alt vi bygger.» Uten unntak.
Rødt flagg: Noen konsulentselskaper beholder eierskap til deler av koden — typisk «rammeverk» eller «plattformkomponenter» de gjenbruker på tvers av kunder. Dette skaper avhengighet og gjør det vanskelig å bytte partner.
Sjekkliste for kodeeierskap
| Spørsmål | Forventet svar |
|---|---|
| Eier vi all kildekode? | Ja, ubetinget |
| Får vi tilgang til Git-repositoriet? | Ja, løpende under prosjektet |
| Er koden basert på åpen kildekode? | Ja, ingen proprietære rammeverk |
| Kan vi ta koden til en annen leverandør? | Ja, uten restriksjoner |
Vi bygger alltid på åpne standarder — TypeScript, Next.js, Azure — nettopp for å sikre at kundene våre aldri blir låst til oss. Les mer om tech stacken vår.
Spørsmål 3: Hvordan håndterer dere endringer underveis?
Hva du bør høre: At de forventer endringer og har en strukturert prosess for å håndtere dem. Iterativ utvikling med tett feedback betyr at kurs justeres underveis.
Rødt flagg: «Vi leverer det som står i kontrakten.» Denne rigide tilnærmingen betyr at du må vite alt på forhånd — noe som er urealistisk for softwareprosjekter.
Også rødt flagg: «Vi tar alt underveis, ingen problem.» Grenseløs fleksibilitet uten konsekvenser betyr at scope aldri kontrolleres, og budsjettet sprekker.
Den gode middelveien er tydelige milepæler med rom for justeringer innenfor en avtalt ramme.
Spørsmål 4: Kan jeg snakke med utviklerne direkte?
Hva du bør høre: «Ja, absolutt.» I et godt partnerskap har du direkte kontakt med menneskene som bygger produktet ditt.
Rødt flagg: Hvis all kommunikasjon går gjennom en prosjektleder som «oversetter» mellom deg og utviklerne, mister du nyanser, og misforståelser oppstår. Dette er spesielt vanlig hos større konsulentselskaper der prosjektlederen gjerne selger inn det ene og utviklerne leverer noe annet.
Spørsmål 5: Hva skjer etter lansering?
Hva du bør høre: En tydelig plan for drift, vedlikehold og videreutvikling. Lansering er ikke slutten — det er begynnelsen.
Rødt flagg: Hvis partneren bare fokuserer på «prosjektet» og ikke har noe tilbud for det som kommer etter, sitter du med en løsning ingen vedlikeholder.
Hva et vedlikeholdsavtale bør dekke
- Sikkerhetsoppdateringer og avhengighetsvedlikehold
- Feilretting og support
- Overvåking og varsler
- Avtalt responstid for kritiske feil
- Mulighet for videreutvikling
Vi tilbyr vedlikeholdsavtaler for alle prosjekter vi leverer, med fokus på at løsningen forblir sikker og oppdatert over tid. Les mer om vår tilnærming til sky og infrastruktur.
Spørsmål 6: Hvordan sikrer dere kvalitet?
Hva du bør høre: Konkrete praksiser — automatiserte tester, kodegjennomganger, CI/CD-pipeline, staging-miljø. Ikke bare «vi fokuserer på kvalitet».
Rødt flagg: Fravær av automatisert testing, eller utsagn som «vi tester manuelt på slutten». Manuell testing i slutten av prosjektet er for sent og for dyrt.
Kvalitetsindikatorer
| Praksis | Hva det betyr |
|---|---|
| Automatiserte tester | Feil fanges tidlig, regresjoner forhindres |
| CI/CD-pipeline | Kode testes og deployes automatisk |
| Kodegjennomgang (code review) | Mer enn én person ser på koden |
| Staging-miljø | Du kan teste før det går i produksjon |
| TypeScript strict mode | Type-feil fanges av kompilatoren |
Spørsmål 7: Kan dere vise til lignende prosjekter?
Hva du bør høre: Konkrete eksempler med detaljer om utfordringer, løsninger og resultater. Enda bedre om du kan kontakte referanser direkte.
Rødt flagg: Vage beskrivelser uten detaljer, eller bare «vi har jobbet med store bedrifter». Størrelse sier ingenting om kvalitet.
Hva du bør spørre referansene om
- Holdt de budsjettet?
- Ble de levert til avtalt tid?
- Hvordan var kommunikasjonen underveis?
- Ville du brukt dem igjen?
- Hva ville du gjort annerledes?
Vår tilnærming
I UNOS SOFTWARE AS bygger vi ikke software for å bygge software. Vi starter med forretningsproblemet, velger teknologi som passer problemet, og leverer løsninger kundene eier fullt ut.
Vi tilbyr hele spekteret av konsulenttjenester — fra teknisk rådgivning og arkitekturvurderinger til fullstack programvareutvikling og systemintegrasjon.
Vil du diskutere et prosjekt? Ta kontakt for en uforpliktende samtale. Vi svarer gjerne på alle syv spørsmålene.
Kilder og videre lesning
- Standish Group (2024). «CHAOS Report 2024: Decision Latency Theory.» standishgroup.com
- Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley.
- McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
- Anskaffelser.no (2025). «Veileder for anskaffelse av IT-konsulenttjenester.» anskaffelser.no
- IKT-Norge (2025). «Bransjestatistikk for norsk IT-næring.» ikt-norge.no