Check it out
Wat kost een webapp? Scope, data en koppelingen uitgelegd
Wat kost een webapp? Dat kan een kleine oplossing van €2.000 zijn, maar ook een groter traject van €30.000 of €50.000. Bij BORING komen die verschillende groottes voor. Het zijn geen vaste pakketten en ook geen onder- of bovengrens voor iedere opdracht. Het probleem dat we oplossen en de scope daarvan bepalen wat er nodig is.

Dat maakt een algemeen prijskaartje weinig bruikbaar. Een tool waarmee één medewerker leads controleert is een andere opdracht dan een volledige membershipomgeving die onderdeel wordt van je dienstverlening. Ze werken allebei in de browser, maar daarmee houdt de vergelijking al snel op.
Je krijgt meer grip op de kosten door te kijken naar wat gebruikers moeten kunnen doen, welke gegevens daarbij horen en hoe de oplossing aansluit op de rest van je bedrijf.
Een kleine oplossing kan een heel gerichte taak hebben
Een voorbeeld van een kleine opdracht is een simpel dashboard voor een CRM-partij. Leads komen eerst in die omgeving terecht. Het team bekijkt ze, neemt contact op voor een belafspraak en controleert ze voordat ze naar het eigen CRM worden doorgestuurd.
De waarde zit hier in één duidelijke stap: een lead eerst kunnen beoordelen en daarna gecontroleerd doorzetten. Je hoeft daar niet automatisch een compleet nieuw CRM voor te bouwen.
Ook bij zo'n kleine oplossing moeten een paar dingen goed worden afgesproken. Wanneer is een lead gecontroleerd? Wie mag de status wijzigen? Wat gebeurt er als het doorsturen mislukt? Als die route duidelijk en afgebakend blijft, kun je de bouw daarop richten.
Dit voorbeeld is geen prijspakket. Een extra rol, andere koppeling of afwijkende werkwijze kan de opdracht al veranderen.
Een membershipomgeving raakt meer onderdelen
Aan de andere kant kan de opdracht zijn om een volledige membershipomgeving te ontwikkelen, specifiek gericht op het product of de dienst van een klant. Dan ontwerp je een omgeving waar gebruikers langere tijd terugkomen en waar een groter deel van de dienstverlening plaatsvindt.
Afhankelijk van het product moet je bijvoorbeeld nadenken over toegang, verschillende lidmaatschappen, persoonlijke inhoud, betalingen of voortgang. Niet iedere membershipomgeving heeft al die functies nodig. Juist daarom werken we eerst uit wat een lid moet kunnen doen en wat het team erachter beheert.
De samenhang maakt zo'n project groter. Een verandering in een lidmaatschap kan gevolgen hebben voor toegang, communicatie en administratie. Die routes moeten worden ontworpen, gebouwd en getest. Het aantal zichtbare pagina's vertelt daardoor maar een klein deel van het verhaal.
Wat bepaalt de hoeveelheid werk?
Een paar keuzes hebben veel invloed op de scope. Het helpt om ze vroeg concreet te maken:
- Gebruikers en rollen: werkt alleen je eigen team ermee, of ook klanten en externe partners? Wat mag iedere rol zien en wijzigen?
- Processtappen: hoeveel handelingen, beslissingen en uitzonderingen moet de app ondersteunen?
- Gegevens: komen die uit één bron, moeten ze worden opgeschoond of verhuist er bestaande informatie mee?
- Koppelingen: welke systemen moeten samenwerken en wat gebeurt er als die tijdelijk niet reageren?
- Gebruik en beheer: wat moet jullie team zelf kunnen aanpassen en hoe ondersteunen we gebruikers na oplevering?
Een koppeling die alleen een nieuwe lead doorstuurt is bijvoorbeeld iets anders dan twee systemen die continu elkaars wijzigingen moeten bijhouden. En één vaste gebruikersrol vraagt andere keuzes dan een organisatie waarin beheerders zelf rechten uitdelen.
Daarom kijken we naar hele gebruikersroutes, inclusief de situaties waarin iets ontbreekt of misgaat. Die bepalen mede hoeveel ontwerp- en testwerk nodig is.
Houd het project en de terugkerende kosten uit elkaar
Bij de investering in het project kijk je naar ons proces: discovery, concept, design en build. Tijdens discovery onderzoeken we het probleem en de scope. Daarna werken we uit hoe de oplossing functioneert, hoe die eruitziet en hoe we haar bouwen.
Daarnaast zijn er kosten voor hosting en eventuele extra tooling. Denk aan de diensten die nodig zijn om de app beschikbaar te houden of om een specifieke functie te ondersteunen. Welke daarvan nodig zijn, volgt uit het project. Een custom webapp is bij ons niet automatisch aan één platform gebonden.
Maak ook afspraken over beheer, ondersteuning en doorontwikkeling. Wie pakt een storing op? Wat valt binnen onderhoud en wat is een nieuwe functie? Zo weet je welke kosten bij de realisatie horen en welke afspraken daarna doorlopen.
Maak de eerste versie klein genoeg om te toetsen
Je hoeft niet iedere toekomstige wens meteen te bouwen. Kies een eerste versie waarmee gebruikers een nuttige taak volledig kunnen afronden. Dat is iets anders dan overal een halve functie neerzetten.
Bij het leaddashboard kan dat de complete route van binnenkomst tot gecontroleerde overdracht zijn. Voor een membershipomgeving bepaal je eerst welk onderdeel van de dienstverlening in de eerste versie beschikbaar moet zijn. Nieuwe functies kunnen daarna volgen op basis van echt gebruik.
Dat helpt om de investering gericht te houden, zonder te doen alsof een grote oplossing altijd voor een klein budget kan worden gebouwd.
Wil je weten wat jouw webapp kost? Neem het probleem mee naar een gesprek, samen met de huidige werkwijze en de systemen die je gebruikt. Een korte uitleg van waar mensen vastlopen is een beter begin dan een lange wensenlijst zonder prioriteit. Vanuit daar kunnen we een scope bepalen waar een onderbouwde begroting bij past.




