3 belangrijke overwegingen bij het bouwen van een app
In het kort:
- Definieer het minimale product: Breng de visie van stakeholders terug tot de kern (MVP) om efficiënt te starten en later uit te breiden.
- Werk met sprints: Ontwikkel één functionaliteit per keer om bij te sturen, kosten te beheersen en efficiënt te ontwikkelen.
- Beheer koppelingen en systeembelasting: Anticipeer op groeiende gebruikersbelasting en ontwerp een passende IT-infrastructuur om kosten te optimaliseren en efficiëntie te waarborgen.
3 belangrijke overwegingen bij het bouwen van een app
Applicaties zijn overal, in alle soorten en maten. Bedrijven maken er meer en meer gebruik van. Zowel intern als extern en zowel voor communicatie en interactie richting (mogelijke) klanten als voor het slim verwerken van interne data. Apps zijn in veel gevallen een front-end met daarachter een slim systeem om data te presenteren of juist te combineren. Maar hoe maak je nou een goede app? En waar moet je rekening mee houden? Een overzicht van drie overwegingen die nog wel eens vergeten worden.
1. Wat is het minimale product dat je nodig hebt?
Apps worden vrijwel nooit bedacht door technici, maar door de business. Bijvoorbeeld de marketingafdeling of juist de HR-afdeling. De kans is groot dat zij de app al helemaal voor zich zien, met alle bijbehorende toeters en bellen. De kunst is vervolgens om deze visie terug te brengen tot de kern; versie 1.0. Wat is er minimaal nodig om de app te laten draaien? Dat is belangrijk omdat je weliswaar veel van tevoren kunt voorspellen, maar nooit alles. Heb je de basis eenmaal draaien, dan kun je verder bouwen aan meer. Bij Thesio noemen we dit vaak een MVP (minimum viable product). We hebben vaak meegemaakt dat een ondernemer het lastig vindt om een enorm idee terug te brengen naar een MVP variant, maar het is tot nu toe altijd gelukt.
2. Laat je app onderweg ‘groeien’!
Apps ontwikkelen kost veel tijd en geld. Het is dus belangrijk om je ontwikkeling efficiënt te laten verlopen. En dat doe je door te werken met ‘sprints’ waarbij je bijvoorbeeld één functionaliteit per keer volledig uitschrijft, ontwikkelt en oplevert. Voor de business owner heeft dit twee grote voordelen: je kunt onderweg bijsturen in de details van de functionaliteiten en daarnaast levert het kostenbeheersing op. Als je eenmaal weet wat één functionaliteit met een x-aantal details in de praktijk kost, heb je ook een goede inschatting van de kosten voor functionaliteit nummer twee en drie.
3. Houd rekening met koppelingen en de belasting van je systeem.
Een app toont, verstuurt en verwerkt data. In veel gevallen komt deze data van meerdere plekken tegelijk en van zowel interne als externe databronnen. Daarbij zijn er twee belangrijke vragen die je jezelf van tevoren moet stellen:
- Hoeveel koppelingen heb ik nodig?
- Over welke hoeveelheid data gaat het en met welke techniek komt dat binnen? (afhankelijk van het aantal actieve gebruikers)
Naarmate je verwacht dat je app meer gebruikt wordt, wordt de belasting op de verbindingen tussen de databronnen en de app namelijk groter. De kunst is om je architectuur zo te ontwikkelen dat je hem zeker niet te klein maakt, maar bij voorkeur ook niet te groot. Want dan geef je meer uit dan nodig. Een goede inschatting van het verwachte gebruik en het kiezen van de juiste IT infrastructuur heeft dus enorme consequenties voor het ontwikkelingstraject van je app.