Pređi na sadržaj

Proizvod · maj 2026. · 8 min čitanja

Demo verzija ili aplikacija spremna za produkciju: šta se zaista menja

Posao koji stoji između aplikacije koja dobro izgleda na demonstraciji i one koja može da podnese prave korisnike.

Autor: , osnivač i vodeći React Native developer u MakeFast-u

Demo verzija je napravljena da preživi jedan put kroz aplikaciju, koji prolazi neko ko zna gde ne treba da dodirne. Produkcija je sve ostalo.

Ovo je najčešći izvor iznenađenja u projektima aplikacija: osnivač vidi nešto što izgleda gotovo i razumno zaključi da je projekat skoro završen. Obično nije, a preostali posao je nevidljiv upravo zato što se sastoji od situacija u koje demo nikada nije ušao.

Evo šta se zaista menja.

Demo pretpostavlja da sve radi

U demo verziji mreža je brza, plaćanje uspeva, otpremanje se završava, a korisnik upisuje ono što se od njega očekivalo. U produkciji svako od toga ima slučaj neuspeha koji zahteva odluku.

SituacijaPonašanje u demo verzijiŠta produkcija zahteva
Mreža se prekine usred akcijeNikada se ne dešavaPonovni pokušaj, red čekanja ili jasna poruka - i bez dvostruke naplate
Plaćanje ne uspeNe prikazuje seStanje iz kog korisnik može da nastavi i zapis koji možete da uskladite
Korisnik napusti aplikaciju usred tokaNije testiranoStanje se vraća po povratku ili se tok čisto prekida
Prazan nalog, prvo pokretanjeUnapred ubačeni podaciPrazno stanje koje objašnjava šta dalje
Dva uređaja, isti nalogJedan uređajOdgovor koji se može odbraniti o tome koja izmena pobeđuje
Sesija istekneSesija nikada ne ističeTiho osvežavanje ili ponovna prijava koja ne gubi rad

Ništa od ovoga se ne vidi pri prolasku kroz aplikaciju. Sve to je razlika između aplikacije kojoj ljudi veruju i one koju obrišu.

Bezbednost od nepostojeće postaje obavezna

Demo verzije se redovno isporučuju sa pristupnim podacima u klijentu, bez prave autorizacije i sa API-jem koji veruje svemu što mu aplikacija pošalje. To je razuman kompromis za prototip i neprihvatljiv onog trenutka kada postoje pravi nalozi.

Produkcija zahteva autorizaciju koja se sprovodi na serveru, a ne skriva u interfejsu, tajne podatke čuvane negde gde ih paket aplikacije ne može izložiti i proveru svega što korisnik može da pošalje. Ako je demo brzo napravljen - a posebno ako ga je uglavnom generisao AI - pretpostavite da ništa od ovoga ne postoji dok neko ne proveri.

Podaci prestaju da budu potrošni

U demo verziji možete da resetujete bazu kad god se njen oblik promeni. Kada postoje pravi korisnici, svaka promena šeme mora da prenese podatke koji već postoje, a da ništa ne izgubi.

Zato modelovanje podataka zaslužuje pravu pažnju pre lansiranja, a ne posle. To je jedna od retkih odluka koju je drastično skuplje kasnije menjati, a nevidljiva je svima koji gledaju ekrane.

Produkcija donosi i obaveze koje prototip nema: rezervne kopije za koje ste zaista proverili da mogu da se vrate, način da obrišete podatke korisnika kada to zatraži i odgovor koji se može odbraniti o tome šta prikupljate i zašto.

Morate da znate kada se pokvari

U demo verziji vi gledate. U produkciji se pad desi na nečijem telefonu u drugoj zemlji, a vi to saznate iz recenzije sa jednom zvezdicom, osim ako niste napravili način da saznate ranije.

To znači prijavljivanje padova, praćenje grešaka na serveru i dovoljno analitike da se utvrdi da li je odustajanje greška ili problem dizajna. To je mala količina posla koja menja koliko brzo se rešava svaki budući problem.

Isporuka postaje proces

Demo verzija se napravi na laptopu i pokaže sa tog laptopa. Produkciona aplikacija mora da se builduje ponovljivo, ispravno potpiše, pošalje sa metapodacima i snimcima ekrana koji zadovoljavaju pregled i objavi na način koji može da se poništi.

Pregled u prodavnicama zaslužuje posebno planiranje. Odbijanja su česta i često se tiču stvari koje nemaju veze sa kodom - nedostaje tok za brisanje naloga, izjava o privatnosti se ne poklapa sa ponašanjem, dozvola se traži bez obrazloženja. Svaki krug košta dane.

Objava, smernice za pregled i prepiska sa Apple-om i Google-om deo su projekta u našim uslugama razvoja mobilnih aplikacija.

Kako o tome razgovarati sa developerom

Ako vam neko pokaže demo i kaže da je aplikacija skoro gotova, ova pitanja će vam reći koliko je zaista blizu:

  • Šta se dešava ako se mreža prekine na pola ove akcije?
  • Gde se trenutno čuvaju API ključevi?
  • Ako pozovem ovaj endpoint kao drugi korisnik, šta me sprečava da vidim njegove podatke?
  • Šta radimo kada se model podataka promeni posle lansiranja?
  • Kako ćemo znati ako ovo sutra padne nekom korisniku?
  • Ko može da izbuilduje i objavi ovo i da li je to negde zapisano?

Odgovori poput „to bismo dodali kasnije" su u redu i iskreni. „To nije problem" obično znači da o tome niko nije razmišljao.

Ništa od ovoga ne znači da su prototipovi greška. Napraviti nešto grubo da biste saznali da li to iko želi je upravo ispravno. Greška je pretpostaviti da je gruba verzija veći deo puta do prave.

Ako imate prototip koji treba da postane pravi proizvod, upravo za to služi naš MVP za 30 dana.

Česta pitanja

Koliko posla ostaje posle funkcionalne demo verzije?

Veoma zavisi od toga šta je demo preskočio, ali redovno je to više nego što osnivači očekuju - često uporedivo sa poslom koji je već urađen. Preostali trud je skoncentrisan na obradu grešaka, autorizaciju, migraciju podataka, nadzor i objavu, a ništa od toga se ne vidi pri prolasku kroz aplikaciju.

Može li prototip da postane pravi proizvod ili ga treba ponovo napraviti?

Često može da se zadrži, posebno ako je model podataka ispravan, a struktura razumljiva. Odluka obično zavisi od sloja podataka, a ne od ekrana, jer je interfejs relativno jeftino ponovo uraditi, dok se pogrešan model podataka širi kroz sve. Revizija je uobičajen način da se ova odluka donese.

Šta aplikaciju čini spremnom za produkciju?

U praksi: autorizacija koja se sprovodi na serveru, tajni podaci van klijenta, razumna obrada otkaza mreže i plaćanja, model podataka koji može da se migrira, proverene rezervne kopije, prijavljivanje padova i grešaka i ponovljiv proces buildovanja i objave. Funkcije su retko ono što nedostaje.

Zašto aplikacije bivaju odbijene na App Store-u?

Većina odbijanja se ne tiče kvaliteta koda. Česti razlozi su nedostatak brisanja naloga, izjave o privatnosti koje se ne poklapaju sa onim što aplikacija prikuplja, dozvole tražene bez jasnog razloga, nepotpuni metapodaci ili recenzent koji ne može da pristupi funkciji iza prijave. Planiranje za to štedi dane.

Još tekstova

Pogledajte sve

Imate projekat na umu?

Recite nam šta pravite, a mi ćemo vam se javiti sa obimom, rokom i cenom.