Van proof of concept naar stilstand, en weer terug: een online boekhouddienst

Een bedrijf maakte van een snelle proof of concept een online boekhouddienst, en vond al snel klanten. Toen kwamen de klachten over de performance, wist niemand waarom, en kwam de ontwikkeling stil te liggen. Door een architectuur neer te zetten en stap voor stap weer grip te krijgen, waren de performanceproblemen binnen korte tijd opgelost en kwam de ontwikkeling weer op gang.

In het kort

Organisatie	Softwarebedrijf met een online boekhouddienst voor andere bedrijven. Een mkb-bedrijf met een klein ontwikkelteam (2–3 developers).
Situatie	Vastgelopen met een snel gegroeide applicatie, gebouwd op een no-codeplatform
Mijn rol	Adviseur: het probleem begrijpen en met een oplossing komen
Duur	1–2 dagen om het probleem te begrijpen; de oplossing kostte een paar weken
Resultaat	Performanceproblemen opgelost door een stevige architectuur neer te zetten; ontwikkeling weer volledig onder controle

De situatie

Het bedrijf bouwde een systeem om hun eigen boekhouding te ondersteunen, vanaf het begin zo opgezet dat het ook als online dienst aan andere bedrijven verkocht kon worden. Het begon als een kleine proof of concept. Die proof of concept werd de echte applicatie, allemaal gebouwd in redelijk korte tijd op een no-codeplatform.

En het werkte: de applicatie deed wat ze moest doen, en ze kregen klanten. Iedereen blij, toch?

Het probleem

Nou ja, tot de eerste klachten over de performance binnenkwamen. Het systeem werd te traag om mee te werken, maar niemand wist echt waarom. En niemand durfde er nog aan te komen, bang dat het alleen maar erger zou worden.

Het gevolg: de ontwikkeling kwam zo goed als stil te liggen. Geen nieuwe features, en steeds ontevredener klanten.

Zoals later bleek, had het bedrijf een paar klassieke fouten gemaakt bij het bouwen van een applicatie op een no-codeplatform. De eerste, en meest cruciale: ze begonnen met een proof of concept (POC) en gebruikten die als basis voor hun verdere ontwikkeling. De POC was heel snel in elkaar gezet, door iemand die nog nooit software had ontwikkeld. Onder de indruk van de snelheid en het resultaat besloten ze de POC te houden, twee andere citizen developers erbij te halen (ook zonder achtergrond in software engineering), en er gewoon steeds meer features aan toe te voegen.

Op een gegeven moment kregen ze klanten, werd het systeem steeds intensiever gebruikt, kwam er steeds meer data binnen die verwerkt moest worden, en werd het systeem steeds trager. Tot het moment dat hun klanten er niet meer mee konden werken.

Omdat het bedrijf de kennis niet had om uit te zoeken wat er mis was, durfden ze de software niet meer aan te raken. Daarmee lag de ontwikkeling feitelijk stil, en konden ze de problemen van hun klanten niet oplossen.

De aanpak

Eerst namen we een stap terug, in plaats van meteen de software in te duiken:

1. Inventarisatie. Wat was belangrijk, en wie was waarvan eigenaar. Welke features waren cruciaal, en welke waren nog nodig.
2. Specificaties. We legden vast wat het systeem moest doen, en vergeleken die specs met wat er al gebouwd was, zodat we wisten waar we aan moesten werken. Toen ik aan dit project begon, waren er geen specs.
3. Architectuur. Het cruciale inzicht: er was geen architectuur. De applicatie was gegroeid uit een proof of concept door er steeds functionaliteit bovenop te bouwen. Het ontbreken van een architectuur had ernstige problemen blootgelegd in hoe data en security werden afgehandeld (en nog een aantal minder kritische problemen). Dus zetten we een architectuur neer, met de regels die daarbij moesten gelden.
4. Stap voor stap. We vergeleken de specs met de bestaande applicatie, en pasten bestaande features aan of voegden nieuwe toe, volledig gecontroleerd en op basis van de nieuwe architectuur. Eigenlijk hebben we grote delen van de software opnieuw gebouwd, en hergebruikt wat we konden.
5. Governance. Er kwamen regels en controles om het team te begeleiden, zodat dezelfde situatie niet opnieuw zou ontstaan.

Het resultaat

De performanceproblemen waren binnen een maand opgelost, en de ontwikkeling kwam weer op gang, dit keer volledig onder controle, met de architectuur en governanceregels die we hadden ingericht als leidraad.
Vanaf dat moment konden ze nieuwe klanten aannemen en hun bedrijf laten groeien.

Wat ik anders zou doen

Het probleem was tweeledig: geen architectuur, en geen kennis van software engineering. Ze vertrouwden op hun kennis van het product dat ze wilden, en op het no-codeplatform om het op te bouwen.
Wat ze hadden moeten doen:

• Specs schrijven van alles wat ze in de software nodig hadden.
• Hun klanten in beeld brengen, en hoe die klanten de software zouden gebruiken.
• Uitzoeken aan welke securityrichtlijnen ze moesten voldoen.
• Een architectuur opzetten op basis van de specs, de klanten, security, datavolume, enzovoort.
• En pas daarna beginnen met het bouwen van de oplossing.

En ja: zorg voor basisgovernance, zodat het hele team de regels en verantwoordelijkheden kent.

Herken je jouw situatie hierin?

Groeit je applicatie sneller dan haar structuur? De health check voor low-code en AI-assisted development laat zien waar je nu staat, en wat de volgende stap is. Of lees “Je met AI gebouwde app loopt uit de hand. En nu?” voor het bredere verhaal.