Hvor mye koster det å utvikle og bygge en app som Uber? Dette spørsmålet, og andre lignende problemstillinger, møter vi på opptil flere ganger hver eneste dag. Svaret er alltid det samme – det kommer an på!

Ubers forretningsmodell har inspirert til utvikling av mange andre lignende tjenester innen forskjellige industrier. Disse nye tjenestene posisjonerer seg for å raskt kunne dra nytte av trender innen tilbud og etterspørsel. Denne nye trenden kan utfordre selv de aller best etablerte og erfarne aktørene innen sitt felt. Måten de nye tjenestene kombinerer online og offline, og involverer flere forskjellige aktører, gjør at de kan være vanskelige å designe, administrere, og skalere.

Relatert lesestoff – The Uber Business Model

Flere entreprenører og bedrifter som ønsker å bygge lignende plattformer for andre varer eller tjenester, bruker ofte denne anolgien for å beskrive sine ønsker – og nettopp derfor mottar vi dette spørsmålet ofte. Det er mange variabler som spiller inn når en skal gjøre et korrekt estimat. Vi tar en rask gjennomgang av disse kriteriene, for å forstå hva som kreves for å designe en Uber-type applikasjon for en X-plattform. Dette vil også gi bedre forståelse for hvorfor vi valgte en modulær tilnærming, ved å designe en MBaaS (Mobile Backend as a Service) for å kunne skape merverdi for entreprenører og bedrifter som ønsker å skape noe stort.

A) Har du samme forretningmodell som Uber? Hvis ikke, hvordan skiller den seg fra Ubers modell?

Modeller som Uber kan best beskrives som en plattform som tilbyr en tjenesten etter behov, hvor etterspørselen skjer på nett, mens tjenesten tilbys utenfor nettet. Vi finner allikevel mange variasjoner når vi begynner å analysere forskjellige implementeringer av denne modellen.

Når vi snakker om en app som Uber:
1. Antar vi at tilbudet av tjenestene er løst bundet sammen med plattformen, og at plattformen benyttes for å gjøre tilbyderne mer tilgjengelige.
2. Snakker vi om umiddelbare kjøp, og ikke fremtidige kjøp.
3. Forutsetter vi at kjøperen ikke velger tilbyder manuelt, men en tilbyder velges ut basert på preferanser og andre variabler.
4. Er det en standardisert flyt av tjenester/varer, og det involverer ikke at kunden gjør et valg basert på et sett av variabler.

De aller fleste nye plattformer vil ha flere betydelige forskjeller fra Ubers modell som beskrevet ovenfor. Slike hensyn vil ha direkte innflytelse på hvordan du tar avgjørelser når det kommer til identitet, betaling, matching, etc. når du designer produktet ditt, og dette vil naturligvis igjen avgjøre kostnadene når du definerer MBP.

Relatert lesestoff On-demand startup in mind? Success depends on these planning factors – Venture Beat

Om du holder på med å skissere forretningmodellen din, og gjerne vil ha mer utfyllende materiale på området, kan denne eBoken som omtaler bygging av forretningmodeller for On-Demand oppstarter være nyttig – eBok: Understanding the On Demand Business Model

B) Innen hvilket område ønsker du å etablere deg?

Ønsker du å tilby tjenester som taxi- eller limousinturer, eller er det et annet felt du ønsker å etablere deg innen? Om du ønsker å finne en løsning for å utvikle din eksisterende taxi- og limousintjeneste med en Uber-aktig modell, finnes det flere bedrifter som tilbyr løsninger for deg. Om du sikter litt bredere, og f.eks. vil tilby generell transport (løsninger for shuttle/event/samkjøring med barn/eldre/bedrifter etc. som din målgruppe), eller levering, hjemmetjenester, skjønnhetsbehandling osv., kan ting bli litt mer komplisert, og det kan være vanskelig å finne eksisterende skript som fungerer.

Vi har arbeidet med dette problemet de seneste 15 månedene, og vi har utarbeidet en god og funksjonell løsning. Det grunnleggende for de aller fleste tjenester vil være moduler som matching, planlegging, sporing, betaling, omtaler, varsler, aggregering og registrering. Derfor har vi skapt kodeblokker for backend – eller en MBaaS-basert arkitektur – som er bygget for å kunne ta hånd om de aller fleste scenarioer man støter på med en On-Demand forretningmodell. For mer informasjon om valg som gjøres når en definerer disse modulene, kan du laste ned denne eBoken som omtaler byggeklossene som benyttes for On-Demand-teknologi.

Det underliggende premisset er at frontend delen av tjenesten må utvikles for hver enkelt plattform. Den funksjonelle og allsidige backend-arkitekturen sørger for at vi ikke trenger å finne opp hjulet på nytt når det kommer til dypere tilpasninger av de enkelte tjenestene.

C) Utviklingen innen On-Demand plattformer

Når en snakker om apper lik Uber, bør en også tenke på hvordan oppstartbedrifter utvikler seg. Alle tjenester – både de som ligner på Uber, og de som ikke gjør det – går gjennom de 4 trinnene som nevnes nedenfor. Ettersom de aller fleste On-Deman plattformer baseres på nettverkeffekten, og at det første hinderet er den klassiske høna og egget etc., er det desto viktigere å ha en god forståelse av disse stegene. Et spørsmål som så stilles er om vi skal se på en modell som gjør mindre enn 1000 transaksjoner om dagen, eller om vi skal se på et globalt system bygget på et rammeverk av optimalisert logistikk.

Det er viktig å finne riktig fokusområde i de forskjellige stegene i plattformens evolusjon. Det første målet må være å finne fram til et funksjonelt produkt som treffer hovedfunksjonen. Så snart MBP-en er klar, vil neste mål være å finne det perfekte produktmarkedet. Når produktmarkedet er innen rekkevidde, vil neste hinder være å finne enhetsøkonomien (kundeanskaffelseskost/livstidsverdi) mens du fortsatt forbedrer kohortdataen. Denne fasen vil ofte involvere mye fokus på å bygge metoder for god analyse.

Den totale kostnaden for utviklingen av en app som Uber:

Du har nå fått en forståelse for at det er mange variabler som spiller inn når vi skal avgjøre kostnaden for utviklingen av en app som Uber. Men vi gjør allikevel et forsøk på å estimere beløpet. Når en skal bygge MBP for en slik On-Demand plattform, må en bygge brukergrensesnitt for både nett og mobil, for både tilbyder og kjøper. I tillegg vil dette vanligvis innebære parallell utvikling for både iOS og Android. Et annen viktig komponent er nervesenteret/administrasjonspanelet, som også fungerer som CRM og instrumentbord for styring av kritiske operasjoner. Det hele bindes sammen av API-ene, som sitter på toppen av de sentrale databasene og kontrollerer logikken – som en del av backend-rammeverket som driver skyen.

Om vi tar for oss en skalerbar plattform som kan håndtere 500-1000 transaksjoner om dagen, vil kostnadene ligge på mellom $100k-$300k for et MBP. Variasjoner innenfor dette estimatet avhenger primært av 4 faktorer –
1. Antall aktører
2. Antall plattformer for første lansering
3. Forretningmodellens kompleksitet
4. Geografisk plassering for teamet som utvikler og bygger produktet. Timepriser varierer fra $20 -$60 (i deler av India/Øst-Europa/Sørøst-Asia) til $80 -$150 (i deler av Vest-Europa/USA)

Med en modulær tilnærming som drar fordel av forhåndsbygd IP, kan vi på Future Work Techonolgies redusere tiden og kostnaden med omtrent 30%. Ettersom vårt ingeniørteam holder til i India, har vi i tillegg muligheten til å holde kostnadene lave, samtidig som vi kan tilby god flyt i kommunikasjonen med våre in-house team. Vi har utviklet vår bedrift gjennom over 5 år med distribuert produktutvikling. Den totale kostnaden for et MBP kan med vår tilnærming komme helt ned i 80 000 – 40 000 USD. Ikke bare kan vi tilby gode prisvilkår – vår største styrke er erfaringene vi har med oss etter å ha utviklet mer enn 50 On-Demand plattformer for forskjellige industrier, i forskjellige geografiske områder. Basert på disse erfaringene kan vi hente ut informasjon fra vår playbook som inneholder både direkte og indirekte relevante data fra våre mange vellykkede implementeringer.

Vil du ha en nøyaktig kostnadsanalyse for din idé? Kontakt oss nå!