Je bent hier hoogstwaarschijnlijk gekomen omdat je een idee of probleem hebt dat je mogelijk kunt oplossen met een webapplicatie, webapp, app, integratie of API. Iets in die richting, maar je weet nog niet precies hoe je dat gaat aanpakken. In dit artikel help ik je graag op weg met enkele valkuilen bij het maken van een webapplicatie.
Ik help je graag verder met dit artikel, maar je mag natuurlijk ook je contactgegevens achterlaten zodat we je ideeën kunnen bespreken.
- Doel & functionaliteiten
- Budget & resources
- Technische keuzes
- Onderhoud en doorontwikkeling
Doel en functionaliteiten
Je hebt een idee voor een webapplicatie, of je hebt een technische uitdaging waarvoor een maatwerk webapplicatie de oplossing kan bieden. Het maakt eigenlijk niet zoveel uit wat de reden is dat je hier bent; in alle gevallen heeft een webapplicatie een doel, een reden van bestaan.
Het doel bepaalt voor een groot deel hoe je beslissingen gaat maken in de rest van het proces. Als het gaat om een SaaS-applicatie waarbij je een nieuwe dienst introduceert en daar geld mee wilt verdienen, is het belangrijk om te bewijzen dat je idee werkt met de juiste functionaliteiten (product-market fit). Zo is de terugverdientijd korter en wordt het gemakkelijker om op te schalen.
Voor interne applicaties ligt het net anders; daar gaat het vaak om het verbeteren van een werkproces of het oplossen van een specifiek probleem binnen een organisatie. Het doel is dan bijvoorbeeld het gemakkelijker maken van het schrijven van offertes of een verbeterde orderverwerking.
Hoe dan ook, het is gemakkelijk om het doel uit het oog te verliezen doordat er allerlei geniale nieuwe ideeën opkomen.
De functionaliteiten moeten daarbij aansluiten. In grote lijnen kun je die van tevoren bedenken. Als je op zoek bent naar een product-market fit, dan is veel uitproberen en luisteren naar je klanten belangrijk om tot de juiste functionaliteiten te komen. Deze zoektocht kan soms meerdere iteraties duren.
Bij bedrijfsapplicaties is het vaak veel duidelijker wat de functionaliteiten zijn, omdat de gebruikers vaak je collega’s zijn, en het gemakkelijk is om hun wensen in kaart te brengen. Maar ook hier geldt dat, zeker bij complexere projecten, het meerdere iteraties kan duren voordat de functionaliteiten compleet zijn.
Om dit proces te versnellen, beginnen wij vaak met een discovery-fase, soms ook sprint-0 genoemd. Wij brengen onze technische kennis en ervaring mee om samen naar het doel en de functionaliteiten te kijken. Het eindresultaat, een duidelijk plan, afwegingen en focus.
Budget en resources
Zowel het budget als andere resources worden vaak onderschat, maar ze zijn toch echt heel belangrijk voor het succes.
Budget voor een webapplicatie
Je hoort het natuurlijk erg vaak, maar jou gaat het niet overkomen: het project gaat over budget. Zoals het FD schreef: budgetoverschrijdingen bij grote projecten zijn eerder regel dan uitzondering. Het lijkt wel meer regel dan uitzondering.
Complexiteit en verkeerde focus spelen hier vaak een grote rol. Het verkleinen van de complexiteit van het project en het snel behalen van resultaat zorgen ervoor dat de webapplicatie op de lange termijn ook een succes wordt. Met andere woorden: we moeten plannen voor de toekomst, maar iteratief een webapplicatie ontwikkelen, testen en uitbrengen, zodat de complexiteit meegroeit met het gebruik en je gemakkelijk kunt bijsturen.
Tijd van jou en je collega’s
Nagenoeg altijd onderschat: de tijd die jij of je collega’s aan het project besteden. Wij, of andere developers, weten veel, maar niet alles. Gedurende het project zal er echt tijd en toewijding nodig zijn van jou en/of je collega’s om te sparren over functionaliteiten, mee te denken of iets wel handig is, en om te testen.
Het is goed om hier van tevoren afspraken over te maken en bij stil te staan. Het zit allemaal in communicatie en wederzijds begrip.
Technische keuzes
De keuze voor technieken lijkt soms niet zo belangrijk, vooral als je een partij hebt gevonden die het voor de helft kan doen. Je bent al lang blij. Maar ook hier geldt: wat zijn je doelen? Als je snel een SaaS-product wilt lanceren en het prima vindt om later alles opnieuw te bouwen, maak je andere keuzes dan wanneer je een interne webapplicatie wilt bouwen die de komende tien jaar een betrouwbaar API- en integratieplatform moet zijn.
Pas op met shiny new things.
Een belangrijke IT-term die vaak negatief klinkt, is legacy, ook wel eens ouwe meuk genoemd. Legacy software betreft applicaties die lang geleden zijn ontwikkeld en waar je lastig vanaf komt. Als je erover nadenkt, zijn legacy systemen misschien niet sexy, maar wel succesvol.
Het tegenovergestelde zijn shiny new things, geen officiële IT-term en het tegenovergestelde van legacy: wel sexy, maar (nog) niet succesvol. Dit zijn vaak nieuwe, hippe technologieën of tools die zich nog niet hebben bewezen en waarvan je niet weet of ze er over vijf jaar nog zijn. Wees daar alert op.
Onderhoud en doorontwikkeling
Een vuistregel is dat je 20% van de ontwikkelkosten moet rekenen als hosting- en onderhoudskosten. Hoe je het ook wendt of keert, meestal komt de investering hierop uit. Soms wordt er bezuinigd op onderhoud, wat kan betekenen dat niet alles wordt geüpdatet of dat foutmeldingen niet actief worden onderzocht. Dit betekent dat je webapplicatie onveiliger wordt en dat mogelijke bugs niet worden opgelost of juist ontstaan. Als die fouten pas bij nood worden opgelost, kunnen ze er al lange tijd in zitten.
Door onderhoud beperkt of niet uit te voeren, kan het steeds lastiger worden om nieuwe functionaliteiten toe te voegen. In sommige gevallen wordt dit zelfs onmogelijk.
Doorontwikkeling valt hier nog niet onder en is uiteraard afhankelijk van je wensen en het succes van je webapplicatie.
De valkuilen bij een webapplicatie laten maken
- Doel en functionaliteiten
- Houd focus op het hoofddoel, ondanks nieuwe ideeën.
- Ontwikkel iteratief en test regelmatig.
- Bij bedrijfsapplicaties zijn de functionaliteiten vaak duidelijker, maar meerdere iteraties zijn nodig.
- Budget en resources
- Budget en tijd worden vaak onderschat.
- Complexiteit en focus beïnvloeden budgetoverschrijdingen.
- Voldoende tijd van jou en je collega’s is nodig om samen te werken met ontwikkelaars.
- Technische keuzes
- Kies technologieën die passen bij je doelen.
- Pas op voor “shiny new things” die nog niet bewezen zijn.
- Legacy systemen zijn misschien minder sexy, maar vaak wel succesvol.
- Onderhoud en doorontwikkeling
- Onderhoud is essentieel voor veiligheid en functionaliteit.
- Onderhoudskosten bedragen ongeveer 20% van de ontwikkelkosten.
- Gebrek aan onderhoud kan het toevoegen van nieuwe functionaliteiten moeilijk maken.
Advies
Ik denk dat het belangrijk is om deze zaken in je achterhoofd te houden. Een succesvol project is voor iedereen leuk! Goede en open communicatie is essentieel om elkaar te begrijpen: wat wil jij bereiken en hoe kunnen wij dat het beste realiseren?
Mocht je geheel vrijblijvend willen sparren, laat dan je contactgegevens achter!
Waar moet ik aan denk bij een webapplicatie laten maken?
Bij het maken van een webapplicatie zijn er enkele belangrijke valkuilen om in gedachten te houden. Houd altijd focus op het hoofddoel en ontwikkel iteratief om nieuwe ideeën te balanceren met de oorspronkelijke plannen. Budget en tijd worden vaak onderschat, terwijl het cruciaal is om realistische verwachtingen te hebben en voldoende tijd vrij te maken voor samenwerking met het team. Technologische keuzes moeten aansluiten bij je lange-termijndoelen, en het is belangrijk om niet te veel te vertrouwen op “shiny new things” die nog niet bewezen zijn. Daarnaast is onderhoud essentieel; het verwaarlozen ervan kan leiden tot veiligheidsproblemen en het moeilijker maken om nieuwe functionaliteiten toe te voegen.
Wat zijn voorbeelden van shinny new thing?
Denk bijvoorbeeld aan AI. Sinds ChatGPT publiek beschikbaar is geworden, lijkt AI het antwoord op alles, maar dat is het niet. De tools die je ervoor kunt gebruiken veranderen bijna dagelijks. Het slim inzetten van AI kan je echter wel helpen.
Is het mogelijk software na te bouwen?
Ja, natuurlijk, maar dit kan ook een grote valkuil worden. Als het gaat om bestaande software na te bouwen om er zelf een dienst mee aan te bieden, houd er dan rekening mee dat die software vele iteraties heeft doorlopen. Jouw doelgroep is mogelijk anders, en je zult ook op zoek moeten naar jouw eigen product-market fit.
Als het gaat om een bestaand systeem (legacy) nabouwen, houd er dan rekening mee dat er waarschijnlijk veel ongedocumenteerde functionaliteiten en uitzonderingen zijn, wat het nabouwen mogelijk ingewikkeld maakt.