Apps ontwikkelen: onbeperkt spareribs, McDrive of een sterrenrestaurant?
Dat het bouwen van enterprise mobiele apps de laatste tijd een vlucht neemt is je vast niet ontgaan. Potentiële kopers van een mobiele app vragen regelmatig “wat kost dat nou, zo’n app bouwen?”. De wat beter ingelezen klant heeft soms al zelf de conclusie getrokken hebben dat apps bouwen een kostbare aangelegenheid is.
Want: en dan volgen er een hele reeks aannames en feiten als “Android is zo gefragmenteerd” en “voor ieder mobile operating system is weer een nieuw ontwikkelproject” of “mobile web doet het altijd en is dus veel goedkoper”.
Het goede nieuws is: iedereen heeft gelijk, het slechte nieuws: er is geen one size fits all-antwoord. Iedere moderne smartphone heeft momenteel een redelijk functionerende browser aan boord. De native app is de meest complexe ontwikkelmethodiek voor mobiele oplossingen, maar geeft je meer mogelijkheden om het maximale uit het toestel te halen.
Ook een ontwikkelplatform-aanpak kan een prima keuze zijn, zolang deze maar bewust en op basis van de juiste parameters gemaakt wordt.
Wanneer gebruik je welke methode? Denk als de horeca!
Wanneer gebruik je nu dan welke ontwikkelmethode? Wat zijn nou precies die parameters waarop je een development-beslissing kunt nemen? Er is geen standaard of correct antwoord. Daarom zetten we in dit artikel met een metafoor en enkele overwegingen uiteen hoe je zelf tot een (gedeeltelijk) correct en voor jou passend antwoord kunt komen. De metafoor is gebaseerd op de horeca. Net zoals bij app-development zijn er, als je uit eten wilt gaan, diverse soorten restaurants om de honger te stillen.
Onbeperkt spare-ribs
Voor een redelijke prijs is het over het algemeen prima onbeperkt spare-ribs eten. Je weet dat het eten van redelijke kwaliteit is maar je weet ook dat het niet op een heel elegante manier zal worden klaargemaakt en opgediend. Ook de ingrediënten zijn eenvoudig en voorspelbaar. Onbeperkt spare-ribs eten is voor af en toe best prima en gezellig. Zo ook mobiele web apps.
Drive-through fastfood
Fastfood-ketens zijn vooral goed in het zo kosten-efficiënt en snel mogelijk produceren van voedsel dat voor zoveel mogelijk mensen als eetbaar wordt ervaren. Vooral lage prijzen, hoog volume en een hoge productiesnelheid zijn van belang. Als smaak en kwaliteit van ingrediënten niet het meest belangrijk is, dan is fastfood wellicht in een aantal gevallen een geschikte hongerstiller, zeker voor grote groepen gasten.
Als je voor deze route kiest dan kies je ervoor (lees: moet je van plan zijn) om een hele reeks apps te produceren die binnen een beperkte tijd ontwikkeld moeten worden en moeten kunnen draaien op meerdere platforms (lage prijs, volume en snelheid). Maar let op: je moet het restaurant (de platformsoftware-licenties) er wel bij aanschaffen.
Het sterrenrestaurant
Wil je een tot in de puntjes verzorgd diner waarbij alles klopt en naar wens is, dan ga je naar een sterrenrestaurant. Zodra je binnenstapt weet je dat je een meer dan gemiddelde prijs zult betalen voor een gerecht, maar daarentegen zal de restaurateur er ook alles aan doen om de klant het zo goed mogelijk naar de zin te maken.
De gerechten zijn complex en de ingrediënten van zeer hoge kwaliteit. Er is zelfs een goede kans dat de chef ook nog aan tafel komt om de controleren of alles naar wens is. Kortom, maximale beleving maar in vergelijking met de andere horeca-concepten kostbaar als je vaak of met een groot gezelschap uit eten gaat. Kortom, apps die functioneel, technisch en visueel complex zijn, vragen om een native (maatwerk) aanpak.
Overwegingen & tegeltjeswijsheden
Waar moet je verder nog aan denken bij je keuze? Ik zet wat eigen tegeltjeswijsheden voor je op een rij:
-iedere app gebruikt een server back-end-
Apps draaien vrijwel nooit stand-alone. 99 van de 100 keer zal de app periodiek danwel continu gevoed moeten worden vanuit een serveromgeving. Hou rekening met de beveiliging en toegankelijkheid van de server en de daarop aanwezige content. Bedrijfsinformatie staat doorgaans achter een firewall en het opstarten van een VPN-verbinding om een app te kunnen gebruiken is niet gebruiksvriendelijk.
-app ontwikkelkosten zitten ook in de back-end-
Omdat een app bijna altijd gebruik maakt van backend-systeem is het noodzakelijk het ontsluiten van het back-end mee te nemen in de begroting. Het kan zomaar zijn dat de kosten hiervan hoger zijn dan het bouwen van de app zelf!
-een goede API is belangrijker dan de app zelf-
Mobile devices en bijbehorende mobile operating systems veranderen continu. De apps die je ontwikkelt hebben wellicht maar een houdbaarheid van maximaal 24 maanden. Je back-end daarentegen zal vaak langer mee (moeten) gaan. Investeer dus in een schaalbare robuuste API op je backend-omgeving en bedrijfsgegevens zodat je je (nog te bouwen) apps daarop op een uniforme manier kunt laten aansluiten.
-een veelgebruikte app moet een native app zijn-
Hoe vaker men een app gebruikt (veel eyeball time) hoe belangrijker een maximale user experience is. Snelheid, offline gebruik, beveiliging en perfecte integratie met andere apps, maximaal gebruik van de hardware en koppelingen met social media zijn doorgaans zeer wenselijke eigenschappen van een app. Native app development biedt je deze mogelijkheden en is dan vaak the way to go voor veelgebruikte apps. Je gebruikt toch ook liever een Twitter-app dan de mobiele Twitter-website?
-content is king-
Een app is weinig waardevol als de daarin aangeboden informatie en functionaliteit niet actueel, relevant en correct is. Er moet dus een balans gevonden worden tussen vorm, functie en inhoud. Teletekst is een mooi voorbeeld. Het heeft geen mooie uitstraling, maar vanwege de kwaliteit van de content en de snelheid worden er nog miljoenen pagina’s per dag gelezen door mobiele gebruikers!