Wat goede interne tooling echt kost vergeleken met het probleem dat het oplost

Er is een gesprek dat we regelmatig voeren. Een organisatie heeft een intern proces dat slecht loopt. Mensen werken om het heen, kopiëren data tussen systemen, sturen spreadsheets rond die niemand meer vertrouwt. Dan vraagt iemand: kunnen jullie daar een tool voor bouwen? En het volgende wat volgt is een discussie over budget.

Het probleem met die discussie is dat de kosten van de tool zichtbaar zijn, en de kosten van het probleem dat niet zijn. Niemand heeft ooit uitgerekend wat het kost als vijf mensen elke week vier uur verliezen aan een proces dat eigenlijk niet werkt. Niemand heeft bijgehouden hoe vaak een klant iets te laat krijgt omdat twee systemen niet met elkaar praten. Niemand heeft de beslissingen geteld die op de verkeerde data werden genomen.

Bij Livewall zien we dit patroon keer op keer. En het leidt bijna altijd tot dezelfde fout: organisaties investeren te laat, of te weinig, in custom tooling omdat ze de vergelijking nooit eerlijk maken.

Hoe je de vergelijking eerlijk maakt

De eerste stap is simpel: tel op wat het probleem nu al kost. Niet in vage termen als 'tijdverlies' of 'frustratie', maar in concrete getallen. Hoeveel uur gaat er per week verloren? Wat kost dat in personeelskosten? Hoe vaak leidt het tot fouten met gevolgen naar buiten? Wat is de kans dat een sleutelmedewerker vertrekt omdat het werk onnodig zwaar is?

Dat is de basis van de vergelijking. Aan de andere kant staat een goed gebouwd intern systeem of een webapplicatie op maat. Iets wat het probleem structureel wegneemt, in plaats van er steeds opnieuw omheen te werken.

Wat we bij Livewall ook weten: met AI als co-creator liggen de ontwikkelkosten vandaag de dag significant lager dan drie jaar geleden. Een tool die vroeger zes weken vroeg, kan nu in twee tot drie weken worden neergezet, met een hogere kwaliteit en minder technische schuld. De vergelijking wordt daardoor steeds vaker in het voordeel van bouwen beslecht.

Begin klein, maar begin

De tweede fout die we zien: organisaties wachten op de perfecte oplossing. Ze willen alles in één keer goed hebben, en daardoor wordt het project nooit gestart. Of het wordt zo groot dat niemand meer durft te beginnen.

Onze aanpak is anders. We beginnen met een prototype dat het grootste pijnpunt wegneemt. Iets wat je in een week kunt bouwen en direct in gebruik kunt nemen. Daarna kijk je wat het doet, wat het vraagt, en wat de volgende stap is. Dat is ook hoe we werken bij klanten als Zorg van de Zaak en Lefboom: niet met een 100-pagina specificatie, maar met iets wat werkt en groeit.

De kosten van een goed intern tool zijn reëel. Maar ze zijn ook eindig. De kosten van het probleem dat je niet oplost, lopen gewoon door.