En etablert bedrift som kjøper utvikling, vet som regel hva den vil ha og har råd til å ta feil en gang. En oppstartsbedrift har sjelden noen av delene. Pengene er begrenset, produktet er ikke ferdig tenkt, og feil valg av partner kan koste mer enn selskapet tåler.
Derfor er kriteriene litt andre enn de vanlige.
Se etter noen som sier nei
Det høres bakvendt ut, men en leverandør som sier ja til alt, er et dårlig tegn.
Den mest verdifulle egenskapen tidlig er at noen tør å si at halve funksjonslista bør vente, at ideen bør testes før den bygges, eller at dere ikke trenger en app i det hele tatt. Det koster dem penger å si det, og det er nettopp derfor det er verdt noe.
En leverandør som bare bygger det dere ber om, er grei å ha når dere vet nøyaktig hva dere vil. Som startup vet dere som regel ikke det ennå, og da trenger dere noen som stiller spørsmål.
Sjekk om de kan levere lite
Mange utviklingsmiljøer er innrettet mot større prosjekter med lengre løp. Det er en dårlig match for et selskap som skal ut i markedet fort med en avgrenset første versjon.
Spør konkret hva de ville bygget først hvis dere bare hadde tre måneder. Svaret forteller deg om de tenker i leveranser eller i faser. Får dere et svar som handler om å avklare og spesifisere i to måneder, er det feil partner for en startup.
Avtalevilkårene som faktisk betyr noe
Dette er det punktet vi ser oppstartsselskaper angre mest på, fordi konsekvensene kommer først når selskapet begynner å bli verdt noe.
Hvem eier koden? Svaret bør være dere, uten forbehold, og det bør stå skriftlig. For et oppstartsselskap er dette ofte den største enkeltverdien i selskapet, og det kommer opp ved enhver investering eller oppkjøp. En investor som oppdager at leverandøren eier deler av produktet, vil ikke være begeistret.
Hvor ligger koden, og har dere tilgang? Dere bør ha tilgang til kildekoden underveis, ikke bare ved avslutning. Det er også en forsikring hvis samarbeidet skulle ta slutt.
Hvem eier kontoene? Utviklerkontoer hos Apple og Google, domenet, og tjenestene appen bruker bør stå registrert på selskapet deres. Vi har sett selskaper som ikke kom til sin egen app fordi kontoen sto på en tidligere leverandør.
Og hva skjer hvis dere vil bytte? En ryddig leverandør har et svar på det som ikke innebærer at dere må bygge på nytt.
Spør hvem som faktisk gjør jobben
Selskapet dere snakker med i salgsmøtet er ikke alltid de samme som skriver koden. Be om å få møte utvikleren før dere signerer.
For et lite selskap betyr kjemi og kommunikasjon mer enn på et stort prosjekt, fordi dere kommer til å ha tett kontakt og ta mange beslutninger raskt.
Hva dere bør ha klart før første møte
Dere trenger ikke en kravspesifikasjon. Dere trenger å kunne beskrive hvilket problem dere løser, for hvem, og hva de gjør i dag i stedet.
Har dere snakket med noen i målgruppen, ta med hva de sa. Det er den mest nyttige informasjonen dere kan komme med, og den gjør at samtalen handler om riktig ting fra start.
Hva det koster å komme i gang
En fokusert første versjon for begge plattformer ligger på 50 000 til 100 000 og tre til fem uker hvis den klarer seg uten innlogging, og på 80 000 til 300 000 og seks til fjorten uker med innlogging og backend. En klikkbar prototype alene er et arbeid på noen uker og en brøkdel av summen.
Du kan sette sammen et anslag i priskalkulatoren. Undersøk også SkatteFUNN og Innovasjon Norge tidlig, fordi flere ordninger forutsetter at du søker før arbeidet settes i gang.
Hold av penger til etter lansering
Den vanligste feilen vi ser hos oppstartsselskaper er at hele rammen går til versjon én. Hold av minst en fjerdedel til månedene etterpå, for det er da dere bygger på noe dere vet framfor noe dere tror.
Mer om hvordan dere avgrenser første versjon i MVP-apputvikling, og om hva som er verdt å bygge selv i skreddersydd eller ferdig løsning.
Vil du ta en prat?
Vi jobber med oppstartsselskaper både på prototyper og på første versjoner, og vi sier fra når vi mener dere bør teste mer før dere bygger. Se hvordan vi jobber med apputvikling, eller ta kontakt.