Prieš porą mėnesių gavau užklausą: „Norime app'o. Kiek kainuos?" Ir viskas. Jokio paaiškinimo, ką tas app'as turėtų daryti, kam skirtas, kokia problema sprendžiama. Tiesiog — „norime app'o".
Tai va — tai tas pats, kas ateiti pas architektą ir pasakyti „noriu namo". Gerai, bet kokio? Vieno aukšto ar trijų? Su garažu ar be? Kiek žmonių gyvens? Koks biudžetas?
Ir čia ne klientas kaltas. Dauguma žmonių niekada gyvenime neužsakinėjo programėlės. Iš kur jiems žinoti, ką paruošti? Todėl parašiau šitą straipsnį — kad tau nereikėtų mokytis iš klaidų.
Kodėl pasiruošimas sutaupo 30% laiko ir pinigų
Tai ne šiaip skaičius iš lubų. Per savo praktiką esu matęs abu variantus — kai klientas ateina pasiruošęs ir kai ateina su „na, padarykit kažką".
Skirtumas milžiniškas. Kai turi aiškų brief'ą — kūrėjas iš karto supranta, ko reikia. Nereikia 5 susitikimų vien tam, kad išsiaiškintum, ką darysim. Nereikia perdaryti dizaino, nes „ne taip įsivaizdavau". Nereikia pridėti funkcijų viduryje projekto, nes „pamiršau paminėti".
Vienas klientas iš Kauno — restoranų tinklas — atėjo su 4 puslapių brief'u. Funkcijų sąrašas, konkurentų screenshot'ai, biudžeto rėžiai, terminai. Projektą padarėme per 7 savaites, be jokių dramų. Kitas panašaus dydžio projektas, kur klientas „viską pasakys vėliau" — užsitęsė 4 mėnesius ir kainavo dvigubai.
Trumpai tariant — valanda pasiruošimo sutaupo savaitę kūrimo.
1. Aiškiai suformuluok problemą
Tai pirmas ir svarbiausias žingsnis. Ne „noriu app'o", o „mano klientai laukia eilėje 15 minučių ir dalis išeina" arba „mūsų kurjeriai nežino optimalių maršrutų ir švaisto kurą".
Jei negali vienu sakiniu pasakyti, kokią problemą app'as sprendžia — dar per anksti jį kurti.
Geras problemos aprašymas atrodo taip:
- Blogai: „Norime programėlės savo verslui"
- Gerai: „Mūsų grožio salonas Vilniuje turi 4 meistrus. Klientės skambina registruotis, bet 40% skambučių praleidžiame, nes meistrai dirba. Norime, kad klientės galėtų užsiregistruoti pačios bet kuriuo paros metu."
Matai skirtumą? Antras variantas iš karto pasako — kas, kodėl ir ką tikimės gauti.
Patarimas: parašyk problemą ant lapo. Tada parodyk kolegai, kuris nieko nežino apie tavo planą. Jei jis supranta — puiku. Jei ne — perrašyk.
2. Apibrėžk savo tikslinę auditoriją
„Visi" — tai ne auditorija. Man reikia žinoti, kas tiksliai naudos tavo app'ą.
Ar tai tavo darbuotojai? Tada svarbu, kokius telefonus jie naudoja (Android ar iOS), koks jų tech raštingumo lygis, ar dirba lauke ar biure.
Ar tai klientai? Tada — kiek jiems metų, kaip dažnai naudos, ar jie jau naudoja panašius app'us, kokios jų lūkesčiai.
Pavyzdys: vienas Klaipėdos logistikos verslas norėjo app'o vairuotojams. Kai paklausiau apie auditoriją, paaiškėjo — vairuotojai 45-60 metų, naudoja pigiausius Android telefonus, daug kas sunkiai rašo žinutes. Tai reiškia: didelis šriftas, minimalūs teksto laukai, daugiau mygtukų ir ikonų. Jei to nebūtume žinoję — padarytume app'ą, kuriuo niekas nemokėtų naudotis.
3. Sudėliok funkcijų sąrašą: must-have vs nice-to-have
Čia prasideda smagu — ir čia dauguma klientų klysta labiausiai. Nori visko iš karto. Registraciją, mokėjimus, chat'ą, push pranešimus, lojalumo programą, AI rekomendacijas, integraciją su buhalterija, dar ir social media sharing.
Na, ir kas? Tai kainuos 40 000 EUR ir truks pusę metų. O gal pradžiai užtektų registracijos ir pranešimų?
Kaip prioritetizuoti funkcijas
Pasiimk lapą ir padaryk dvi kolonėles:
- Must-have (būtina): be šitų funkcijų app'as neturi prasmės. Pvz., booking sistema grožio salonui — be jos visas app'as beprasmis.
- Nice-to-have (būtų gerai): pagerins patirtį, bet app'as veiks ir be jų. Pvz., lojalumo taškai, spalvų temos, integracija su kalendoriumi.
Pirma versija — tik must-have. Visa kita — antrai versijai.
Tiesą sakant, geriausios programėlės daro vieną dalyką labai gerai. Ne dešimt dalykų vidutiniškai. Pagalvok apie Bolt — iškvieti taksi. Taškas. O dabar jau turi ir maistą, ir nuomą, bet pradėjo nuo vieno dalyko.
4. Padaryk konkurentų analizę (užtrunka 1 valandą)
Tau nereikia rašyti mokslinės analizės. Tiesiog atidaryk Google Play ar App Store, surask 3-5 panašius app'us ir padaryk screenshot'us.
Pažymėk, kas tau patinka:
- Šitas meniu patogus — noriu panašiai
- Šitas booking flow per 3 žingsnius — genialai, noriu taip
- O šita spalvų schema — ne, per tamsu, mano klientams netiks
Ir pažymėk, kas nepatinka — tai lygiai taip pat svarbu. „Šitam app'e reikia 7 žingsnių, kad užsiregistruotum — tai per daug."
Kai kūrėjui atsiųsi 15 screenshot'ų su komentarais — jis tave mylės. Rimtai. Tai sutaupys bent 2-3 susitikimus ir sumažins nesusipratimų skaičių per 80%.
Bet nekopijuok aklai
Dažna klaida — „noriu kaip Wolt" arba „padaryk kaip Vinted". Tai milžiniški produktai su 50+ žmonių komandomis ir milijoniniais biudžetais. Imk inspiracijos, bet nepritaikyk sau viso jų funkcionalumo. Tavo pirmoji versija turi būti paprastesnė — ir tai gerai.
5. Nusistatyk realų biudžetą
Žinau, kad kainos — jautri tema. Bet kūrėjui labai padeda žinoti bent biudžeto rėžius. Ne todėl, kad norėtų „ištraukti maksimumą" — o todėl, kad gali pasiūlyti geriausią sprendimą tavo kainų kategorijoje.
| Biudžeto rėžis | Ką galima padaryti |
|---|---|
| 3 000 – 7 000 EUR | PWA arba labai paprasta native programėlė su 2-3 pagrindinėmis funkcijomis |
| 7 000 – 15 000 EUR | Vidutinio sudėtingumo app'as su backend'u, vartotojų registracija, push pranešimais |
| 15 000 – 30 000 EUR | Sudėtingas app'as su mokėjimais, integracijomis, admin panele |
| 30 000+ EUR | Enterprise sprendimas su AI, daugybe integracijų, kelios vartotojų rolės |
Ir nepamirški — prie kūrimo kainos pridėk dar 15-20% metiniam palaikymui. Serveriai, atnaujinimai, klaidų taisymas. App'as — ne vienkartinė investicija. Detalią kainų analizę rasite straipsnyje apie Android aplikacijos kainą Lietuvoje, o bendrą kainų palyginimą — straipsnyje app kūrimo kaina 2026.
6. Turėk realius terminų lūkesčius
„Ar galima per mėnesį?" — klausimas, kurį girdžiu kas savaitę. Atsakymas dažniausiai — ne. Nebent tai labai paprastas MVP.
Realūs terminai:
- Paprastas app'as: 6-10 savaičių
- Vidutinio sudėtingumo: 3-4 mėnesiai
- Sudėtingas su integracijomis: 4-6 mėnesiai
Ir tai su sąlyga, kad brief'as aiškus ir klientas greitai atsako į klausimus. Kiekvieną savaitę delsimo iš kliento pusės — dar savaitė prie terminų.
Mano patarimas: jei turi „deadline" (pvz., sezono pradžia, renginys) — pradėk planuoti bent 2 mėnesius anksčiau nei galvoji. Visada kažkas užtrunka ilgiau nei planuota. Detalesnę terminų analizę rasite straipsnyje per kiek laiko sukuriama mobili aplikacija.
Dažniausios klaidos, kurias matau
Per kelerius metus pastebėjau, kad klientai kartoja tas pačias klaidas. Štai TOP 5:
- Nori visko iš karto. Rezultatas — projektas kainuoja trigubai, trunka dvigubai ir pusė funkcijų niekam nereikalinga. Pradėk nuo MVP.
- Kopijuoja konkurentus aklai. „Noriu kaip Bolt" — bet Bolt turi 200 inžinierių. Imk idėjas, bet pritaikyk savo realybei.
- Neturi biudžeto palaikymui. Sukuria app'ą ir tikisi, kad jis veiks amžinai be priežiūros. Po 6 mėnesių — klaidos, pasenusios bibliotekos, nulūžę API.
- Nekalba su savo klientais. Daro app'ą pagal savo viziją, o ne pagal tai, ko klientai iš tikro nori. Rezultatas — 50 atsisiuntimų ir tyla.
- Renkasi pigiausią pasiūlymą. Esu ne kartą taisęs projektus po „pigaus freelancer'io". Kainavo daugiau nei būtų kainavęs normalus projektas nuo pradžių. Kaip atskirti gerą kūrėją — rasite straipsnyje kaip pasirinkti aplikacijos kūrėją.
Praktinis checklist: ką turėti prieš pirmą susitikimą
Štai konkretus sąrašas. Atspausdink arba nukopijuok — ir užpildyk prieš skambindamas bet kokiam kūrėjui.
App brief checklist
- Kokią verslo problemą sprendžia app'as? (1-2 sakiniai)
- Kas naudos app'ą? (auditorijos aprašymas)
- Must-have funkcijų sąrašas (5-10 punktų)
- Nice-to-have funkcijų sąrašas (neribota)
- 3-5 konkurentų/patinkančių app'ų screenshot'ai su komentarais
- Biudžeto rėžiai (bent apytiksliai)
- Pageidaujami terminai (ar yra deadline?)
- Ar reikia tik Android, tik iOS, ar abiem platformom?
- Ar turite logotipą, spalvas, brand guide?
- Su kokiomis sistemomis app'as turi integruotis? (buhalterija, CRM, svetainė)
Nereikia atsakyti tobulai. Net ir 70% užpildytas checklist — jau šviesmečiais geriau nei „norime app'o, kiek kainuos?".
Ko kūrėjas tikisi iš tavęs
Esu buvęs abiejose pusėse — ir užsakovo, ir kūrėjo. Štai kas iš tikro padeda:
- Greitai atsakyk į klausimus. Kai kūrėjas paklausia „o kaip čia turėtų veikti?" — atsakyk per 1-2 dienas, ne per savaitę. Kiekvienas delsimas — tai tiesioginiai pinigai.
- Turėk vieną sprendimų priėmėją. Kai 5 žmonės turi „nuomonę" apie dizainą — projektas niekada nesibaigs. Paskirk vieną žmogų, kuris tvirtina.
- Pasitikėk eksperto patarimu. Jei kūrėjas sako „šita funkcija kainuos 5000 EUR, bet galiu pasiūlyti alternatyvą už 1500 EUR" — bent pasvarstyk.
- Testuok. Kai gausi beta versiją — tikrai naudok ir duok feedback. Ne tik „viskas gerai" ar „nepatinka". Konkrečiai — „šitas mygtukas per mažas" arba „neaišku, kur spausti toliau".
Tai va — ne toks jau sudėtingas reikalas
Kai pažiūri į visa tai — atrodo nemažai darbo. Bet realiai — tai 3-4 valandos tavęs laiko. Ir tos valandos gali sutaupyti tūkstančius eurų ir savaites nervų.
Geriausias klientas, su kuriuo teko dirbti, pasakė: „Aš praleidau savaitgalį galvodamas apie app'ą. Pirmadienį atsiuntiau brief'ą." Rezultatas — projektas pavyko iš pirmo karto, be perdarymo, per 8 savaites, neviršijant biudžeto.
Tai va koks skirtumas tarp „noriu app'o" ir „štai ko man reikia".
Jei ruošiesi užsakyti programėlę ir nori pasitikrinti savo brief'ą — parašyk man. Peržiūrėsiu nemokamai ir pasakysiu, ar viskas aišku, ar reikia ką nors papildyti. Jokių įsipareigojimų — tiesiog noriu, kad tavo projektas pavyktų.
Nori aptarti savo situaciją konkrečiai? Aprašyk savo projekto idėją — atsakysiu per 24 valandas su konkrečiu pasiūlymu.
Turite app idėją, bet nežinote nuo ko pradėti?
Atsiųskite savo brief'ą arba tiesiog aprašykite idėją. Per 24 valandas gausite nemokamą įvertinimą — ar verta kurti, kiek kainuos ir kiek užtruks.
Nemokama konsultacija
