Izrada mobilnih aplikacija za tvrtke: cijena, proces i ključne odluke

Proces izrade mobilne aplikacije: faze i rokovi

Zamislite tim koji svako jutro otvara tri različite tablice, ručno prepisuje stanje narudžbi iz jednog sustava u drugi i tek onda može odgovoriti na jednostavno pitanje: „Koliko imamo na zalihi?" Sati se gube na ručne procese koji su u biti problem arhitekture, a ne marljivosti.

Razvoj mobilne aplikacije nije jednokratni događaj nego strukturirani proces u nekoliko faza. Razumijevanje faza unaprijed štiti vas od iznenađenja na računu i u kalendaru.

Analiza zahtjeva i definiranje opsega

Sve počinje mapiranjem korisničkih uloga, prikupljanjem funkcionalnih zahtjeva i definiranjem što ulazi u prvu verziju, a što dolazi kasnije. Nejasno definiran opseg često je glavni uzrok prekoračenja budžeta, i to prije nego što se pojave pogreške u kodu. Razlika između zahtjeva „trebamo obavijesti" i preciznog zahtjeva („administrator šalje push obavijest registriranim korisnicima koji aplikaciju nisu otvorili sedam dana; obavijest sadrži tekst i poveznicu na promotivni ekran") može značiti i nekoliko tisuća eura razlike u procjeni.

Za tipičnu poslovnu aplikaciju analiza i definiranje opsega traju jedan do tri tjedna, ovisno o broju dionika, postojećih sustava i odluka koje treba donijeti.

Dizajn, razvoj i testiranje

UX/UI dizajn prethodi razvoju jer je iteracija na prototipu višestruko jeftinija od mijenjanja gotovog koda. Pozadinski sustav, sučelja prema vanjskim servisima i prednji sloj razvijaju se usporedno kroz iteracije s redovitim demonstracijama. Testiranje nije završna faza nego trajni dio svake iteracije: funkcijsko i regresijsko testiranje te provjera na stvarnim uređajima različitih veličina i verzija iOS-a i Androida.

Uvođenje u produkciju i održavanje

Od predaje koda do objave u trgovinama obično prođe jedan do dva tjedna. Apple najčešće pregledava aplikacije oko 24 sata (vrijeme pregleda na App Storeu), a Google Play od nekoliko sati do pet dana (vrijeme pregleda na Google Playu); svaki krug odbijanja i ponovne predaje dodaje još nekoliko dana. Naknada za Apple Developer Program iznosi 99 USD godišnje (program), a Google Play naplaćuje jednokratnih 25 USD (registracija).

Nakon objave počinje stvarni tekući trošak: za sigurnosne zakrpe, ažuriranja za nove verzije iOS-a i Androida te nadzor sustava okvirno planirajte 15 do 20% početnog razvojnog budžeta godišnje. To je smjernica za planiranje, a stvarni iznos ovisi o broju integracija i tempu promjena platformi. Hosting, naknade trgovina i vanjske licence dolaze povrh toga.

Native ili cross-platform: kako odabrati pravu arhitekturu

Arhitektura je poslovna odluka, a ne tehnička rasprava. Pogrešan izbor može znatno povisiti troškove migracije u kasnijoj fazi i odgoditi izlazak na tržište.

Kada native razvoj ima smisla

Native pristup opravdan je za zahtjevnu grafiku, duboku integraciju s hardverom poput Bluetootha i profesionalne kamere te za aplikacije koje moraju odmah koristiti najnovije sistemske mogućnosti. Ključna posljedica: iOS i Android zahtijevaju odvojene baze koda, što znači dvostruki razvoj, dvostruko testiranje i dvostruki trošak održavanja svake izmjene.

Flutter i React Native: kada cross-platform smanjuje trošak i rok

Za većinu poslovnih aplikacija, korisničkih portala, rezervacijskih sustava i internih alata cross-platform pristup znači 25 do 50% niži razvojni trošak u usporedbi s dvije odvojene native aplikacije, uz 70 do 95% zajedničke baze koda. To su uobičajeni okvirni rasponi iz prakse, a stvarni omjer ovisi o funkcijama, hardverskim zahtjevima i iskustvu tima.

Konkretnije: funkcionalnost čiji razvoj za dvije native platforme traje deset radnih dana može u Flutteru ili React Nativeu biti gotova za šest do sedam dana, pod uvjetom da ne ovisi o rijetkim hardverskim mogućnostima. React Native je praktičniji ako tim već poznaje TypeScript i React ekosustav; Flutter donosi konzistentniji vizualni identitet i predvidive performanse na svim veličinama ekrana.

Za MVP koji mora istodobno izaći na iOS i Android, cross-platform je gotovo uvijek pametan prvi korak. Native pristup ostavite za kasnije faze, kada specifična hardverska integracija ili maksimalne performanse postanu stvarna poslovna potreba, a ne pretpostavka.

Cijena izrade mobilne aplikacije u 2026.

Okvirni rasponi za cross-platform razvoj, bez PDV-a, izgledaju ovako. Riječ je o informativnim procjenama tržišta za planiranje budžeta, a ne o Noverovom cjeniku; konačna cijena ovisi o opsegu dogovorenom nakon pregleda zahtjeva.

• Jednostavna aplikacija (3.000 do 6.000 EUR): nekoliko ekrana, prikaz sadržaja, osnovni obrasci, push obavijesti.
• Srednje složena aplikacija (6.000 do 15.000 EUR): korisnički računi, pozadinski sustav, rezervacije ili narudžbe, sučelja prema vanjskim servisima, plaćanje.
• Kompleksna aplikacija (15.000 do 30.000 EUR+): više korisničkih uloga, tržišnica, razmjena poruka u stvarnom vremenu, karte, složene integracije.
• Potpuno prilagođena aplikacija s ERP/CRM integracijom (30.000 do 80.000 EUR+): napredni pozadinski sustav i više povezanih poslovnih sustava.

Što podiže trošak iznad početne procjene

Nejasno definirani zahtjevi najčešći su uzrok prekoračenja, odmah iza promjena opsega usred razvoja. Složene integracije sa sustavima čija sučelja nisu dokumentirana, rad u stvarnom vremenu poput razmjene poruka i geolokacije te regulatorna usklađenost svaki za sebe mogu znatno pomaknuti konačni iznos. Zato proračun planirajte s rezervom za nepredviđene stavke.

Kako izračunati povrat ulaganja prije razgovora s agencijom

Uzmite koliko sati tjedno zaposlenici troše na ručne procese koje aplikacija zamjenjuje i pomnožite s prosječnim satnim troškom te s 52 tjedna: godišnja ušteda = sati tjedno × 52 × satni trošak. Osnovni povrat ulaganja je godišnja ušteda − trošak razvoja, podijeljeno s troškom razvoja, puta 100, a rok povrata je trošak razvoja podijeljen s mjesečnom uštedom.

Primjer: tim troši 30 sati tjedno na ručne procese, a prosječni satni trošak je 15 EUR. Godišnja ušteda iznosi 30 × 52 × 15 = 23.400 EUR. Ako razvoj košta 20.000 EUR, povrat u prvoj godini je oko 17%, a ulaganje se vraća za približno deset mjeseci. Primjer je ilustrativan i služi kao okvir za vlastiti izračun.

Dodajte i drugu komponentu: prihode od novih kanala poput mobilnih narudžbi ili programa vjernosti koje bez aplikacije ne možete ostvariti. Te je prihode teže procijeniti pa ih planirajte konzervativno i odvojeno od uštede na ručnom radu.

Integracije s poslovnim sustavima: gdje se krije prava vrijednost

Aplikacija sama po sebi rijetko mijenja poslovanje. Integracija s postojećim ERP-om, CRM-om ili sustavom na prodajnom mjestu automatizira procese i uklanja ručni unos podataka.

ERP, CRM i POS: što morate znati unaprijed

Uspješnost integracije ovisi o kvaliteti dokumentacije sustava s kojim se aplikacija spaja. Tipični scenariji uključuju aplikaciju koja povlači stanje zaliha iz ERP-a, CRM koji se automatski ažurira kad kupac izvrši radnju u aplikaciji te POS koji prima narudžbe izravno iz aplikacije bez ručnog unosa. Izvođač mora što ranije dobiti pristup testnom okruženju i dokumentaciji dobavljača sustava; bez toga su procjene nepouzdane.

Primjer isporuke: Balance Brunch & Bakery i Remaris POS

Za Balance Brunch & Bakery u Zagrebu razvili smo brendiranu iOS i Android aplikaciju s programom vjernosti i izravnom integracijom na Remaris POS. Gost kroz aplikaciju prati bodove i nagrade, a kupnja zabilježena na blagajni automatski se veže na njegov korisnički račun, bez ručnog evidentiranja. Aplikacija je objavljena na App Storeu i Google Playu, a projekt možete pogledati na stranici Novero Loyalty.

Primjer pokazuje i širi princip: integracija s nestandardnim sustavom nije prepreka ako izvođač ima stvarno iskustvo s takvim sučeljima i pristup dokumentaciji dobavljača.

Proširenja: od aplikacije do cjelovitog poslovnog alata

Integrirana aplikacija može rasti kroz module umjesto skupog razvoja od nule. Novero Billing pokriva obračun najma opreme na lokacijama kupca: bilježi količine i datume, primjenjuje ugovorene cijene i priprema račune za pregled prije predaje postojećem računovodstvu. Novero Loyalty dodaje program vjernosti s bodovima, nagradama i brendiranom aplikacijom, a POS povezivanje provjerava se za vašeg dobavljača. Modularan pristup smanjuje početni rizik i trošak jer rješenje gradite sloj po sloj, prema stvarnim potrebama.

Kako napisati specifikaciju projekta koja agenciji daje dovoljno informacija

Loša specifikacija jedan je od najčešćih razloga kašnjenja i prekoračenja budžeta. Ne mora biti savršena, ali mora biti dovoljno konkretna da izvođač može dati realnu procjenu umjesto okvirnog raspona koji se kasnije utrostruči.

Šest blokova koje dobra specifikacija mora sadržavati

• Cilj aplikacije i ciljani korisnici.
• Korisničke uloge i dozvole.
• Funkcionalni zahtjevi s kriterijima prihvata.
• Ekrani i korisnički tokovi.
• Integracije s vanjskim sustavima.
• Nefunkcionalni zahtjevi: broj korisnika, odziv i razina dostupnosti.

Svaki funkcionalni zahtjev treba imati jasnog korisnika, opis radnje, očekivani rezultat i kriterij prihvata. Primjer: „registrirani korisnik može kreirati narudžbu odabirom proizvoda iz jelovnika; nakon potvrde narudžba se pojavljuje u sustavu na prodajnom mjestu, a korisnik prima push obavijest s procijenjenim vremenom pripreme."

Kako opisati integracije i autentikaciju

Za svaku integraciju navedite naziv sustava, svrhu, smjer protoka podataka te dostupnost dokumentacije i testnog okruženja. Za autentikaciju jasno navedite tražite li e-mail i lozinku, jedinstvenu prijavu, društvenu prijavu ili dvofaktorsku provjeru. Izostanak ovih detalja gotovo uvijek uzrokuje reviziju ponude jer izvođač mora pretpostaviti složenost umjesto da je izmjeri.

Pitanja koja treba postaviti agenciji prije potpisa ugovora

Usporedba ponuda samo po cijeni gotovo uvijek dovodi do loše odluke. Pravi kriteriji su opseg, vlasništvo, rokovi reakcije i troškovi nakon isporuke.

Tehničko rješenje i vlasništvo

Pitajte koje tehnologije predlažu i zašto, tko je vlasnik koda, dizajna i korisničkih podataka po završetku projekta te možete li kasnije angažirati drugog izvođača. Ako izvođač izbjegava odgovor o vlasništvu koda, to je jasna crvena zastavica.

Opseg, rokovi i troškovi nakon isporuke

Provjerite je li cijena fiksna ili procjena, što točno uključuje, a što se dodatno naplaćuje: PDV, licence, hosting, edukaciju, naknade trgovina aplikacija. Pitajte kakva su godišnja i dvogodišnja ulaganja nakon lansiranja i kako se obračunavaju izmjene opsega.

Podrška, razina usluge i reference

Tražite konkretne rokove reakcije po kritičnosti incidenta, potvrdu da su sigurnosne zakrpe i ažuriranja za nove verzije operacijskih sustava uključeni u ugovor o podršci te odgovor na pitanje tko snosi odgovornost ako aplikacija prestane raditi. Razgovarajte s prethodnim klijentima, ne samo s prezentacijskim materijalima. Ponudu prihvatite kada možete jasno odgovoriti što dobivate, do kada, za koji iznos i tko je vlasnik rezultata.

Zaključak: izrada mobilne aplikacije kao mjerljivo ulaganje

Izrada mobilne aplikacije nije trošak nego ulaganje s mjerljivim povratom, ali samo ako su zahtjevi jasno definirani, arhitektura odabrana prema poslovnim potrebama, a izvođač provjeren po pravim kriterijima. Cross-platform rješenja poput Fluttera i React Nativea za većinu poslovnih scenarija znače brži izlazak na tržište i niži početni budžet. Integracije s ERP-om, CRM-om ili POS-om pretvaraju aplikaciju iz korisnog alata u poslovnu infrastrukturu koja radi umjesto vas.

Ako imate projekt u glavi ili samo popis pitanja na koja još nemate odgovore, pošaljite nam kratak opis procesa. Za prvi razgovor nije potrebna gotova specifikacija.