Cik maksā mobilās lietotnes izstrāde Latvijā 2026. gadā

Cik maksā mobilā aplikācija? Godīgā atbilde ir — no dažiem tūkstošiem eiro līdz summām, kuras var noteikt tikai pēc detalizētas apjoma noskaidrošanas, un starpību nosaka nevis izstrādātāja apetīte, bet tas, ko lietotnei patiesībā jādara. Mobilās lietotnes izstrādes cena veidojas no funkcijām, backend daļas, integrācijām, dizaina un platformām, un vēl ir izmaksas, kas parādās tikai pēc palaišanas. Šajā rakstā aplūkojam visu, kas ietekmē mobilo aplikāciju izstrādes budžetu Latvijā: kādi ir reāli cenu līmeņi, kad izvēlēties native un kad cross-platform pieeju, ko maksā Apple un Google konti, serveris un operētājsistēmu atjauninājumi, kā samazināt izmaksas ar MVP un ko sagatavot, pirms prasāt piedāvājumu. Skaitļi ir MBC indikatīvās cenas bez PVN — galīgā summa vienmēr tiek noteikta pēc apjoma noskaidrošanas.

Mobilās lietotnes izstrāde — cena īsumā

Ja vajag vienu skaitli, ar ko sākt sarunu ar vadību vai grāmatvedi, tad mobilās lietotnes izstrāde Latvijā sākas ap 2 400 eiro par vienkāršu pirmo versiju abām platformām. Biznesa līmeņa lietotne ar savu backend, administrēšanas paneli un push paziņojumiem sākas no 4 500 eiro. Sarežģītas platformas ar bezsaistes režīmu, reāllaika datiem un integrācijām ar esošajām sistēmām tiek rēķinātas pēc apjoma, jo tur divi projekti ar vienādu nosaukumu var atšķirties vairākas reizes.

Svarīgi saprast, ka šie ir tipiski projektu līmeņi, nevis fiksētas paketes. Funkcijas var kombinēt — piemēram, MVP ar push paziņojumiem vai biznesa lietotne ar vienu integrāciju —, un cena attiecīgi mainās. Tāpēc jebkurš izstrādātājs, kas nosauc precīzu summu, vēl nezinot funkciju sarakstu, patiesībā nosauc minējumu.

Zemāk ir MBC indikatīvie cenu līmeņi bez PVN. Tālākajās sadaļās izskaidrojam, kas tieši ceļ vai samazina cenu.

• MVP lietotne — no 2 400 EUR: cross-platform iOS un Android, pamata funkcionalitāte, pamata UI/UX dizains, pamata autentifikācija, publicēšana App Store un Google Play
• Biznesa lietotne — no 4 500 EUR: pielāgots backend API, autentifikācija un autorizācija, push paziņojumi, admin panelis, pamata analītika
• Sarežģīta platforma — pēc apjoma: bezsaistes režīms, reāllaika datu sinhronizācija, augstas slodzes arhitektūra, sarežģītas trešo pušu integrācijas
• Izmaiņas un uzturēšana pēc palaišanas — 40 EUR stundā, bez ikmēneša maksas

Kas nosaka cenu: funkcijas, ekrāni un lietotāju lomas

Lielāko daļu mobilās aplikācijas cenas veido funkciju saraksts. Katrs ekrāns ir jāuzzīmē, jāizstrādā, jāsavieno ar datiem un jānotestē dažāda izmēra telefonos. Lietotne ar pieciem ekrāniem un vienu lietotāju tipu ir pavisam cits projekts nekā lietotne ar divdesmit ekrāniem, kur klientam, darbiniekam un administratoram katram ir savs skats un savas tiesības.

Ir funkcijas, kas izskatās mazas, bet prasa ievērojamu darbu. Pieteikšanās ar e-pastu ir vienkārša, bet pieteikšanās ar Google un Apple kontu, paroles atjaunošana un konta dzēšana pēc veikalu prasībām jau ir atsevišķs darba bloks. Push paziņojumi prasa gan lietotnes pusi, gan servera loģiku, kas izlemj, kam un kad tos sūtīt. Maksājumi lietotnē, kartes un atrašanās vieta, failu un attēlu augšupielāde — katrs no tiem ir savs darba apjoms.

Tāpēc, salīdzinot piedāvājumus, skatieties nevis uz kopsummu, bet uz to, vai abos ir vienāds ekrānu un funkciju saraksts. Ja viena piedāvājuma sarakstā ir pieci punkti, bet otrā — piecpadsmit, jūs salīdzināt divas dažādas lietotnes.

• Ekrānu skaits un lietotāju lomu skaits
• Autentifikācija — e-pasts, Google, Apple, paroles atjaunošana, konta dzēšana
• Push paziņojumi ar servera loģiku
• Maksājumi, kartes, atrašanās vieta, failu augšupielāde
• Valodu skaits un satura pārvaldība

Backend, admin panelis un integrācijas — neredzamā budžeta daļa

Lietotājs redz tikai lietotni telefonā, bet vairumam biznesa lietotņu lielākā darba daļa notiek serverī. Kur glabājas lietotāju konti, pasūtījumi vai rezervācijas? Kas sūta paziņojumus? Kur jūsu komanda maina saturu, redz lietotājus un apstrādā pieteikumus? Uz visiem šiem jautājumiem atbild backend un administrēšanas panelis.

MBC backend daļu parasti veido ar Laravel API, un tieši šī daļa ir galvenā atšķirība starp MVP un biznesa lietotni. MVP pietiek ar pamata funkcionalitāti un autentifikāciju, bet, tiklīdz vajag pielāgotu datu loģiku, admin paneli un analītiku, apjoms būtiski pieaug.

Integrācijas ir nākamais lielais cenas faktors. Ja lietotne savienojas ar jūsu CRM, rezervāciju sistēmu, klientu portālu vai mājaslapas datiem, darba apjomu lielā mērā nosaka tas, cik sakārtota ir otra puse. Ja otrai sistēmai ir labi dokumentēts API, integrācija ir paredzams darbs. Ja API nav vai tas ir nepilnīgs, darbs kļūst par izpēti, un to godīgi var novērtēt tikai pēc tam, kad izstrādātājs ir redzējis dokumentāciju vai saņēmis piekļuvi testa videi.

• Backend API — lietotāju dati, biznesa loģika, paziņojumu sūtīšana
• Admin panelis, kurā jūsu komanda pārvalda saturu un lietotājus
• Integrācijas ar CRM, rezervāciju sistēmām, portāliem, mājaslapu
• Integrācijas cenu nosaka otras sistēmas API kvalitāte

Native vai cross-platform un cik maksā dizains

Native pieeja nozīmē divas atsevišķas lietotnes — vienu iOS videi, otru Android videi, katrai savs kods. Cross-platform pieeja, piemēram, Flutter, nozīmē vienu koda bāzi, no kuras tiek būvētas abas lietotnes. Cenas ziņā atšķirība ir vienkārša: native praktiski nozīmē divus izstrādes darbus, divas testēšanas kārtas un divas uzturēšanas plūsmas.

Tāpēc MBC MVP un biznesa lietotnes standartā veido kā cross-platform risinājumus — jūs par vienu budžetu iegūstat gan iOS, gan Android lietotni, un arī katrs vēlākais uzlabojums jāizstrādā tikai vienu reizi. Native pieeja ir pamatota, ja lietotnes kodols prasa dziļu piekļuvi operētājsistēmai — intensīva kameras vai video apstrāde, sarežģīts Bluetooth vai NFC darbs, augstas veiktspējas grafika. Ja jūsu lietotnes pamatā ir pieteikumi, rezervācijas, dati un paziņojumi, native priekšrocība praksē nav sajūtama, bet cenas starpība ir.

Dizains ir otrs cenas faktors. Pamata UI/UX dizains nozīmē skaidru, ērtu saskarni, kas balstās uz jūsu zīmola krāsām un iOS un Android lietošanas paradumiem. Pilnībā unikāls dizains ar pielāgotām animācijām un ilustrācijām ir krietni lielāks darbs. Pirmajai versijai gandrīz vienmēr pietiek ar pamata dizainu — lietotāji novērtē ātrumu un skaidrību vairāk nekā efektus.

• Cross-platform — abas platformas par vienu budžetu un viena uzturēšana
• Native — tikai tad, ja to prasa kamera, Bluetooth, NFC vai grafika
• Pietiek ar vienu platformu, ja visa auditorija vai komanda lieto tikai to
• Pamata UI/UX pirmajai versijai, unikāls dizains vēlāk, ja tas atmaksājas

Izmaksas pēc palaišanas, par kurām piedāvājumi bieži klusē

Izstrādes cena ir tikai daļa no kopējām izmaksām. Mobilajai lietotnei ir pastāvīgi maksājumi, kas jāieplāno jau lēmuma brīdī, nevis jāatklāj pēc palaišanas.

Pirmie ir veikalu konti. Apple Developer konts maksā 99 USD gadā, Google Play izstrādātāja konts — vienreizēji 25 USD. Abus kontus klients reģistrē uz sava uzņēmuma vārda un apmaksā pats, lai lietotne paliktu jūsu īpašumā. Rēķinieties, ka pirmreizējā konta verifikācija, īpaši Apple pusē, var aizņemt vairākas nedēļas, tāpēc to sāk kārtot jau projekta sākumā.

Otrie ir serveris un hostings backend daļai. Izmaksas ir atkarīgas no lietotāju skaita, datu apjoma un slodzes — iekšējai lietotnei ar dažiem desmitiem darbinieku tās ir pavisam citas nekā klientu lietotnei ar tūkstošiem aktīvu lietotāju. Labs izstrādātājs šo pozīciju aprēķina jau piedāvājumā.

Trešie ir operētājsistēmu atjauninājumi. Apple un Google katru gadu izlaiž jaunas iOS un Android versijas un paaugstina prasības publicētajām lietotnēm. Lietotnei, kuru neviens neatjaunina, agrāk vai vēlāk vairs nevar publicēt jaunas versijas veikalos. MBC izmaiņas un uzturēšanu pēc palaišanas rēķina pēc fakta — 40 EUR stundā, bez ikmēneša abonementa. Jūs maksājat tikai par to, kas tiešām tiek izdarīts.

• Apple Developer konts — 99 USD gadā
• Google Play izstrādātāja konts — 25 USD vienreizēji
• Serveris un hostings — atkarībā no lietotāju skaita un slodzes
• Saderības atjauninājumi ar jaunajām iOS un Android versijām
• MBC izmaiņas un uzturēšana — 40 EUR stundā, bez ikmēneša maksas

Kā samazināt izmaksas: sāciet ar MVP

Dārgākā kļūda mobilo aplikāciju izstrādē ir mēģinājums pirmajā versijā ielikt visu, kas jebkad varētu noderēt. Rezultāts ir lielāks budžets, garāks termiņš un lietotne, kurā puse funkciju netiek lietota. Lētākais un drošākais ceļš ir MVP jeb pirmā versija ar vienu skaidru galveno scenāriju.

Praktiski tas nozīmē uzrakstīt visu funkciju sarakstu un pēc tam par katru punktu pajautāt: vai bez tā lietotne spēj izpildīt savu galveno uzdevumu? Ja spēj, punkts tiek pārcelts uz otro versiju. Rezervāciju lietotnei galvenais scenārijs ir rezervēt laiku un saņemt apstiprinājumu. Lojalitātes programmu, atsauksmes un čatu var pievienot vēlāk, kad redzēsiet, ko lietotāji patiesībā dara.

MVP nav lēta un nepabeigta lietotne. Tā ir kvalitatīvi izstrādāta, publicēta abos veikalos un gatava paplašināšanai. Ja backend jau sākumā ir veidots ar domu par nākamajām funkcijām, otrā versija nav jāpārbūvē no nulles. Šāda pieeja arī samazina risku: ja izrādās, ka lietotāji uzvedas citādi, nekā plānojāt, jūs to uzzināt par MVP cenu, nevis par pilnas platformas cenu.

• Viens galvenais scenārijs pirmajai versijai
• Katru funkciju pārbaudiet ar jautājumu — vai bez tās lietotne strādā?
• Cross-platform, nevis divas native lietotnes
• Pamata dizains, unikāli efekti vēlāk
• Backend, kas gatavs paplašināšanai, lai otrā versija nebūtu jāpārbūvē

Ko sagatavot, pirms prasāt piedāvājumu

Jo precīzāk aprakstāt ideju, jo precīzāka būs cena. Lai saņemtu piedāvājumu, nevajag tehnisko specifikāciju — pietiek ar vienu vai divām lapām, kurās atbildēti daži pamata jautājumi.

Sāciet ar mērķi un lietotājiem: kas lietos lietotni, cik bieži un kāpēc viņi to instalēs, nevis vienkārši atvērs mājaslapu. Ja uz šo jautājumu grūti atbildēt, ir vērts vispirms izvērtēt, vai mobilā lietotne vispār ir vajadzīga. Tad uzskaitiet galvenās funkcijas prioritātes secībā un atzīmējiet, kuras ir obligātas pirmajā versijā.

Noderīgi ir arī piemēri — divas vai trīs lietotnes, kas jums patīk, un ko tieši jūs tajās novērtējat. Ja lietotnei jāsavienojas ar esošajām sistēmām, nosauciet tās un, ja iespējams, pievienojiet API dokumentāciju. Visbeidzot norādiet budžeta diapazonu un vēlamo termiņu. Budžeta nosaukšana nav risks — tā ļauj izstrādātājam piedāvāt reālistisku apjomu jūsu budžeta robežās, nevis ideālu lietotni, ko nevarat atļauties.

• Mērķis un lietotāji — kas, cik bieži un kāpēc
• Funkciju saraksts prioritātes secībā ar atzīmētu MVP daļu
• Lietotāju lomas — klients, darbinieks, administrators
• Esošās sistēmas un to API dokumentācija
• Divas vai trīs lietotnes kā piemēri
• Budžeta diapazons un vēlamais termiņš

Kāpēc piedāvājumi atšķiras un kā tos salīdzināt

Nav nekas neparasts, ka divi piedāvājumi vienai un tai pašai idejai atšķiras divas vai trīs reizes. Gandrīz vienmēr atšķiras nevis stundas likme, bet tas, ko katrs izstrādātājs ir sapratis ar vārdu „lietotne”. Viens cenā ir iekļāvis tikai ekrānus telefonā, otrs — arī backend, admin paneli, publicēšanu un testēšanu.

Kārtīgā piedāvājumā ir redzams ekrānu vai funkciju bloku saraksts, norādīts, vai risinājums ir cross-platform vai native, vai ir iekļauts backend un admin panelis, kā tiek organizēta publicēšana App Store un Google Play, kā notiek testēšana reālās ierīcēs un kā tiek rēķināti darbi ārpus apjoma. Publicēšana ietver sertifikātus, ikonas, ekrānšāviņus, aprakstus un pirmo iesniegšanu — ja piedāvājumā tā nav minēta, pajautājiet, kurš to darīs.

Pievērsiet uzmanību arī tam, kam pēc apmaksas pieder kods un vai veikalu konti būs uz jūsu uzņēmuma vārda. Lētākais piedāvājums, kurā lietotne paliek izstrādātāja kontā, ilgtermiņā var izrādīties dārgākais.

• Salīdziniet funkciju sarakstus, nevis kopsummas
• Pārbaudiet, vai ir iekļauti backend, admin panelis un publicēšana
• Noskaidrojiet, kā tiek rēķinātas izmaiņas pēc palaišanas
• Kods un veikalu konti — jūsu īpašumā