Wanneer is maatwerk gerechtvaardigd?

Als een bestaand systeem het proces niet aankan zonder er omheen te werken, en als dat proces wezenlijk is voor de organisatie. Een verzekeraar met een eigen premieberekening of een groothandel met een afwijkende prijsstructuur heeft maatwerk nodig. Een organisatie die een standaardformulier wil met één extra veld, vrijwel nooit. De vuistregel is dat je maatwerk bouwt voor wat je onderscheidt en standaardoplossingen gebruikt voor alles wat iedereen ook doet.

Van wie is de broncode na oplevering?

Dat moet je vooraf vastleggen, want het is niet vanzelfsprekend. Sommige bureaus dragen de code volledig over, andere leveren een gebruiksrecht terwijl het eigendom bij hen blijft. Zonder eigendom en zonder toegang tot de opslagplaats zit je na oplevering vast aan één partij, ook als de samenwerking stopt. Vraag naast eigendom ook om documentatie en om de mogelijkheid de code op te halen: alle drie zijn nodig om ooit te kunnen overstappen.

Welke programmeertaal moet ik kiezen?

Belangrijker dan de taal zelf is hoe gangbaar die is in de Nederlandse markt, want dat bepaalt of je later developers kunt vinden. PHP met Laravel of Symfony, .NET, Java, Python en Node.js zijn alle ruim vertegenwoordigd. Een zeldzame taal of een intern ontwikkeld framework maakt je afhankelijk van één partij of zelfs van één persoon. Vraag bij een voorstel altijd hoeveel andere bureaus ermee kunnen werken, niet alleen waarom deze partij hem prettig vindt.

Wat kost onderhoud aan een maatwerkoplossing?

Reken op een terugkerende post, niet op een eenmalige investering. Serversoftware, frameworks en bibliotheken krijgen updates die moeten worden doorgevoerd, en beveiligingslekken vragen soms om snelle actie. Als vuistregel houden veel organisaties een jaarlijks bedrag aan in de orde van vijftien tot twintig procent van de bouwkosten, afhankelijk van complexiteit en van hoeveel koppelingen er zijn. Een maatwerkapplicatie die jaren niet wordt bijgewerkt, wordt op enig moment een risico.

Wat is het verschil met een CMS?

Een CMS is een kant en klaar systeem waarin je inhoud beheert; de functionaliteit is er al en je richt hem in. Backend-maatwerk betekent dat er functionaliteit wordt geschreven die er nog niet is. In de praktijk komen combinaties het meest voor: een gangbaar CMS voor de inhoud, met daarnaast maatwerk voor het proces dat de organisatie onderscheidt. Dat is doorgaans goedkoper en beter onderhoudbaar dan alles zelf bouwen.

Hoe weet ik of de code van goede kwaliteit is?

Als opdrachtgever kun je dat niet zelf beoordelen, maar je kunt wel om indicatoren vragen: is er geautomatiseerd getest, wordt er met versiebeheer gewerkt, is er documentatie, en wordt code door een tweede developer nagekeken voordat hij live gaat. Bij grotere investeringen is een onafhankelijke code-audit door een derde partij een reële optie. Die kost een fractie van het bouwbudget en legt structurele problemen bloot voordat je er jaren aan vastzit.

Backend en maatwerk | WebdesignVergelijker.nl

Wat is backend en maatwerk?

Backend-development is het bouwen van alles wat op de server gebeurt en wat de bezoeker nooit rechtstreeks ziet: gegevens opslaan en ophalen, gebruikers herkennen en rechten toekennen, berekeningen uitvoeren, bestellingen verwerken, e-mails versturen en gegevens uitwisselen met andere systemen. Als de frontend de etalage is, is de backend het magazijn, de kassa en de administratie samen.

Maatwerk betekent in deze context dat functionaliteit specifiek wordt geschreven omdat bestaande systemen niet toereikend zijn. Dat is een wezenlijke keuze met blijvende gevolgen. Een standaardoplossing configureren is sneller, goedkoper en wordt door de leverancier onderhouden; maatwerk past precies maar moet door jou worden bekostigd, onderhouden en bij vertrek van een partij worden overgedragen.

De praktijk zit meestal in het midden. Een gangbaar CMS of e-commerceplatform verzorgt het gewone werk, en daarnaast wordt maatwerk gebouwd voor het proces dat de organisatie onderscheidt: een offertecalculator, een koppeling met een voorraadsysteem, een portaal waarin klanten hun eigen gegevens beheren. Die verdeling is doorgaans verstandiger dan een van beide uitersten.

Wat valt er precies onder?

Backend-werk omvat de functionaliteit zelf, maar ook alles wat nodig is om die betrouwbaar en veilig te laten draaien.

Datamodel: bepalen welke gegevens worden vastgelegd en hoe die zich tot elkaar verhouden, wat later moeilijk te wijzigen is.
Bedrijfslogica: de regels waarmee het systeem beslissingen neemt, van kortingsberekening tot goedkeuringsstappen.
Authenticatie en autorisatie: wie mag inloggen en wie mag wat zien of wijzigen.
API’s: de aansluitpunten waarmee de frontend of andere systemen gegevens opvragen en versturen.
Achtergrondtaken: werk dat buiten het verzoek van de bezoeker om draait, zoals nachtelijke synchronisaties en het versturen van e-mail.
Gegevensbeveiliging: versleuteling, invoercontrole en maatregelen tegen misbruik, plus wat de AVG vereist.
Geautomatiseerd testen: tests die controleren of functionaliteit blijft werken na wijzigingen, wat bij maatwerk zwaarder weegt dan bij standaardsoftware.
Logging en monitoring: vastleggen wat er gebeurt, zodat storingen te herleiden en op te lossen zijn.

Hoe verloopt een maatwerktraject?

Maatwerk begint met uitzoeken wat er precies moet gebeuren, en dat uitzoekwerk is bepalend voor de kosten van alles wat erna komt.

Functioneel ontwerp. Er wordt vastgelegd wat het systeem moet doen, inclusief uitzonderingen en foutsituaties. Onduidelijkheid hier is de voornaamste bron van meerwerk.
Technische keuzes. Taal, framework, database en hostingvorm worden gekozen, waarbij beschikbaarheid van developers in de markt zwaar hoort te wegen.
Datamodel opzetten. De structuur van de gegevens wordt bepaald. Dit is de keuze die achteraf het duurst te wijzigen is.
Bouwen in delen. Functionaliteit wordt in afgebakende stukken opgeleverd, zodat er tussentijds getoetst kan worden in plaats van pas aan het eind.
Testen. Naast geautomatiseerde tests wordt er met echte gegevens getest, inclusief de gevallen waarin iets misgaat of ontbreekt.
Livegang en overdracht. Het systeem gaat in gebruik, met documentatie, toegang tot de code en afspraken over wie storingen oppakt.

Wanneer heb je dit nodig?

De heldere aanleiding is een proces dat niet in bestaande software past. Als een organisatie werkt met eigen rekenregels, afwijkende prijsafspraken of een goedkeuringsstroom die nergens standaard in zit, houdt configureren op enig moment op en begint maatwerk.

Een tweede aanleiding is een klantportaal: een omgeving waar klanten inloggen en hun eigen gegevens, bestellingen of dossiers inzien. Dat vraagt vrijwel altijd maatwerk, omdat het aansluit op interne systemen die per organisatie verschillen.

Ook koppelingen met bedrijfssystemen leiden hiertoe, zoals een ERP, een voorraadsysteem of een boekhoudpakket dat gegevens moet uitwisselen met de site. En bij schaal: als het aantal gebruikers of transacties zo groot wordt dat standaardoplossingen tekortschieten, wordt maatwerk aan de serverkant onvermijdelijk.

Wat levert het op?

Maatwerk levert functionaliteit op die precies aansluit op hoe een organisatie werkt, in plaats van een organisatie die haar proces aanpast aan wat de software toevallig kan. Waar dat proces onderscheidend is, kan dat een reëel voordeel zijn: minder handwerk, minder fouten en snellere doorlooptijden. Ook levert het onafhankelijkheid op van de routekaart van een softwareleverancier.

Daar staat een blijvende verplichting tegenover. Maatwerk wordt niet door een leverancier onderhouden; dat doe je zelf of via het bureau dat het bouwde. Frameworks en serversoftware krijgen updates die moeten worden doorgevoerd, en beveiligingslekken vragen soms om snelle actie. Wie de onderhoudspost schrapt, houdt na enkele jaren een systeem over dat een risico vormt en dat lastig is bij te werken. Bureaus die maatwerk aanbieden zonder daarbij een onderhoudsafspraak voor te stellen, laten een wezenlijk deel van de rekening buiten beeld.

Waar let je op als je dit uitbesteedt?

Regel het eigendom van de broncode vooraf en schriftelijk, samen met toegang tot de opslagplaats en documentatie. Dit is bij backend-maatwerk zwaarder van belang dan waar ook: zonder die drie is overstappen naar een andere partij in de praktijk onmogelijk en begin je feitelijk opnieuw. Vraag ook hoe de code wordt overgedragen als de samenwerking eindigt.

Let daarnaast op de technologiekeuze in het licht van de arbeidsmarkt. Een gangbare taal en een gangbaar framework betekenen dat er voldoende developers zijn die er later mee verder kunnen. Vraag hoeveel andere Nederlandse bureaus met de voorgestelde opzet werken. Vraag verder naar geautomatiseerd testen en naar de manier waarop code wordt nagekeken, want dat bepaalt of het systeem over vijf jaar nog aanpasbaar is. Maak ten slotte concrete afspraken over storingen: wie is bereikbaar, binnen welke tijd wordt gereageerd en wat kost dat.

Veelgemaakte fouten

Bij maatwerk zitten de duurste fouten aan het begin en aan het eind, niet in het bouwen zelf.

Maatwerk kiezen waar standaard had volstaan. Zelf bouwen wat een bestaand systeem ook kan, kost een veelvoud en levert een blijvende onderhoudsverplichting op.
Beginnen zonder functioneel ontwerp. Als niet vooraf vastligt wat het systeem precies moet doen, groeit de omvang gaandeweg en loopt de begroting mee.
Eigendom en documentatie niet regelen. Zonder code, toegang en uitleg is een organisatie na oplevering gebonden aan één partij, ongeacht hoe de samenwerking verloopt.
Onderhoud niet begroten. Een maatwerksysteem dat jaren niet wordt bijgewerkt, wordt kwetsbaar en steeds duurder om alsnog te moderniseren.

Wat bepaalt de prijs?

De prijs volgt uit de hoeveelheid functionaliteit die daadwerkelijk geschreven moet worden en uit hoeveel systemen erbij betrokken zijn. Koppelingen zijn de post die het vaakst wordt onderschat, omdat elke koppeling eigen uitzoekwerk vraagt.

Wat de prijs opdrijft	Waarom het meetelt
Mate van maatwerk	Zelf geschreven functionaliteit kost een veelvoud van het configureren van bestaande bouwstenen.
Aantal koppelingen	Elk extern systeem heeft eigen eigenaardigheden, eigen testwerk en eigen onderhoud.
Eisen aan beschikbaarheid	Een systeem dat continu bereikbaar moet blijven, vraagt een zwaardere opzet en meer bewaking.
Omvang van geautomatiseerd testen	Tests kosten bouwtijd vooraf, maar zijn bij maatwerk nodig om latere wijzigingen betaalbaar te houden.

Afgebakend maatwerk wordt vaak op projectbasis aangeboden; werk waarvan de omvang vooraf niet scherp te bepalen is, gaat gebruikelijk op uurbasis of via een maandelijkse capaciteitsafspraak. Reken daarnaast op een terugkerende onderhoudspost. Vraag expliciet of hosting, monitoring en updates in die post zitten, en wat er gebeurt bij een storing buiten kantooruren, want dat is waar afspraken het meest uiteenlopen.

Backend en maatwerk en aanverwante diensten

De backend is de laag waar de meeste andere diensten uiteindelijk op steunen. Frontend-development is de directe afnemer: die toont wat de backend levert, en de afspraken over dat gegevensverkeer bepalen hoe soepel beide kanten samenwerken. Koppelingen en API’s is in de praktijk vrijwel altijd onderdeel van backend-werk, en vaak de grootste post daarbinnen. Webdevelopment is de bredere term waaronder dit valt bij bureaus die geen onderscheid maken tussen front- en backend. Hosting en onderhoud is de noodzakelijke tegenhanger, want maatwerk zonder onderhoud veroudert snel. En beveiliging en updates raakt hier het hardst, omdat serverzijdige code de plek is waar gegevens en toegangsrechten worden afgehandeld. Nederlandse bureaus verschillen sterk in hoeveel maatwerk ze aankunnen; sommige bouwen uitsluitend op bestaande platformen.