Standaard of maatwerk: hoe je die keuze onderbouwt

Standaardsoftware is gebouwd rond een gemiddelde. Zolang je werkt zoals dat gemiddelde, is er geen betere keuze: je krijgt onderhoud, beveiligingsupdates en een community er zonder extra kosten bij. De vraag is dus niet of het pakket goed is, maar hoeveel van jouw werk erbuiten valt.

Ik vraag daarom altijd naar de uitzonderingen in plaats van naar de wensen. Welke orders gaan anders dan de rest, welke klant heeft eigen prijsafspraken, welke stap doet iemand met de hand omdat het systeem hem niet kent. Dat lijstje is de kern van de beslissing, en het is bijna altijd korter dan mensen verwachten.

Wat je daarna overhoudt, is een concrete vraag: kan het pakket deze vijf dingen, en zo niet, hoeveel kost het om eromheen te werken. Dat is een beslissing die je kunt onderbouwen, in plaats van een gevoel over of iets “past”.

Een pakket dat niet past kost geen licentie extra, maar wel uren. Een medewerker die elke dag een half uur gegevens overtypt, kost per jaar meer dan de koppeling die dat werk overneemt. Die rekensom wordt zelden gemaakt, omdat de kosten verspreid zitten over mensen in plaats van over facturen.

Zet er daarom een bedrag bij. Neem het aantal uren per week, reken door naar een jaar, en tel op wat een fout kost die door dat handwerk ontstaat: een verkeerde levering, een creditfactuur, een klant die afhaakt. Bij de projecten die ik doe blijkt maatwerk op één onderdeel vaak binnen een jaar terugverdiend.

Even belangrijk is de omzet die je nu niet haalt. Als je geen staffelprijzen kunt aanbieden omdat het systeem het niet kent, is dat geen ontbrekende functie maar een gemiste markt.

De keuze is bijna nooit alles of niets. Betalingen, verzendlabels, fraudepreventie en boekhouding zet ik graag op bestaande diensten: dat is opgelost werk waar je niets aan toevoegt en waar de risico's het grootst zijn.

Het maatwerk beperk ik tot het deel dat jouw bedrijf onderscheidt. Een webshop op Shopify met een eigen prijs- en offertemodule is bijna altijd verstandiger dan een shop volledig zelf bouwen. Je houdt het onderhoud klein terwijl het proces past bij hoe je werkt.

Diezelfde verdeling werkt ook binnen een applicatie. Authenticatie, e-mailverzending en bestandsopslag hoef je niet zelf te bedenken; de bedrijfsregels eromheen wel.

Maatwerk heeft één nadeel dat vaak wordt vergeten: iemand moet het over vijf jaar nog kunnen onderhouden. Dat maakt techniekkeuze onderdeel van de beslissing, niet iets dat je achteraf regelt.

Ik kies daarom bewust voor gereedschap met een grote community en een voorspelbare structuur, en lever op met documentatie van de koppelingen en de omgeving. Dat betekent dat je op elk moment naar een andere developer kunt, en dat is precies de bedoeling.

Vraag bij elke aanbieding wat je krijgt bij de oplevering. Als het antwoord alleen “een werkend systeem” is, koop je een afhankelijkheid.

In de praktijk kom ik met vier vragen tot een onderbouwd advies. Ze zijn simpel, maar ze dwingen om cijfers te noemen in plaats van voorkeuren.

Wijkt je proces echt af, of is het gewoonte? Wat kost het handwerk per jaar? Welk deel is standaard op te lossen? En wie onderhoudt het straks? Als die vier antwoorden op papier staan, wijst de uitkomst zich meestal zelf.

Wat je daarmee vooral voorkomt, is het meest voorkomende scenario: een half jaar bouwen aan iets dat een bestaand pakket ook had gekund, of jaren omheen werken in een pakket dat nooit ging passen.