Hogyan csökkenthető az applikációk bekerülési költsége?

Napjainkban gyakorlatilag elvártnak tekintik a vásárlók egy komoly vállalkozástól, hogy legyen valamilyen saját alkalmazása, ne kelljen a telefonjukról mindig a böngészőt használni. Ez egyébként abból is kikövetkeztethető, hogy mennyire megnőtt az utóbbi néhány évben a rendes, telepíthető megoldások felhasználóbázisa. Ezek mellett pedig számos olyan vállalkozás van melynek fő platforma valamilyen applikáció.

De akkor miért nem csinál magának mindenki saját appot?

Az elhatározásig rengetegen eljutnak, azonban az esetek többségében a kezdeti költségek jelentik a legnagyobb elrettentést. Könnyen szembesülhetünk milliós nagyságrendű árajánlatokkal, még akkor is, ha nagyon egyszerűnek tűnik az ötletünk amit szeretnénk megvalósítani.
A gyorsan elkészíthető, tisztán modulos megoldások itt sokkal nagyobb kötöttségeket jelentenek, rengeteg funkció nem megvalósítható bennük, így általában nem ússzuk meg a kódolást. Van azonban pár költségcsökkentő megoldás, ami nem megy a végső termék minőségének kárára és nem is igényel olyan brutális befektetést.

Nézzünk két költségcsökkentő megoldást:

1. MVP - Azaz Minimum Viable Product

Ez a termék első olyan verziója, amelyet a végfelhasználók a kezükbe kaphatnak. Nem képes az eredeti elképzelés minden egyes funkciójának megvalósítására, de nem is ez a célja.
Úgy működik, hogy a végső termékből megpróbálunk előállítani egy olyan verziót, amely már értékelhető, hasznot hoz a felhasználók számára, örömmel használják. Így az elején ugyan rengeteg funkciónk kimarad valószínűleg az eredeti elképzelésből, azonban lényegesen csökken a piacra lépési költségünk. Kisebb a kockázat, gyorsabban elkészül, hamarabb kezd el termelni.
Természetesen az MVP verzió elkészülte után nem szokás úgy hagyni az alkalmazást. Ilyenkor kezdjük el beépíteni azokat a mellékfunkciókat, amelyeket eredetileg is elképzeltünk pluszban, de a minimumban nem voltak benne. Több iterációban érdemes végighaladni, mivel így a végén nem egy nagy frissítést kell kiadnunk (ez általában egyébként is problémás), hanem több kicsit, szépen sorban. Így tervezhetőbbek és kiegyenlítettebbek lesznek a költségek, illetve a felhasználóink is örülnek, hiszen sokkal hamarabb megkapnak egy-egy új, hasznos funkciót.

Tehát röviden egy alacsonyabb költségből adunk egy már használható verziót, majd pedig az első bevételekből befejezzük a végleges applikációt.

2. Cross-Platform megoldások

Ritkán kérnek tőlünk olyat, hogy csak egyetlen platformra fejlesszünk, általában mindenkinek kettő vagy több kell. Ma már léteznek olyan technológiák, amellyel a kódbázis megosztható az eltérő hardverek és operációs rendszerek között, így a fejlesztés és az utólagos bővítés, esetleg hibajavítás könnyebb, gyorsabban elvégezhető feladat.

Rengeteg Cross-Platform technológiával találkoztam, hogy válasszak?

A legelső lépés a célplatform-alapú szűkítés legyen. Határozzuk meg, hogy milyen rendszereken, eszközökön akarunk megjelenni. Ezzel általában drasztikusan le is csökken a lehetőségek száma.
Ezután érdemes a támogatást, illetve a mögötte álló közösséget ellenőrizni, hiszen az ő munkájukra fogunk támaszkodni és tőlük kérhetünk segítséget is ha elakadunk. Ezt megtehetjük Githubon, stackoverflown, saját belső fórumokon például.
Ha még mindig túl sok a lehetőség, akkor érdemes az általunk preferált tech-stacket megpróbálni kikeresni. Tehát, ha nekünk mobilos fejlesztés kell és a C# áll kézre, akkor a Xamarin jó választás lehet, míg ha a Javascript, de nem ijedünk meg minimális natív kódtól sem, akkor például a React Native, de ha a Dart szintaxisa tetszik, akkor a Flutter lehet a helyes út.
A lényeg, hogy soha ne felejtsük el, hogy a technológiát mindig a célhoz igazítsuk és ne fordítva. Ha érdekel az app készítés, kattints ide és tekintsd meg oldalunkat.

Valójában, ha biztosak vagyunk benne, hogy egynél több platformra szeretnénk appunkat lefejleszetetni, akkor érdemes választani a cross platform megoldásokat, hiszen akár 30-40% költséget is spórolhatunk. Persze ettől még egy teljesen egyedi és jól működő applikációt kapunk.