Voor het laatste geactualiseerd op

Je organisatie groeit of automatisering is vereist om de volgende stap te maken. Soms heb je daarbij specifieke functionaliteiten nodig. Zo kan je extra software nodig hebben om je sales te structureren of om je interne processen te stroomlijnen. De kosten van een webapplicatie kunnen erg uiteenlopen. Dit hangt af of je maatwerk of een standaard webapplicatie wilt. Hierbij moet je denken aan maandelijkse kosten en investeringskosten. De maandelijkse kosten kunnen bij een standaardapplicatie €49,- zijn en bij maatwerk €1000. Daarnaast zijn er nog instapkosten die beginnen bij €1490. Daarnaast worden er nog kosten per uur berekend.

Er zijn een hele hoop standaard webapplicaties op de markt. In een aantal gevallen bestaat er echter geen standaard webapplicatie voor jouw specifieke wens. In deze situatie is het zinvol om je te verdiepen in het laten maken van software. In dit artikel leggen we je haarfijn uit wat de kosten zijn voor een webapplicatie. 

De volgende onderwerpen en vragen nemen we onder de loep:

Wat is een webapplicatie?

Voordat we verder gaan naar het kostenplaatje zullen we nog even op een rijtje zetten wat het verschil is tussen een website en een webapplicatie is. Een website is een verzameling van (statische) pagina’s die in bijna alle gevallen toegankelijk zijn voor iedereen die het wil gebruiken. Waar het verhaal zich bij websites aan de voorkant afspeelt gaat het bij webapplicaties het grootste gedeelte om de functionaliteiten aan de achterkant. 

Lees hier meer over wat een website kost of ons artikel over de prijs van een webshop.

Anders dan het laten maken van een website wordt een webapplicatie ingezet om bedrijfsprocessen te versnellen, het aantal fouten te reduceren of meer omzet te genereren en zijn ze niet zomaar voor iedereen toegankelijk. Omdat webapplicaties veel meer complexe functionaliteiten bevatten zijn ze een stuk duurder om te ontwikkelen in tegenstelling tot de meeste websites. 

Het verschil tussen standaard en maatwerkapplicaties 

Eerder in dit artikel spraken we over standaard webapplicaties en maatwerk webapplicaties. Waarin de een je voorziet van standaard functionaliteiten zal de ander volledig gebouwd zijn op basis van jouw behoeften. Dit verschil is alles bepalend voor het uiteindelijke kostenplaatje. Vergelijk dit met het bouwen van een huis, laat je een door een befaamde architect ontworpen luxe villa met zwembad bouwen of een standaard appartement? Afhankelijk van de complexiteit van jouw eisen en wensen biedt een van de twee de oplossing.  

Voor niet al te complexe verwachtingen kom je al snel terecht bij standaard webapplicaties. Bij standaard webapplicaties zijn standaard functies ingebouwd die voor meerdere partijen ontwikkeld zijn. Je kan hierbij denken aan kant en klare boekhoudsystemen, agendaplanners of projectmanagementsystemen. Standaard webapplicaties worden via een licentie afgenomen die veelal de toegankelijkheid tot verschillende functionaliteiten bepaalt. Een standaard applicatie kan soms na afname geconfigureerd en gekoppeld worden aan jouw website of andere systemen. 

Anders dan een standaard webapplicatie zijn maatwerkapplicaties volledig gebouwd op basis van de eisen en wensen van één bedrijf. Maatwerk komt kijken bij complexe wensen waar nog geen standaardoplossing voor is. Dit kan bijvoorbeeld het geval zijn indien de standaard software voor een specifieke branche niet voldoet aan de wensen, maar ook als het gaat om de ontwikkeling van een innovatief product.

De voor- en nadelen van standaard en maatwerkapplicaties

Sommige zien het licht aan het einde van de tunnel middels een standaardoplossing óf maatwerk. Beide gevallen hebben zo hun eigen voor- en nadelen. We gaan je precies vertellen waar je zoal mee te maken krijgt bij het gebruik van standaard applicaties en maatwerkapplicatie, zowel positief als negatief. 

Standaard webapplicaties

  • In de meeste gevallen een goedkopere optie
  • Dekt de meeste standaard functionaliteiten
  • Direct een oplossing (geen ontwikkeltijd)
  • Goed doorgetest (meerdere gebruikers)
  • Verbonden aan periodieke kosten
  • Minder aansluiting met eigen werkprocessen
  • Te weinig vrijheid met standaard applicaties
  • Bestaande applicaties hebben te veel functionaliteiten
  • Bestaande applicaties hebben te weinig functionaliteiten
  • Je bent als klant vaak een nummer


Op maat gemaakte webapplicaties

  • Dekt elk verzoek voor een functionaliteit
  • Veel vrijheid binnen eigen maatwerk
  • Veelal lagere periodieke kosten
  • Je bent een belangrijke klant bij je ontwikkelpartner
  • Eindresultaat sluit beter aan op het bedrijf en de werkprocessen
  • Het bied je een onderscheidend vermogen
  • Op maat gemaakte applicaties zijn waardevol voor de bedrijfsverkoop
  • Het is prijzig
  • De oplossing dient nog ontwikkeld te worden en is dus pas later beschikbaar.
  • Minder goed doorgetest (minder gebruikers)
  • Als klant moet je een proactieve rol innemen bij het ontwikkelproces
  • Groter risico op eindresultaat zoals ontwikkelcomplicaties en budgetoverschrijdingen
  • Je hebt onderhoudskosten om je software up to date te houden

Ons advies is in de meeste gevallen een standaardoplossing. Want bestaat er al een applicatie die jou kan helpen? Vooral dat kiezen. Overstijgt de behoefte voor maatwerk toch? Dan is het raadzaam om te controleren of dat zichzelf terugverdient. Maatwerk biedt wel het voordeel dat je het zo kan inrichten dat het aansluit op jouw werkproces, bij een standaardoplossing blijft dat nog altijd de vraag.   

De uiteindelijke keuze en het advies dat wij je voorleggen zal puur gebaseerd zijn op je situatie, doelen, missie en visie, soort functionaliteiten en de complexiteit hiervan. Mocht je met ons het partnerschap aan willen gaan dan zullen we je eerst het hemd van het lijf vragen alvorens we een zo’n gericht en eerlijk mogelijk advies kunnen geven. Zo weet je meteen waar je aan toe bent!

Prijsindicatie voor jouw webapplicatie?

Vertel ons meer over jouw project

Ik help je graag een stap verder in jouw project!

Wat levert een maatwerk of standaardoplossing op?

De praktijk leert ons dat een standaardoplossing soms voordeliger is dan maatwerk, maar in andere gevallen loont het meer om met een maatwerkteam in zee te gaan. Uit de praktijk geven we vier voorbeelden waar zowel beide een betere keuze waren ten op zichtte van de ander:

Maatwerkoplossing
Een partij binnen de logistieke branche zocht naar de beste oplossing om al hun interne processen aan elkaar te knopen. Het ging hierbij om een planningsysteem, sales systeem en de bijbehorende administratie. Ze vonden daarvoor hun oplossing in een standaard webapplicatie die meer functionaliteiten heeft dan ze daadwerkelijk nodig hadden. Hier is waar het interessant wordt: de instapkosten voor de bestaande oplossing bedroegen €20.000. Daarbovenop kwamen er nog eens €1000 aan maandelijkse kosten bij. Uiteindelijk kwam de partij naar ons toe voor een consult vanwege de hoge kosten. Ons advies was maatwerk. Binnen Web Whales hebben wij een nieuwe applicatie voor ze ontwikkeld voor €40.000. De applicatie was kleiner en enkel uitgerust met de functionaliteiten die ze nodig hadden. De kosten voor maatwerk waren uiteindelijk binnen ongeveer anderhalf jaar terugverdiend

Standaardoplossing
Binnen Web Whales hebben we een eigen webapplicatie gemaakt genaamd WooConnect. WooConnect koppelt de e-commerce module van een kassasystemen aan WooCommerce om voorraadbeheer en orderafhandeling te automatiseren. Het ontwikkelwerk voor een dergelijke webshop koppeling zou een klant normaal €28.000 kosten. Wanneer ze een licentie bij ons zouden afnemen zouden de instapkosten €1490 bedragen met een maandelijks bedrag van €49. Mocht de klant de koppeling toch zelf willen laten ontwikkelen dan zouden de kosten pas terugverdiend worden binnen 50 á 60 jaar. In een situatie als deze wil je geen maatwerk omdat je uiteindelijk veel duurder uit bent.

Maatwerkoplossing
Een klant had de wens om te besparen op interne processen. Deze interne processen werden handmatig uitgevoerd door zijn werknemers, welke €22,- per uur kosten. De automatisering hiervan heeft de klant €15.000 gekost, maar bespaarde hem 6 uur per week aan werk. Uiteindelijk heeft de klant de investering van €15.000 binnen 2.5 jaar terugverdiend. Met de verwachte groei van de organisatie was dit zelfs minder.

Standaardoplossing 
Fouten maken is menselijk. Ook tijdens de ontwikkeling van software worden fouten gemaakt. Soms kunnen deze fouten echter voorkomen worden. Stel dat er iedere maand 10 fouten worden gemaakt. Elke fout kost €500 en dat maakt €5000 op maandbasis en in een jaar al gauw €60.000. Als je de boel kan automatiseren en terug kan brengen naar 1 fout per maand, scheelt dat al €4500 per maand en op jaarbasis €50.000. De foutgevoeligheid bij systemen ligt veel lager dan bij mensen en is daarmee in sommige projecten een doorslaggevende factor voor automatisering. 

Bij allebei de keuzes kwamen mensen voordeliger uit, terwijl de keuze anders was.

Waarom blijft een kostenindicatie zo lastig om te maken?

Zoals te lezen in onze praktijkvoorbeelden variëren de prijzen voor maatwerk webapplicaties enorm. Het liefst zouden we direct gerichte offertes toesturen, maar helaas is dat niet de realiteit. Wel kunnen we je vertellen wat de belangrijkste factoren zijn die invloed hebben op de prijs:

  • Het aantal functionaliteiten
  • Complexiteit functionaliteiten
  • Samenwerking tussen de functionaliteiten
  • Hoeveelheid designwerk
  • Hoeveelheid front-end
  • Complexiteit algoritmes
  • Softwarekoppeling(en) met andere systemen
  • Omvang en diversiteit van de data

Het samenstellen van een webapplicatie kan gezien worden als een soort blokkendoos. Elke functionaliteit, elke koppeling, elke externe bron is een apart blokje. Naarmate je steeds meer blokken opstapelt moet er meer zorg worden gedragen om de stapel stabiel te houden.

Het lastige aan het geven van een gerichte prijs is dat je niet weet hoeveel blokken en welke complexiteit deze blokken hebben alvorens je de webapplicatie gaat verwezenlijken. Een eerste meeting met ons kan gezien worden als een traject waarbij we de basis zo duidelijk mogelijk voor ogen willen krijgen om dit in te schatten.  

Daaropvolgend weet de klant vaak wat hij wil, maar niet op detailniveau waardoor niet alle vragen beantwoord kunnen worden. Daarom pakken we projecten altijd agile aan om onzekerheden een stapje voor te zijn. We delen de stapel blokken op in kleinere stapeltjes om duidelijke stappen te specificeren. Dit biedt de mogelijkheid om stap voor stap in te zoomen op elk onderdeel binnen het project en van verschillende stakeholders veel input te krijgen zodat de functionaliteit volledig aansluit op de wensen.

Stappenplan: bereken de kosten van je maatwerkapplicatie

Omdat een exacte prijsberekening ontzettend lastig is voorzien we je van een aantal vuistregels voor het berekenen van een grove prijsrange. Belangrijk is om te weten dat dit slechts een schatting is en er normaliter een tot meerdere gezamenlijke sessies met je ontwikkelpartij nodig zijn om een gerichtere prijs te krijgen.

Stap 1. Automatisering bedrijfsprocessen

We beginnen bij de eerste stap: wat moet jouw applicatie allemaal doen? Welke bedrijfsprocessen worden geautomatiseerd? Dit is afhankelijk van jouw behoefte. Denk bijvoorbeeld aan tijdregistraties bijhouden, werk inplannen of het synchroniseren van voorraadbeheer. Dit zijn allemaal aparte bedrijfsprocessen. Ook koppelingen met andere systemen (API koppelingen) zijn op deze manier in te schatten.

Per proces of koppeling kost het gemiddeld 60 uur om deze als component op te nemen in de applicatie. Per component moet je ook nagaan hoe complex deze is. Een simpel component is het opnemen van een postcode API in de applicatie (gradatie 1). Een complex component is de integratie van een compleet productcatalogus bij het laten maken van een webshop (gradatie 5). Per component dien je de complexheid te bepalen aan de hand van de onderstaande vijf gradaties en daarvan het aantal uur te nemen. 

1: 10 uur
2: 30 uur
3: 60 uur
4: 100 uur
5: 150 uur

Indien je de complexiteit moeilijk kunt inschatten, ga je uit van het gemiddelde. Dit is 60 uur per component.

Stap 2. Design & Front-end

Nu komen we bij het aantal schermen. Je hebt bedacht welke bedrijfsprocessen worden geautomatiseerd. Bedenk nu welke acties verricht moeten worden en hoeveel schermen daarvoor nodig zijn. Voor elk scherm moet een design worden gemaakt. Vervolgens moeten deze schermontwerpen ontwikkeld worden. Dit is het front-end gedeelte. Hanteer de volgende vuistregel voor het berekenen van het aantal uur. 

Voor de basis, bestaande uit de huisstijl, navigatie en footer geldt 20 uur voor design. Daarbovenop komt er nog 4 uur per scherm bij. Voor front-end start de basis met 24 uur en daar komt er 6 uur per scherm bovenop. Denk aan het volgende voorbeeld waarbij we 8 schermen willen realiseren:

20 uur + (4 uur x 8 schermen) = (20 uur + 32 uur) 52 uur
24 uur + (6 uur x 8 schermen) = (24 uur + 48 uur) 72 uur 

Normaal hanteren we 4 uur voor een design per scherm en voor front-end 6 uur, maar dit is slechts een gemiddelde. Het kan voorkomen dat het hele simpele schermen zijn en de boel gerealiseerd kan worden in minder tijd, of je hebt juist een hoop complexe schermen die meer tijd kosten. Voor een realistischere berekening hanteer je het aantal uur per moeilijkheidsgraad:

Aantal uur per scherm voor design
Simpel:              2 uur 
Gemiddeld:       4 uur 
Complex:           8 uur 

Aantal uur per scherm voor front-end
Simpel:              3 uur 
Gemiddeld:       6 uur 
Complex:         12 uur

Stap 3. Overige taken

Overhead betekent in brede termen extra activiteiten die verricht moeten worden om het project te realiseren. Denk hierbij aan projectmanagement, het uitdenken van de software architectuur en het testen van het product. Gemiddeld wordt er 35% van het totaalaantal uren van het project gerekend voor deze overige taken. Hiervan gaat 20% naar testen, 10% naar projectmanagement en 5% naar het uitdenken van de software-architectuur. Met de onderstaande formule kan je het aantal uur voor deze overige taken zelf berekenen: 

0,35 x de totale uren voor de componenten, het design en de front-end = aantal uur overhead

Voorbeeld: je hebt in totaal 200 uur gerekend voor het implementeren van componenten, het designen van schermen en het ontwikkelen van deze schermen. Daarbovenop komen nog de uren voor de overige taken die je berekent met de formule: 0,35 x 200 = 70. Bovenop de 200 uur die je eerst al had berekend komen er nog eens 70 uur aan overige taken bij. 

Stap 4. Onderhoudskosten

Na afronding van je applicatie krijg je te maken met onderhoud. De onderhoudskosten zijn op jaarbasis ongeveer 15% tot 30% van de totale ontwikkelkosten. Het verschil zit in de hoeveelheid zekerheid die je wil en verwacht van je ontwikkelpartij. Je kan bijvoorbeeld een Service Level Agreement (SLA) contract afsluiten. Je spreekt dan af wat je van elkaar verwacht en of iemand ook ’s nachts klaar staat als er zich een probleem voordoet binnen jouw applicatie. Een contract als deze brengt meer zekerheid, maar kost daardoor ook meer. 

Ook het intellectueel eigendom binnen jouw applicatie is van invloed op de onderhoudskosten. Tijdens het ontwikkelen hoeft het wiel niet altijd opnieuw uitgevonden te worden. Het zou zomaar kunnen zijn dat je ontwikkelpartij al een aantal componenten klaar heeft staan om te implementeren in jouw product. Dit geldt als intellectueel eigendom van de ontwikkelpartij en wordt door de klant vaak afgenomen in de vorm van een licentie. Denk bijvoorbeeld aan 30% op maat en 70% standaard. Dus maak je gebruik van componenten waarbij het intellectueel eigendom bij je ontwikkelpartij ligt? Dan kan daar een bedrag per maand of jaar tegenover staan.

Gemiddeld kan je uitgaan van circa 20% onderhoudskosten per jaar.

Stap 5. De totale kosten

Aan de hand van onze vuistregels heb je het aantal uur berekend. Nu wordt dit aantal vermenigvuldigd met het uurtarief van de ontwikkelpartij. Hier verschillen de meeste partijen natuurlijk in. Om je globaal een beeld te geven van de ontwikkeltarieven in de markt hieronder een overzicht:

Gemiddelde prijzen ontwikkelpartijen
Goedkoop tarief:        
   €65,- per uur
Gemiddelde tarief:        €100,- per uur
Hoog tarief: 
                  €150,- per uur

Voor jouw berekening zou ik uitgaan van het gemiddelde. Prijs en kwaliteit gaan (vaak) hand in hand en vooral voor grotere webapplicaties zou ik niet rekenen met het goedkope (startend ZZP) tarief. Kwaliteit is namelijk het verschil tussen een applicatie die werkt en een applicatie die herschreven moet worden.

Uiteindelijk bereken je de prijs van jouw webapplicatie dus met de volgende formule:

Uurtarief ontwikkelpartij x het totaal aantal uren = de prijs van jouw applicatie. 

Onderhoudskosten

Voor je het weet is het moment eindelijk aangebroken dat je een eigen webapplicatie hebt laten bouwen. Hij is af en werkt als een trein en heeft de nodige investeringen gekost. De eindsprint behalen is een prachtig moment. Voor het kostenplaatje is het echter belangrijk om ook alvast een stapje verder te kijken. Zo krijg je bijvoorbeeld te maken met onderhoudskosten. Denk hierbij aan het volgende:

Software updates
Vernieuwing. Ook jouw nieuwe parel is toe aan onderhoud en vernieuwing en vereist updates om bruikbaar te blijven voor jou of jouw klanten. Je gebruikt bijvoorbeeld een PHP-framework waarvan geregeld nieuwe versies uitkomen. Zo zorg je er tevens voor dat de beveiliging van jouw webapplicatie op orde blijft.

Hosting
Ook op het gebied van hosting zijn er een hele hoop variaties af te nemen. Het soort hostingpakket zal afhangen van de complexiteit van jouw product. Een kleine koppeling kan al draaien op een standaard hostingpakket voor €30 per maand, maar de prijzen kunnen oplopen tot wel €1000 per maand. De reden voor deze prijsverschillen zit hem in de intensiteit van jouw applicatie en de mate van zekerheid die hierbij vereist is. Want als je een hoog gebruikersaantal hebt, veel processen die draaien en zware berekeningen die gedaan moeten worden, dan kunnen de serverkosten oplopen.

Ook de service en garanties van de provider zijn van invloed op de prijs, want je moet wel op ze kunnen rekenen mocht er een calamiteit ontstaan. Om zeker te zijn van de juiste service kan je een Service Level Agreement met je providers afsluiten. In een contract als deze neem je op wat je van elkaar verwacht zoals nachtdiensttijden, responsetijd, contacturen en meer. 

Support
Als je een vraag hebt of probleem met een applicatie dan wil je graag bij iemand terecht kunnen die jou kan helpen. Dit zal ook het geval zijn bij het gebruik van een eigen applicatie en daarom kan het raadzaam zijn om over de inrichting van de support na te denken. 

Afhankelijk van het doel en jouw behoefte kan je vaak sturing geven aan jouw supportafspraken. 

Enkele belangrijke vragen om samen te bespreken:

  • Kan je nog bij je ontwikkelaars terecht over twee jaar met een vraag of willen ze überhaupt door ontwikkelen?
  • Stel je lanceert een eigen SaaS-oplossing op de markt, kunnen de gebruikers hiervan voor de support terecht bij jou of bij de oorspronkelijke ontwikkelaars?
  • Zullen zij een ondersteunende rol innemen of ligt die bij jou?
  • Wat zijn de reactietijden? 
  • Misschien wordt de applicatie enkel intern gebruikt, heb je dan nagedacht over trainingen voor je eigen werknemers? 

Kortom een hele hoop vragen om over na te denken. Uiteindelijk gaat de inrichting van jouw support hand in hand met het doel, complexiteit en aantal gebruikers van jouw product.

Externe tools
Ook bij een eigen applicatie ben je herhaaldelijk afhankelijk van de software van derden. Je wilt je bijvoorbeeld richten op de e-mail marketing rondom je product. Hiervoor gebruik je meestal niet je gangbare Google e-mail, maar een mailservice waarmee je nieuwsbrieven opmaakt en verstuurt. Andere services waar je aan kan denken zijn branche specifieke pakketten, ERP-systemen, boekhoudprogramma’s etc.

Al deze webservices of externe tools regelen de extra zaken rondom je applicatie. Het afnemen van deze webservices gebeurt vaak in licentievorm en zorgen daarom voor extra periodieke kosten. 

Nieuwe versies van externe tools
Door het gebruik van externe tools en webservices praat je applicatie met een hele hoop koppelingen die geregeld nieuwe versies uitbrengen. Dit betekent dat ook jouw applicatie ingespeeld moet zijn op deze vernieuwingen. De kosten voor het opnieuw koppelen met bijvoorbeeld een vernieuwde API zijn op voorhand vaak moeilijk(er) te voorspellen omdat deze situaties zich slechts sporadisch voordoen.

Over het algemeen adviseren we om circa 15-30% van het initiële ontwikkelbudget te reserveren voor het updaten en onderhouden van jouw webapplicatie. De doorontwikkelingskosten zijn daarnaast volledig afhankelijk van de ambities die je als organisatie nastreeft. 

Prijsindicatie voor jouw webapplicatie?

Vertel ons meer over jouw project

Ik help je graag een stap verder in jouw project!

Hoe de prijsindicatie bij ons verloopt

Tot nu toe hebben we inzicht getoond in de kosten die zoal komen kijken bij een eigen stukje software en hebben we je voorzien van de juiste handvatten om een eigen prijsinschatting te maken. Helaas zijn deze indicatoren en grove schattingen niet altijd leidend en begint een gerichte prijsindicatie bij een goed gesprek. Daarom vertellen we je graag meer over hoe we binnen Web Whales met onze potentiële partners tot een gerichte offerte komen. 

1. Kennismaking

Een goed gesprek begint met een introductie. We leren elkaar kennen, elkaars ambities, doelen en ideeën. Daarna gaan we verder met het belangrijkste, jouw verhaal. We zijn van nature nieuwsgierig en gaan op zoek naar antwoorden. Je krijgt een hoop vragen voorgeschoteld want we willen zoveel mogelijk over jouw project leren. Een goede samenwerking begint eenmaal bij goede communicatie. Aan de hand van de basis die we hebben geven we een grove prijsrange waarna jij bepaalt of je de volgende stap wilt nemen.  

2. Verdieping

Als de basis, het concept en de grootte duidelijk zijn gaan we in de volgende stap het project verder specificeren en opdelen zodat we een gerichte offerte kunnen doen. Dit doen we met de techneuten van onze kant en de gebruikers en belanghebbende aan jouw kant. De eerste verdiepingsslag wordt gemaakt. We kijken naar het aantal sprints, de must havesen horen verschillende stakeholders uit. Het is een soms een dag aan inspanningen maar zo weten we beide wat we kunnen verwachten. 

3. Voorstel en afstemmen

Nadat de details rondom het project meer verdieping hebben gekregen gaat Web Whales voor je aan de slag met de offerte. Afhankelijk van de omvang van het project zoeken we meer of minder de diepte op. Kleine projecten bakenen we zoveel mogelijk af en voorzien we van een vaste prijs. Bij grote projecten passen we een agile methodiek toe zoals de scrum ontwikkelmethode om per sprint aan de slag te gaan. Ook voor en na het opstellen van de offerte kan je tussentijds contact verwachten. Zo nemen we geregeld contact op met de klant indien we aanvullende vragen hebben of om te overleggen over zaken zoals intellectueel eigendom, betalingscondities en de inrichting van het agile werkproces.

4. Van start gaan

De offerte is goedgekeurd, beide kanten zijn gelijk gestemd en dat betekent dat we de motor eindelijk kunnen starten om mooie dingen te realiseren! Bij kleine projecten wordt er gestart volgens de planning. Bij de grotere projecten stappen we eerst in de voorbereidende fase. We bespreken de rolverdelingen zoals wie binnen de organisatie het productownership vervuld. Vervolgens gaan we informatie verzamelen en bespreken we alle details die nodig zijn voor de eerste sprint. Daarna wordt het tijd om aan de slag te gaan!

Jouw voorbereiding op de kennismaking

Hoe meer vragen jij kan beantwoorden hoe sneller het hele plaatje duidelijker wordt. Zo’n vragenuur kan behoorlijk intensief zijn en soms weet je niet een antwoord op alles. Om toch goed beslagen ten ijs te komen sommen we een reeks vragen voor je op die je van tevoren kan voorbereiden. 

  1. Wat is de aanleiding en wat zijn de doelen?
  2. Uit welke onderdelen bestaat de applicatie?
  3. Welke van deze onderdelen zijn gekoppeld met externe diensten?
  4. Binnen welk termijn moet dit gerealiseerd worden?
  5. Is iemand intern beschikbaar als productowner of tester en off-tester?
  6. Welke onderdelen moeten we prioriteren? Denk aan het toepassen van de MoSCoW-methode. 
  7. Moeten we samenwerken met externe partijen?
  8. Moeten wij het design verzorgen?

Hoe je zelf kan besparen op maatwerk

Soms biedt maatwerk eerder de oplossing dan een standaard applicatie, maar is in de meeste gevallen de duurdere optie. Daarom heeft Web Whales een aantal tips voor jou om te besparen op maatwerkkosten:

Interne ontwikkelteams
Ontwikkelwerk is duur en dat mag best gezegd worden. Vooral als een extern ontwikkelteam voor jou aan de slag gaat en dat vergt veel begeleiding van jouw kant. Als je een interne developer op het project zet die samenwerkt met de externe developers bespaar je kosten. Het werk wordt verdeeld en de begeleiding verloopt soepeler. Als voorbeeld: voor een recente klant van ons hebben wij twee developers voor een project ingezet terwijl vanuit de klant ook twee developers meewerken. Dit is uiteindelijk goedkoper voor de klant. Deze samenwerkingsvorm leent zich vooral voor de ontwikkeling van SaaS-oplossingen waar jaar in jaar uit aan doorontwikkeld wordt.

Productownership
Goed productownership is ontzettend belangrijk. Deze man of vrouw is verantwoordelijk voor de implementatie, doorontwikkeling en ziet toe dat het juiste wordt ontwikkeld. Je kan dus zeggen dat het eindresultaat valt of staat met goed productownership. Vaak stellen we daarom een productowner cursus verplicht. Een interne productowner is goedkoper en gunstiger voor het resultaat. Eigen werknemers staan nou eenmaal dichter tot de ambities van hun eigen bedrijf en kunnen daarom beter vanuit deze belangen communiceren. 

Lange termijncommitment
Middels een lange termijncommitment kan je besparen op de kosten omdat je langer in zee gaat met je ontwikkelbedrijf. 

User-centered design
Om geld te besparen en succesvol te worden met je product dien je de gebruiker centraal te stellen in het gehele ontwikkelproces. Door goed te luisteren naar je doelgroep wordt het duidelijk wat hun behoeften en problemen zijn, zodat je ze tegemoet kan komen met de juiste oplossingen. Je laat hierdoor enkel de belangrijkste functionaliteiten ontwikkelen. Dit betekent dat er geen zinloze functionaliteiten worden ontwikkeld op basis van aannames. Het product wordt versimpeld en bruikbaar voor jouw doelgroep. Daarmee is user centered design een belangrijke factor in het besparen van kosten. 

Wat wij voor je kunnen betekenen

We hopen dat je na dit artikel een beter beeld hebt bij de kosten die komen kijken bij je eigen software. Desondanks blijft het maken van een gerichte offerte lastig en is iedere prijs uniek. Een realistische offerte verkrijg je door persoonlijk het gesprek met ons aan te gaan. Wil jij de boel binnen jouw organisatie automatiseren of ben je benieuwd naar de mogelijkheden? Binnen Web Whales denken wij kritisch mee met de groei van jouw bedrijf. Neem contact op en we voorzien je geheel vrijblijvend van advies waarna jij bepaalt hoe je verder wilt.

Geschreven door

Stel je vraag

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site wordt beschermd door reCAPTCHA en het Google Privacybeleid en Servicevoorwaarden zijn van toepassing.