Izrada mobilnih aplikacija za firme: cena, proces i ključne odluke

Proces izrade mobilne aplikacije: faze i rokovi

Zamislite tim koji svakog jutra otvara tri različite tabele, ručno prepisuje stanje porudžbina iz jednog sistema u drugi i tek onda može da odgovori na jednostavno pitanje: „Koliko imamo na zalihama?" Sati se gube na ručne procese koji su u suštini problem arhitekture, a ne marljivosti.

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

Analiza zahteva i definisanje opsega

Sve počinje mapiranjem korisničkih uloga, prikupljanjem funkcionalnih zahteva i definisanjem šta ulazi u prvu verziju, a šta dolazi kasnije. Nejasno definisan opseg često je glavni uzrok prekoračenja budžeta, pre nego što se uopšte pojave greške u kodu. Razlika između zahteva „treba nam obaveštenje" i preciznog zahteva („administrator šalje push obaveštenje registrovanim korisnicima koji nisu otvorili aplikaciju sedam dana; obaveštenje sadrži tekst i link na promotivni ekran") može da znači i nekoliko hiljada evra razlike u proceni.

Za tipičnu poslovnu aplikaciju analiza i definisanje opsega traju jednu do tri nedelje, u zavisnosti od broja učesnika, postojećih sistema i odluka koje treba doneti.

Dizajn, razvoj i testiranje

UX/UI dizajn prethodi razvoju jer je iteracija na prototipu višestruko jeftinija od menjanja gotovog koda. Pozadinski sistem, interfejsi prema eksternim servisima i prednji sloj razvijaju se paralelno kroz iteracije s redovnim demonstracijama. Testiranje nije završna faza nego stalni deo svake iteracije: funkcionalno i regresiono testiranje i provera 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 prodavnicama obično prođe jedna do dve nedelje. Apple uglavnom pregleda aplikacije za oko 24 sata (vreme pregleda na App Storeu), a Google Play od nekoliko sati do pet dana (vreme 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 jednokratno 25 USD (registracija).

Nakon objave počinje stvarni tekući trošak: za bezbednosne zakrpe, ažuriranja za nove verzije iOS-a i Androida i nadzor sistema okvirno planirajte 15 do 20% početnog budžeta za razvoj godišnje. To je smernica za planiranje, a stvarni iznos zavisi od broja integracija i tempa promena platformi. Hosting, naknade prodavnica i eksterne licence dolaze povrh toga.

Native ili cross-platform: kako izabrati pravu arhitekturu

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

Kada native razvoj ima smisla

Native pristup opravdan je za zahtevnu grafiku, duboku integraciju s hardverom poput Bluetootha i profesionalne kamere i za aplikacije koje moraju odmah da koriste najnovije sistemske mogućnosti. Ključna posledica: iOS i Android zahtevaju odvojene baze koda, što znači dupli razvoj, duplo testiranje i dupli trošak održavanja svake izmene.

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

Za većinu poslovnih aplikacija, korisničkih portala, sistema za rezervacije i internih alata cross-platform pristup znači 25 do 50% niži trošak razvoja u poređenju s dve odvojene native aplikacije, uz 70 do 95% zajedničke baze koda. To su uobičajeni okvirni rasponi iz prakse, a stvarni odnos zavisi od funkcija, hardverskih zahteva i iskustva tima.

Konkretno: funkcionalnost čiji razvoj za dve native platforme traje deset radnih dana može u Flutteru ili React Nativeu da bude gotova za šest do sedam dana, pod uslovom da ne zavisi od retkih hardverskih mogućnosti. React Native je praktičniji ako tim već poznaje TypeScript i React ekosistem; Flutter donosi konzistentniji vizuelni identitet i predvidive performanse na svim veličinama ekrana.

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

Cena izrade mobilne aplikacije u 2026.

Okvirni rasponi za cross-platform razvoj, bez PDV-a, za tržišta Srbije i Hrvatske izgledaju ovako. Reč je o informativnim procenama tržišta za planiranje budžeta, a ne o Noverovom cenovniku; konačna cena zavisi od opsega dogovorenog nakon pregleda zahteva.

• Jednostavna aplikacija (3.000 do 6.000 EUR): nekoliko ekrana, prikaz sadržaja, osnovni obrasci, push obaveštenja.
• Srednje složena aplikacija (6.000 do 15.000 EUR): korisnički nalozi, pozadinski sistem, rezervacije ili porudžbine, interfejsi prema eksternim servisima, plaćanje.
• Kompleksna aplikacija (15.000 do 30.000 EUR+): više korisničkih uloga, marketplace, razmena poruka u realnom vremenu, mape, složene integracije.
• Potpuno prilagođena aplikacija s ERP/CRM integracijom (30.000 do 80.000 EUR+): napredan pozadinski sistem i više povezanih poslovnih sistema.

Šta podiže trošak iznad početne procene

Nejasno definisani zahtevi najčešći su uzrok prekoračenja, odmah iza promena opsega usred razvoja. Složene integracije sa sistemima čiji interfejsi nisu dokumentovani, rad u realnom vremenu poput razmene poruka i geolokacije i regulatorna usklađenost svaki za sebe mogu znatno da pomere konačan iznos. Zato budžet planirajte s rezervom za nepredviđene stavke.

Kako izračunati povraćaj ulaganja pre razgovora s agencijom

Uzmite koliko sati nedeljno zaposleni troše na ručne procese koje aplikacija zamenjuje i pomnožite s prosečnim troškom sata i 52 nedelje: godišnja ušteda = sati nedeljno × 52 × trošak sata. Osnovni povraćaj ulaganja je godišnja ušteda − trošak razvoja, podeljeno s troškom razvoja, puta 100, a rok povraćaja je trošak razvoja podeljen s mesečnom uštedom.

Primer: tim troši 30 sati nedeljno na ručne procese, a prosečan trošak sata je 15 EUR. Godišnja ušteda iznosi 30 × 52 × 15 = 23.400 EUR. Ako razvoj košta 20.000 EUR, povraćaj u prvoj godini je oko 17%, a ulaganje se vraća za približno deset meseci. Primer je ilustrativan i služi kao okvir za sopstveni izračun.

Dodajte i drugu komponentu: prihode od novih kanala poput mobilnih porudžbina ili programa lojalnosti koje bez aplikacije ne možete da ostvarite. Te prihode je teže proceniti, pa ih planirajte konzervativno i odvojeno od uštede na ručnom radu.

Integracije s poslovnim sistemima: gde se krije prava vrednost

Aplikacija sama po sebi retko menja poslovanje. Integracija s postojećim ERP-om, CRM-om ili POS sistemom automatizuje procese i uklanja ručni unos podataka.

ERP, CRM i POS: šta morate da znate unapred

Uspešnost integracije zavisi od kvaliteta dokumentacije sistema s kojim se aplikacija povezuje. Tipični scenariji uključuju aplikaciju koja povlači stanje zaliha iz ERP-a, CRM koji se automatski ažurira kada kupac izvrši radnju u aplikaciji i POS koji prima porudžbine direktno iz aplikacije bez ručnog unosa. Izvođač mora što ranije da dobije pristup testnom okruženju i dokumentaciji dobavljača sistema; bez toga su procene nepouzdane.

Primer isporuke: Balance Brunch & Bakery i Remaris POS

Za Balance Brunch & Bakery u Zagrebu razvili smo brendiranu iOS i Android aplikaciju s programom lojalnosti i direktnom integracijom na Remaris POS. Gost kroz aplikaciju prati bodove i nagrade, a kupovina zabeležena na kasi automatski se vezuje za njegov korisnički nalog, bez ručnog evidentiranja. Aplikacija je objavljena na App Storeu i Google Playu, a projekat možete da pogledate na stranici Novero Loyalty.

Primer pokazuje i širi princip: integracija s nestandardnim sistemom nije prepreka ako izvođač ima stvarno iskustvo s takvim interfejsima i pristup dokumentaciji dobavljača.

Proširenja: od aplikacije do celovitog poslovnog alata

Integrisana aplikacija može da raste kroz module umesto skupog razvoja od nule. Novero Billing pokriva obračun najma opreme na lokacijama kupca: beleži količine i datume, primenjuje ugovorene cene i priprema račune za pregled pre predaje postojećem računovodstvu. Novero Loyalty dodaje program lojalnosti s bodovima, nagradama i brendiranom aplikacijom, a POS povezivanje se proverava za vašeg dobavljača. Modularan pristup smanjuje početni rizik i trošak jer reš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 da bude savršena, ali mora da bude dovoljno konkretna da izvođač može da da realnu procenu umesto okvirnog raspona koji se kasnije utrostruči.

Šest blokova koje dobra specifikacija mora da sadrži

• Cilj aplikacije i ciljni korisnici.
• Korisničke uloge i dozvole.
• Funkcionalni zahtevi s kriterijumima prihvatanja.
• Ekrani i korisnički tokovi.
• Integracije s eksternim sistemima.
• Nefunkcionalni zahtevi: broj korisnika, odziv i nivo dostupnosti.

Svaki funkcionalni zahtev treba da ima jasnog korisnika, opis radnje, očekivani rezultat i kriterijum prihvatanja. Primer: „registrovani korisnik može da kreira porudžbinu izborom proizvoda iz menija; nakon potvrde porudžbina se pojavljuje u POS sistemu, a korisnik dobija push obaveštenje s procenjenim vremenom pripreme."

Kako opisati integracije i autentikaciju

Za svaku integraciju navedite naziv sistema, svrhu, smer protoka podataka i dostupnost dokumentacije i testnog okruženja. Za autentikaciju jasno navedite tražite li e-mail i lozinku, jedinstvenu prijavu, društvenu prijavu ili dvofaktorsku proveru. Izostanak ovih detalja gotovo uvek uzrokuje reviziju ponude jer izvođač mora da pretpostavi složenost umesto da je izmeri.

Pitanja koja treba postaviti agenciji pre potpisa ugovora

Poređenje ponuda samo po ceni gotovo uvek dovodi do loše odluke. Pravi kriterijumi su opseg, vlasništvo, rokovi reakcije i troškovi nakon isporuke.

Tehničko rešenje i vlasništvo

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

Opseg, rokovi i troškovi nakon isporuke

Proverite da li je cena fiksna ili procena, šta tačno uključuje, a šta se dodatno naplaćuje: PDV, licence, hosting, obuku, naknade prodavnica aplikacija. Pitajte kakva su godišnja i dvogodišnja ulaganja nakon lansiranja i kako se obračunavaju izmene opsega.

Podrška, nivo usluge i reference

Tražite konkretne rokove reakcije prema kritičnosti incidenta, potvrdu da su bezbednosne zakrpe i ažuriranja za nove verzije operativnih sistema uključeni u ugovor o podršci i odgovor na pitanje ko snosi odgovornost ako aplikacija prestane da radi. Razgovarajte s prethodnim klijentima, ne samo s prezentacionim materijalima. Ponudu prihvatite kada možete jasno da odgovorite šta dobijate, do kada, za koji iznos i ko je vlasnik rezultata.

Zaključak: izrada mobilne aplikacije kao merljivo ulaganje

Izrada mobilne aplikacije nije trošak nego ulaganje s merljivim povraćajem, ali samo ako su zahtevi jasno definisani, arhitektura izabrana prema poslovnim potrebama, a izvođač proveren po pravim kriterijumima. Cross-platform reš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 umesto vas.

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