Kā izvēlēties mobilo lietotņu izstrādātāju Latvijā

Mobilo lietotņu izstrāde atšķiras no mājaslapas izstrādes ar vienu būtisku lietu — pēc palaišanas jūs paliekat atkarīgs no diviem uzņēmumiem, kas jums nepieder. Apple un Google katru gadu maina prasības, un lietotne, kuru neviens neuztur, agri vai vēlu pārstāj darboties vai pazūd no veikala. Tāpēc izstrādātāja izvēle šeit nav tikai jautājums par cenu un dizainu, bet par to, vai jums būs partneris arī otrajā un trešajā gadā. Šajā rakstā izejam cauri visam ceļam: kur meklēt pieredzējušus iOS un Android lietotņu izstrādātājus, ko reāli pierāda portfolio, kam paliek kods un izstrādātāja konti, kad izvēlēties native un kad cross-platform pieeju, kas ir kārtīgā piedāvājumā, kā izskatās ceļš no idejas līdz publicēšanai App Store un Google Play, cik tas orientējoši maksā Latvijā un kā izvēlēties lietotņu uzturēšanas partneri. Visi skaitļi ir tirgus orientieri, nevis piedāvājums.

Kur atrast pieredzējušus mobilo lietotņu izstrādātājus

Latvijā mobilo lietotņu izstrāde ir šaurāks tirgus nekā mājaslapu izstrāde. Uzņēmumu, kuri to dara regulāri, nevis reizi divos gados, ir salīdzinoši maz, un tos var atrast trijos veidos. Pirmais un ticamākais ir caur pašiem veikaliem — atveriet App Store vai Google Play, atrodiet latviešu uzņēmumu lietotnes savā nozarē un paskatieties, kas tās ir izstrādājis. Bieži tas ir uzrakstīts lietotnes aprakstā vai atrodams pēc izstrādātāja profila.

Otrais ceļš ir ieteikumi no uzņēmumiem, kuriem lietotne jau strādā vismaz gadu. Tieši gads ir svarīgs — pirmajā mēnesī pēc palaišanas ikviens izstrādātājs izskatās labi, un tikai pēc pirmā iOS vai Android lielā atjauninājuma kļūst redzams, vai partneris atbild uz zvaniem.

Trešais ceļš ir meklēšana, un tieši šeit ir vērts būt uzmanīgam. Pieprasījumi ar frāzēm par mobilo aplikāciju izstrādi piesaista gan reālus izstrādātājus, gan starpniekus, kuri darbu nodod tālāk ārpakalpojumā. Starpnieks nav automātiski slikts, bet jums ir jāzina, kurš tieši rakstīs kodu, kurā valstī tas atrodas un kas atbildēs pēc palaišanas.

Neatkarīgi no ceļa saraksts būtu jāsašaurina līdz trim kandidātiem. Vairāk nekā trīs piedāvājumi lielākoties tikai aizkavē lēmumu, jo tos vairs nav iespējams godīgi salīdzināt.

• Meklējiet reālas lietotnes veikalos un skatieties, kas tās izstrādājis
• Prasiet ieteikumus par lietotnēm, kas darbojas vismaz gadu
• Noskaidrojiet, vai partneris raksta kodu pats vai nodod tālāk
• Sašauriniet līdz trim kandidātiem un salīdziniet vienā apjomā

Ko reāli pierāda portfolio un kā to pārbaudīt

Skaistas ekrānu bildes prezentācijā nepierāda neko. Mobilo lietotņu izstrādē vienīgais nopietnais pierādījums ir saite uz publicētu lietotni App Store vai Google Play, ko varat lejupielādēt savā telefonā un atvērt. Ja izstrādātājs rāda tikai dizaina maketus vai koncepta video, tas nozīmē vai nu to, ka lietotne nekad nav publicēta, vai to, ka klients nav atļāvis to rādīt — un otrajā gadījumā par to var pateikt tieši.

Kad esat atvēris veikala lapu, tur ir trīs lietas, kas pastāsta vairāk nekā jebkurš prezentācijas slaids. Pirmā ir pēdējā atjauninājuma datums. Ja lietotne nav atjaunināta divus gadus, tas nozīmē, ka projekts ir pamests, un pamestu projektu rinda liecina par to, kā izstrādātājs strādā pēc rēķina apmaksas. Otrā ir versiju vēsture — regulāri atjauninājumi ar saprotamiem aprakstiem rāda dzīvu produktu. Trešā ir lietotāju atsauksmes un tas, vai izstrādātājs uz tām atbild.

Otrs svarīgs solis ir pati lietotne telefonā. Instalējiet vismaz divas kandidāta lietotnes un piecas minūtes ar tām padarbojieties. Vai tā atveras ātri, vai teksti nepārklājas mazākā ekrānā, vai tā izdzīvo, ja izslēdz internetu, vai ir pieejams latviešu valodas variants. Šīs piecas minūtes atklāj kvalitātes līmeni precīzāk nekā stundu ilga saruna.

Visbeidzot palūdziet vienu kontaktu. Uzņēmums, kuram ir apmierināti klienti, iedos telefona numuru bez vilcināšanās. Sarunā jautājiet nevis to, vai bija labi, bet gan to, kas gāja greizi un kā izstrādātājs to atrisināja.

• Prasiet saites uz publicētām lietotnēm, ne tikai dizaina maketus
• Pārbaudiet pēdējā atjauninājuma datumu un versiju vēsturi
• Instalējiet lietotni un pārbaudiet ātrumu, ekrānus un bezsaistes uzvedību
• Palūdziet vismaz vienu klienta kontaktu un pajautājiet par problēmām

Kam pieder kods un kam pieder App Store un Google Play konti

Šis ir jautājums, kas izšķir, vai pēc gada jūs būsiet brīvs vai iesprostots. Mobilajā izstrādē ir divas atsevišķas īpašuma daļas, un abas ir jānoregulē līgumā jau pirms darba sākuma.

Pirmā daļa ir kods. Pēc pilnas apmaksas pirmkodam un dizaina failiem ir jāpāriet jūsu īpašumā, un tam ir jāatrodas repozitorijā, kuram jums ir piekļuve. Ja izstrādātājs saka, ka kods paliek pie viņa, jūs faktiski nomājat lietotni, nevis to esat pasūtījis. Tas var būt pieņemami abonementa modelī, ja cena to atspoguļo, bet tas ir jāzina iepriekš, nevis jāatklāj brīdī, kad gribat mainīt partneri.

Otrā daļa ir izstrādātāja konti. Apple Developer un Google Play izstrādātāja kontam ir jābūt reģistrētam uz jūsu uzņēmumu ar jūsu rekvizītiem un jūsu e-pastu. Izstrādātājam jūs varat piešķirt piekļuves tiesības, un tā ir normāla prakse. Nenormāla prakse ir tā, ka lietotne dzīvo aģentūras kontā — tad izstrādātājs jebkurā brīdī var jūs no tās atslēgt, un lietotnes pārnešana uz jūsu kontu prasa viņa aktīvu līdzdalību.

Praksē tas nozīmē vienu konkrētu soli projekta sākumā: jūs izveidojat Apple Developer kontu, kas maksā 99 dolārus gadā, un Google Play izstrādātāja kontu ar vienreizēju 25 dolāru maksu, un tikai pēc tam sākas publicēšanas sagatavošana. Rēķinieties, ka pirmreizējā konta verifikācija, īpaši Apple pusē, var aizņemt vairākas nedēļas, tāpēc to kārto uzreiz, nevis pēdējā nedēļā pirms palaišanas.

Tāda pati loģika attiecas uz visu pārējo infrastruktūru — backend serveri, domēnu, datubāzi, paziņojumu servisu un analītikas kontiem ir jābūt uz jūsu uzņēmuma vārda.

• Pirmkods un dizaina faili pāriet jums pēc pilnas apmaksas
• Apple Developer un Google Play konti reģistrēti uz jūsu uzņēmumu
• Izstrādātājam tiek dota piekļuve, nevis īpašums
• Serveris, domēns un analītika arī uz jūsu vārda
• Kontu verifikāciju sāciet projekta sākumā, ne beigās

Native vai cross-platform — Flutter, React Native vai atsevišķas iOS un Android lietotnes

Šo jautājumu klienti bieži uzdod pirmo, lai gan lēmumu vajadzētu pieņemt pēc funkciju saraksta, nevis pirms tā. Vienkāršotā valodā ir divi ceļi. Native nozīmē divas atsevišķas lietotnes — vienu iOS videi, otru Android videi, katrai savs kods. Cross-platform nozīmē vienu koda bāzi, no kuras tiek būvētas abas lietotnes, un populārākie rīki tam ir Flutter un React Native.

Vairumam Latvijas uzņēmumu pareizā izvēle ir cross-platform, un iemesls ir vienkāršs — nauda. Divas native lietotnes praktiski nozīmē divus projektus, divas testēšanas kārtas un divas uzturēšanas plūsmas. Cross-platform pieejā jūs par vienu budžetu iegūstat abas platformas, un katrs vēlākais uzlabojums arī tiek darīts vienu reizi, nevis divas.

Native pieeja ir pamatota tad, kad lietotnes kodols ir tieši tas, kas prasa dziļu operētājsistēmas piekļuvi: intensīva kameras vai video apstrāde, sarežģīts Bluetooth vai NFC darbs, augstas veiktspējas grafika, fona procesi ar precīzu enerģijas kontroli, integrācija ar Apple vai Google sistēmas funkcijām, kas cross-platform rīkos vēl nav pieejamas. Ja jūsu lietotne ir pieteikumi, rezervācijas, dati, paziņojumi un maksājumi, native priekšrocība praksē nav sajūtama.

Ir arī trešā situācija, kas Latvijā gadās bieži: jums vajadzīga tikai viena platforma. Ja lietotne ir domāta iekšējai komandai un visiem darbiniekiem ir Android ierīces, nav jēgas maksāt par iOS versiju. Tāpat, ja auditorija ir izteikti Apple lietotāji, var sākt ar iOS lietotņu izstrādi un Android pievienot vēlāk — cross-platform pieejā šāda paplašināšana ir salīdzinoši lēta.

Praktiskais tests ir tāds: ja izstrādātājs uzstāj uz native pieeju, neuzdodot nevienu jautājumu par funkcijām, viņš pārdod stundas, nevis risinājumu.

• Cross-platform — abas platformas par vienu budžetu, viena uzturēšana
• Native — kamera, Bluetooth, NFC, grafika, dziļas sistēmas funkcijas
• Viena platforma pietiek, ja auditorija vai komanda ir vienveidīga
• Izvēle tiek pieņemta pēc funkciju saraksta, nevis pirms tā

No idejas līdz publicēšanai App Store un Google Play — kā izskatās ceļš

Kārtīgs mobilās lietotnes projekts sastāv no sešiem posmiem, un labs izstrādātājs tos nosauc jau pirmajā sarunā. Ja piedāvājumā ir tikai divas rindas — izstrāde un publicēšana — jums nav plāna, jums ir cena.

Pirmais posms ir apjoma noskaidrošana. Šeit tiek uzrakstīti lietošanas scenāriji, ekrānu saraksts, lietotāju lomas un integrācijas ar esošajām sistēmām. Šis posms parasti aizņem vienu līdz divas nedēļas, un tieši tas izšķir, vai vēlāk būs pārsteigumi.

Otrais posms ir dizains — ekrānu struktūra un vizuālais izskats, ko jūs redzat un apstiprināt pirms koda rakstīšanas. Trešais posms ir backend un API, jo lielākā daļa biznesa lietotņu nav patstāvīgas: tām vajag serveri, datubāzi, autentifikāciju un administrēšanas paneli, kurā jūs paši varat mainīt saturu un redzēt lietotājus.

Ceturtais posms ir pati lietotnes izstrāde, piektais ir testēšana uz reālām ierīcēm. Testēšanā ir svarīgi, lai piedalāties arī jūs vai jūsu komanda — izstrādātājs pārbauda tehnisko pusi, bet tikai jūs zināt, kā lietotne iederas ikdienas darbā. Testēšana notiek TestFlight vidē iOS pusē un iekšējā testēšanas kanālā Google Play pusē.

Sestais posms ir publicēšana. Tas nav viens klikšķis: vajadzīgi sertifikāti un paraksti, lietotnes ikona, ekrānšāviņi katram ierīces izmēram, apraksts un atslēgvārdi veikalam, privātuma politika ar publisku saiti, datu drošības anketa Google pusē un privātuma etiķete Apple pusē. Apple katras versijas pārskatīšana parasti aizņem vienu līdz trīs darba dienas, Google Play — no dažām stundām līdz dienai, un pirmā iesniegšana mēdz būt lēnāka par nākamajām.

Kopējais termiņš vienkāršai lietotnei ar publicēšanu abos veikalos Latvijā orientējoši ir seši līdz desmit nedēļas, biznesa līmeņa lietotnei ar backend un administrēšanas paneli — divi līdz četri mēneši. Sarežģītām platformām ar bezsaistes režīmu un reāllaika datiem termiņš ir individuāls.

• Apjoma noskaidrošana un scenāriji — 1-2 nedēļas
• Dizains, ko apstiprināt pirms koda rakstīšanas
• Backend, API un administrēšanas panelis
• Izstrāde un testēšana uz reālām ierīcēm kopā ar jūsu komandu
• Publicēšana — sertifikāti, ekrānšāviņi, privātuma politika, anketas
• Vienkārša lietotne orientējoši 6-10 nedēļas, biznesa lietotne 2-4 mēneši

Kas jābūt piedāvājumā un cik mobilo aplikāciju izstrāde orientējoši maksā

Piedāvājumu ir iespējams salīdzināt tikai tad, ja tajā ir apjoms, nevis viena summa. Kārtīgā piedāvājumā ir uzskaitīti ekrāni vai funkciju bloki, norādīts, vai risinājums ir cross-platform vai native, vai iekļauta backend daļa un administrēšanas panelis, kas notiek ar publicēšanu, cik testēšanas kārtu ir iekļautas, kāda ir garantija pēc palaišanas un kā tiek rēķināti darbi ārpus apjoma. Ja divi piedāvājumi atšķiras divas reizes, gandrīz vienmēr atšķiras nevis stundas likme, bet tas, ko katrs ir sapratis ar vārdu lietotne.

Zemāk ir orientējoši Latvijas tirgus diapazoni, nevis piedāvājums. Precīza cena atkarīga no funkciju skaita, integrācijām un backend sarežģītības.

MVP jeb pirmā versija ar pamata funkcionalitāti abām platformām un publicēšanu App Store un Google Play orientējoši maksā 2 400 līdz 3 000 eiro. Biznesa līmeņa lietotne ar pielāgotu backend API, autentifikāciju, push paziņojumiem un administrēšanas paneli — orientējoši 4 500 līdz 6 000 eiro. Sarežģīta platforma ar bezsaistes režīmu, reāllaika datu sinhronizāciju un integrācijām esošajās sistēmās tiek rēķināta pēc apjoma un parasti sākas no 8 000 eiro.

Pie izstrādes cenas ir jāpieskaita pastāvīgās izmaksas, ko daudzi piedāvājumi klusē: Apple izstrādātāja konts 99 dolāri gadā, Google Play vienreizēja 25 dolāru maksa, servera un datubāzes hostings atkarībā no slodzes, un uzturēšana. Uz trim gadiem šīs pozīcijas summējas, tāpēc tās ir jāredz jau lēmuma brīdī.

Vēl viena vieta, kur jāskatās uzmanīgi, ir maksājumu grafiks. Normāla prakse ir sadalījums posmos — priekšapmaksa, maksājums pēc dizaina apstiprināšanas, maksājums pēc testēšanas versijas un atlikums pēc publicēšanas. Prasība samaksāt visu uzreiz vai, otrādi, pilnīgi bez priekšapmaksas abas ir signāls padomāt.

• MVP lietotne ar publicēšanu abos veikalos — orientējoši 2 400-3 000 EUR
• Biznesa lietotne ar backend un admin paneli — orientējoši 4 500-6 000 EUR
• Sarežģīta platforma ar integrācijām — no 8 000 EUR pēc apjoma
• Apple konts 99 USD gadā, Google Play vienreizēji 25 USD
• Piedāvājumā jābūt ekrānu sarakstam, garantijai un ārpus apjoma likmei
• Maksājumi sadalīti posmos, nevis viens rēķins uz priekšu

Lietotņu uzturēšana pēc palaišanas — kā izvēlēties uzturēšanas partneri

Mobilā lietotne atšķiras no mājaslapas ar to, ka bez uzturēšanas tā ne tikai noveco, bet var vienkārši pārstāt strādāt. Apple un Google katru gadu izlaiž jaunas operētājsistēmas versijas un regulāri paceļ minimālās prasības publicētajām lietotnēm. Ja lietotne šīm prasībām neatbilst, jaunus atjauninājumus vairs nevar iesniegt, un pēc laika Google Play to var padarīt neredzamu jaunām ierīcēm. Neuzturēta lietotne parasti sāk lūzt otrajā gadā.

Tāpēc lietotņu uzturēšanas partneris ir jāizvēlas vienlaikus ar izstrādātāju, nevis gadu vēlāk. Vienkāršākais un lētākais variants ir tas pats uzņēmums, kas lietotni būvēja, jo tas pazīst kodu. Cita partnera pārņemšana ir iespējama, bet tā sākas ar koda auditu, un tas maksā atsevišķi.

Kārtīgs uzturēšanas līgums mobilajai lietotnei ietver vairāk nekā kļūdu labošanu. Tajā ietilpst saderības atjauninājumi ar jaunajām iOS un Android versijām, bibliotēku un SDK atjaunināšana, sertifikātu un paroļu atjaunošana, backend servera un datubāzes uzturēšana ar rezerves kopijām, monitorings ar brīdinājumiem par avārijām, atbilstība mainīgajām veikalu politikām un pašu atjauninājumu iesniegšana veikalos.

Cenu ziņā mobilās lietotnes uzturēšana ir dārgāka par mājaslapas uzturēšanu, jo tajā ietilpst arī backend un divas platformas. MBC uzturēšanu un labojumus rēķina pēc stundas likmes — 40 eiro stundā, arī mājaslapām. Lietotnēm rēķinieties ar lielāku stundu skaitu, jo jāuztur gan backend, gan divas platformas. Alternatīva ir gada budžets attīstībai, kas tiek izmantots pēc vajadzības.

Pirms parakstīšanas noskaidrojiet divas praktiskas lietas: cik ātri partneris reaģē, ja lietotne pēkšņi avarē visiem lietotājiem, un vai atjauninājumu iesniegšana veikalos ir iekļauta vai tiek rēķināta atsevišķi. Šie divi punkti ikdienā izšķir vairāk nekā abonementa summa.

• Saderība ar jaunajām iOS un Android versijām katru gadu
• Bibliotēku, SDK un sertifikātu atjaunināšana
• Backend, datubāze, rezerves kopijas un monitorings
• Atjauninājumu sagatavošana un iesniegšana veikalos
• Skaidrs reakcijas laiks avāriju gadījumā
• Uzturēšanas partneris jāizvēlas kopā ar izstrādātāju, ne gadu vēlāk

Sarkanie karogi un jautājumi, ko uzdot pirms līguma parakstīšanas

Lielākā daļa neizdevušos lietotņu projektu bija atpazīstami jau pirmajā sarunā. Brīdinājuma zīmes ir diezgan viendabīgas. Cena tiek nosaukta uzreiz, neuzdodot nevienu jautājumu par funkcijām. Portfolio sastāv no maketiem, nevis publicētām lietotnēm. Izstrādātājs uzstāj, ka konti būs uz viņa vārda. Piedāvājumā nav ne vārda par backend daļu, lai gan lietotnei ir jāglabā dati. Netiek pieminēta ne testēšana, ne garantija. Termiņš tiek solīts pārsteidzoši īss, piemēram, divas nedēļas lietotnei ar autentifikāciju un maksājumiem.

Vēl viena bieža zīme ir tā, ka izstrādātājs runā tikai par tehnoloģijām, nevis par to, kā lietotne nopelnīs vai ietaupīs. Ja sarunā neizskan jautājums par to, cik bieži cilvēks lietotni atvērs un kāpēc viņš to instalēs, pastāv liela varbūtība, ka jums pārdod projektu, kuram vispār vajadzēja būt mājaslapai.

Pirms parakstīšanas ir vērts izdrukāt un uzdot vienu un to pašu jautājumu sarakstu visiem trim kandidātiem. Atbildes uz šiem jautājumiem salīdzināt ir daudz vienkāršāk nekā piedāvājumu kopsummas.

• Vai varam apskatīt divas jūsu publicētas lietotnes veikalos?
• Kas raksta kodu un kur atrodas komanda?
• Kam pēc apmaksas pieder kods un kur tas glabājas?
• Vai App Store un Google Play konti būs uz mūsu uzņēmuma vārda?
• Kāpēc jūs iesakāt tieši cross-platform vai native pieeju šim projektam?
• Kas tieši ir iekļauts publicēšanā un kas jādara mums?
• Cik ilga ir garantija un kas tajā ietilpst?
• Ko maksā uzturēšana un kas tajā ir iekļauts?
• Cik ātri jūs reaģējat, ja lietotne avarē pēc palaišanas?
• Kas notiek, ja mēs vēlāk gribam mainīt izstrādātāju?