Koliko košta izrada mobilne aplikacije?

Svaki osnivač ovo pita prvo, a svaki iskren odgovor počinje isto: zavisi od toga šta pravite. To zvuči kao izbegavanje odgovora. Nije. Raspon za „mobilnu aplikaciju" toliko je širok da je beskoristan, jer taj izraz pokriva i alat za rezervacije sa dva ekrana i marketplejs sa plaćanjima, porukama i problemom prevara.

Korisno pitanje nije koliko aplikacije koštaju uopšte. Korisno pitanje je šta pomera cenu vaše aplikacije, kako biste, kada stigne ponuda, mogli da procenite da li je promišljena ili nagađana.

Zašto se ponude za isti opis toliko razlikuju

Pošaljite isti opis na jednoj stranici petorici kompanija za razvoj mobilnih aplikacija i razlike će biti velike. Retko je razlog to što su neki pohlepni, a neki velikodušni. Razlog je to što opis na jednoj stranici ne opisuje aplikaciju - opisuje ideju, a svaki tim praznine popunjava drugačije.

Jedan tim pretpostavlja da vam treba administratorski panel. Drugi pretpostavlja da ćete sadržajem upravljati u tabeli. Jedan uračunava rad bez mreže zato što su vaši korisnici vozači. Drugi nije primetio da su vozači. Obe ponude su same po sebi dosledne. To su ponude za različite proizvode.

Zato iznos koji stigne posle razgovora o obimu vredi više od iznosa koji stigne za sat vremena. Ne zato što je niži - često je viši - već zato što je to cena za nešto konkretno.

Šest stvari koje zaista pomeraju cenu

Gotovo sve razlike u ceni razvoja aplikacija potiču sa šest mesta. Ako znate gde se vaš projekat nalazi po svakom od njih, možete otprilike da predvidite koliko će biti skup pre nego što vam iko da ponudu.

1. Koliko su funkcije duboke, a ne koliko ih ima

Broj funkcija zavarava. „Korisnički nalozi" su jedna stavka u opisu, a mogu značiti od dva dana do tri nedelje posla, u zavisnosti od toga da li vam trebaju prijava preko društvenih mreža, potvrda imejla, resetovanje lozinke, brisanje naloga, dozvole po ulogama i administratorski pregled svega toga.

Isto važi za skoro svaku funkciju koju možete da opišete jednom rečenicom. Dubina je mesto gde su sati, a dubina je upravo ono što opis izostavlja.

2. Da li vam treba bekend i koliki

Aplikacija koja sve čuva na telefonu u osnovi je jeftinija od one koja sinhronizuje podatke između korisnika. Onog trenutka kada dve osobe treba da vide iste podatke, imate server, bazu podataka, sistem za autentifikaciju i niz odluka o tome šta se dešava kada se njihove izmene sukobe.

Većini aplikacija bekend je potreban. Ali postoji stvarna razlika između bekenda koji čuva i isporučuje zapise i bekenda koji obavlja uparivanje, zakazivanje, obaveštenja i tok plaćanja.

3. Integracije sa trećim stranama

Svaki spoljni sistem sa kojim se povezujete mali je projekat za sebe. Plaćanja, mape, kalendari, provera identiteta, postojeći ERP, zastareli API koji je neko napravio 2014. godine - svaki ima svoje specifičnosti, svoje načine otkazivanja i svoje testne slučajeve koje ne možete da preskočite.

Integracije su i najčešći razlog zbog kog procene rastu usred razvoja, jer je njihovu težinu zaista teško videti spolja. API sa dobrom dokumentacijom i testnim okruženjem je dan posla. Ista funkcija nad nedokumentovanim internim sistemom može da potraje dve nedelje.

4. Koliko platformi i koliko nativne treba da budu

iOS i Android iz jedne baze koda koštaju primetno manje nego kada se svaka pravi posebno. Ali „jedna baza koda" nije besplatna: dve platforme i dalje traže sopstveno testiranje, sopstvene objave u prodavnicama i povremeno sopstveni kod tamo gde funkcija dodiruje nešto specifično za platformu.

Neke funkcije zaista zahtevaju nativni rad bez obzira na tehnologiju, što podiže cenu na jednoj ili obe platforme.

Na koju stranu ta odluka pada vredi razumeti pre nego što dobijete ponudu, a o tome smo pisali u tekstu React Native ili nativni razvoj aplikacija.

5. Koliko dizajna proizvodu treba

Interni alat koji koristi četrdeset zaposlenih bez alternative treba da bude jasan. Potrošačka aplikacija koja se bori za pažnju u prepunoj kategoriji mora da bude bolja od jasne, a to je vreme za dizajn.

Ako već imate brend, dizajn sistem ili postojeće ekrane, deo ovog troška nestaje. Ako je aplikacija vaš prvi proizvod i još ništa ne postoji, dizajn je prava stavka, a ne omot koji se dodaje na kraju.

6. Propisi i ko su vaši korisnici

Zdravstveni podaci, finansijski podaci, podaci o deci i sve što podleže strogim pravilima o lokaciji podataka dodaje posao koji se nikada ne pojavljuje na spisku funkcija: tokove saglasnosti, evidenciju aktivnosti, zahteve za šifrovanje, garancije brisanja i strožiji pregled od strane Apple-a i Google-a.

Ništa od toga nije opciono, i ništa od toga se ne vidi u aplikaciji. To je najjasniji primer dve aplikacije koje izgledaju identično, a koštaju veoma različito.

Šta obično nedostaje niskoj ponudi

Ponuda znatno niža od ostalih nije automatski loš posao. Ona je znak da vi i taj tim procenjujete različite obime, i vredi saznati koji delovi nedostaju pre nego što odlučite.

Pitajte direktno šta je od ovoga uključeno. Tim koji je razmišljao o projektu odgovoriće konkretno. Tim koji nije reći će vam da je sve pokriveno.

Fiksna cena ili naplata po satu

Naplata po satu pošteno vrednuje posao, ali svu neizvesnost prebacuje na vas. Fiksna cena neizvesnost prebacuje na izvođača, koji onda mora ili pažljivo da definiše obim ili da naduva iznos.

Nijedno nije trik. Važno je koje je od njih vezano za pisani obim. Fiksna cena bez dokumentovanog obima je fiksna cena za nešto nedefinisano, i tako zahtevi za izmene postaju svađa. Satnica bez gornje granice je otvoreno pitanje na koje ćete odgovarati mesecima.

Cena ima smisla samo kada je vezana za opis onoga što za nju dobijate.

Mi dajemo fiksnu cenu po projektu, posle uvodnog poziva, za obim koji su obe strane pročitale. Redosled je važniji od modela.

Troškovi koji stižu posle lansiranja

Izrada aplikacije je jednokratna. Njen rad nije, a taj drugi iznos osnivači najčešće izostave iz plana.

• Apple i Google developerski nalozi, koji se plaćaju godišnje.
• Hosting, baza podataka i skladištenje fajlova, koji rastu sa korišćenjem.
• Plaćene usluge trećih strana - mape, poruke, imejl, provera identiteta, infrastruktura za push obaveštenja.
• Održavanje: nove verzije operativnih sistema, ažuriranja zavisnosti i promene pravila prodavnica, najmanje dva puta godišnje.
• Podrška i sitne popravke, koje nikada potpuno ne prestaju.

Nijedan od ovih troškova pojedinačno nije veliki. Zajedno su tekući trošak, a aplikacija čiji budžet za njih ništa ne ostavlja obično polako propada dok se ne pokvari.

Šta taj tekući posao zaista podrazumeva objašnjavamo u tekstu o održavanju mobilne aplikacije posle lansiranja.

Kako potrošiti manje, a ne dobiti manje

Pouzdan način da smanjite trošak je da smanjite obim, a pouzdan način da bacite novac je da smanjite kvalitet. U ponudi deluju slično, a šest meseci kasnije se ponašaju potpuno različito.

1. Smanjite funkcije, a ne temeljnost. Manja aplikacija napravljena kako treba bolja je od velike napravljene površno, a prvu možete da proširujete.
2. Lansirajte na jednoj platformi ako su vaši korisnici uglavnom na njoj. Druga platforma je mnogo jeftinija kada prva već postoji.
3. Rano odlučite o sadržaju, tekstovima i pravnim tekstovima. Čekanje na njih je često i potpuno izbeživo kašnjenje.
4. Koristite proverene servise za rešene probleme. Plaćanja, autentifikacija i push obaveštenja nisu ono po čemu je vaš proizvod drugačiji.
5. Budite konkretni od početka. Svaka odluka doneta tokom razvoja košta više od iste odluke donete pre njega.

Ono što vredi zaštititi jeste da prva verzija bude prava. Pola aplikacije nije jeftinija aplikacija - to je trošak bez proizvoda na kraju.

Ako je cilj da prva verzija brzo stigne do korisnika i za poznat iznos, upravo to je naš MVP za 30 dana.

Da biste okvirno procenili cenu sopstvenog spiska funkcija pre nego što sa bilo kim razgovarate, koristite naš besplatni kalkulator cene razvoja aplikacije.

Kako MVP sa ovako definisanim obimom izgleda u praksi, pogledajte kako smo napravili EasyCab aplikaciju za naručivanje prevoza.

Pre nego što zatražite ponudu

Dobićete bolji iznos, i to brže, ako dođete sa četiri stvari: šta aplikacija treba da radi za posao, ko je koristi, sa čim mora da se poveže i šta mora da postoji za lansiranje, a šta može kasnije.

To nije specifikacija i niko je ne očekuje. Dovoljno je da tim postavlja korisna pitanja umesto da nagađa, i to je razlika između ponude i proizvoljnog broja.

Recite nam šta imate na umu, a mi ćemo vam se javiti sa obimom, rokom i cenom: započnite razgovor.

Česta pitanja