Maatwerk, standaardpakket of low-code: een beslishulp in vijf vragen

Je planning draait op Excel, je offertes op e-mail en je klantgegevens staan op drie plekken. Het is duidelijk dat er iets moet komen. Dan begint het gesprek: koop je een standaardpakket, laat je iets op maat bouwen, of kies je low-code? Elke leverancier heeft een eigen antwoord, en meestal is dat toevallig wat hij zelf verkoopt.

Wij bouwen zelf met OutSystems, dus wij zijn niet neutraal. Daarom hieronder geen verkooppraatje maar vijf vragen die je zelf kunt beantwoorden, ook als je nooit met ons werkt. Het antwoord is vaker "standaardpakket" dan je van een softwarebouwer verwacht.

Vraag 1: Doet een bestaand pakket het grootste deel van wat je nodig hebt?

Begin hier, want dit is de snelste vraag om te beantwoorden. Schrijf op wat je proces moet kunnen, en loop dat langs bij twee of drie standaardpakketten in jouw branche. Kijk niet naar de demo, maar naar jouw eigen lastigste geval: de uitzondering die elke maand terugkomt.

Past een pakket zonder grote ombouw? Neem het pakket. Je krijgt onderhoud, updates en andere bedrijven die dezelfde problemen tegenkomen. Een boekhouding, een HR-systeem of een standaard CRM bouw je niet zelf, ook niet met low-code.

Past het pakket voor het grootste deel maar niet helemaal? Dan is de vraag of je de rest kunt aanpassen met instellingen, of dat je jouw proces moet verbouwen om in het pakket te passen. Dat laatste is een keuze die je bewust moet maken, geen bijzaak.

Vraag 2: Is dit proces iets wat jou onderscheidt, of iets wat iedereen doet?

Facturen boeken doet iedereen. Hoe jij dealers certificeert, klanten inplant of aanvragen beoordeelt, is misschien precies wat jouw bedrijf anders maakt. Voor gewone processen wil je zo standaard mogelijk zijn. Voor het proces waarmee je geld verdient of klanten wint, wil je zelf de regie.

Een praktijkvoorbeeld staat op onze projectenpagina. MEA Beveiliging verwerkte alle installatiemeldingen van dealers handmatig via e-mail, en dat gaf chaos en vertraging. Het proces van dat bedrijf en zijn dealers was zo eigen dat een eigen platform de logische route was: een volledig geautomatiseerd dealer- en certificeringsplatform, gebouwd op OutSystems, waarin dealers hun eigen installaties beheren en certificaten direct worden gegenereerd. Meer over dat patroon lees je in Van Excel en e-mail naar een applicatie.

Is jouw proces gewoon "zoals iedereen het doet"? Dan is maatwerk zelden de moeite waard.

Vraag 3: Hoe vaak verandert het proces, en wie past het aan?

Een proces dat vijf jaar stil ligt, kun je rustig in een pakket zetten. Een proces dat elk kwartaal verandert, omdat je markt beweegt of je groeit, vraagt om iets wat je snel kunt bijsturen.

Hier scoort low-code goed. OutSystems noemt op de eigen platformpagina visuele, modelgedreven ontwikkeling met behoud van controle over de architectuur. Het idee is dat je een wijziging in het model doorvoert en minder code hoeft te herschrijven. Maar het blijft werk voor een developer. Wil je dat een medewerker zelf schermen en regels aanpast zonder iemand erbij? Dan zoek je eerder een no-code tool, of een pakket met goede instellingen. Die keuze legden we uit in Wat is low-code, en wanneer past OutSystems bij jouw MKB-bedrijf.

Vraag 4: Hoe ver zit dit in de rest van je systemen?

Bijna elke applicatie moet praten met iets anders: je boekhouding, je ERP, een betaaldienst, een klantportaal. Hoe meer koppelingen, hoe belangrijker het is dat je bouwmethode dat goed ondersteunt.

De documentatie van OutSystems zegt hierover: wanneer je gegevens wilt ophalen of bewerken in een ander systeem dat REST-API's biedt, kun je die API's in je app gebruiken. Voor de authenticatie is er ingebouwde ondersteuning voor basisauthenticatie en de OAuth 2.0 client credentials flow. Voor andere vormen van beveiliging is er aanpassing mogelijk.

Er is ook een uitweg voor wat het platform niet standaard kan. In de ODC-documentatie staat dat je eigen logica in C# kunt bouwen als de standaardfuncties niet alles afdekken, en die daarna in je apps kunt gebruiken. Wel staat er een beperking: de acties en structuren uit zo'n externe bibliotheek zijn alleen-lezen en niet aan te passen in de visuele omgeving. Wie iets speciaals nodig heeft, kan dus verder dan het visuele model, maar betaalt daarvoor in beheerbaarheid.

Praktisch: schrijf op met welke systemen je moet koppelen en of die een API hebben. Heeft een systeem geen API, dan is dat vaak het echte risico in het project, ongeacht welke route je kiest. Bewijs zo'n koppeling als eerste, niet in de laatste week voor livegang.

Vraag 5: Wie beheert het over drie jaar, en hoe kom je er weer vanaf?

Dit is de vraag die bijna niemand vooraf stelt. Elke route heeft een prijs die pas na de livegang zichtbaar wordt.

Een standaardpakket hangt aan de leverancier: die bepaalt updates en de richting van het product. Volledig maatwerk hangt aan de bouwer of aan een eigen team, want iemand moet de code begrijpen. Low-code hangt aan het platform, en aan iemand die het platform kent.

Stel daarom vooraf drie vragen, ongeacht de route:

• Wie past dit aan als de bouwer weg is?
• Kunnen wij onze gegevens en onze regels er in een bruikbare vorm uit krijgen?
• Wat gebeurt er als de leverancier van koers verandert?

Krijg je op die vragen geen concreet antwoord, dan heb je een risico, ook al zegt de folder anders. Wij zeggen eerlijk: bij low-code is het platform een afhankelijkheid die je bewust moet aangaan. Bij kleine, eenmalige problemen is dat de moeite niet waard.

Zo kies je

Loop de vijf vragen langs en kijk waar je uitkomt:

• Pakket past, proces is standaard: koop het pakket.
• Proces is uniek, verandert regelmatig, veel koppelingen: low-code is meestal een goede kandidaat.
• Proces is uniek en de software is zelf je product, of je hebt een eigen ontwikkelteam: volledig maatwerk kan zinvol zijn.
• Klein en eenmalig probleem: een slim gebruik van wat je al hebt is vaak genoeg.

Is de uitkomst onduidelijk? Dan is dat het antwoord: je weet nog niet genoeg. Maak eerst een klikbare mockup met realistische gegevens. Dat laat snel zien of de richting klopt, en het is minder duur dan een verkeerde keuze. Waarom dat met AI belangrijker wordt, lees je in Eerst een mockup, dan pas bouwen.

Wat betekent dit voor jouw bedrijf?

1. Schrijf het proces op dat je wilt vervangen, inclusief de vijf uitzonderingen die je elke maand tegenkomt.
2. Leg dat naast twee of drie standaardpakketten en toets jouw lastigste geval, niet hun demo.
3. Maak een lijst van systemen waarmee gekoppeld moet worden en controleer of ze een API hebben.
4. Beantwoord de beheervraag schriftelijk voordat je een route kiest: wie past dit over drie jaar aan?

Kom je er niet uit, of wil je een tweede mening over een voorstel of pakketkeuze die al ligt? Dan denken we graag mee, ook als het antwoord "koop dat pakket" is. Neem gerust contact met ons op.