Maatwerk software laten maken

Maatwerk software laten maken loont als uw werkproces niet in een standaardpakket past, of als u zelf eigenaar wilt blijven van code en data. TechinFlow ontwikkelt maatwerk in kleine, toetsbare stappen op open standaarden. Uitgangspunt is dat u de broncode, documentatie en een exitplan krijgt, zodat u niet vastzit aan één leverancier.

Laatst bijgewerkt: 11 oktober 2026

Wanneer is maatwerk software de juiste keuze?

Maatwerk is geen doel op zich. Bestaat er een standaardpakket dat het grootste deel van uw proces dekt en waarvan u de rest kunt aanpassen in uw werkwijze, dan is dat vaak goedkoper in aanschaf en beheer. Maatwerk wordt interessant als het proces zelf uw onderscheid is, als u gegevens uit meerdere bronnen moet combineren die geen pakket kent, of als licentievoorwaarden u te veel binden.

Make-or-buy: standaardpakket of maatwerk
Situatie	Meestal beter	Waarom
Generiek proces (boekhouding, HR, e-mail)	Standaardpakket	Wetgeving en updates worden door de leverancier bijgehouden
Proces verschilt sterk per organisatie	Maatwerk	Aanpassen van een pakket kost dan vaak meer dan bouwen
Koppelen van eigen registraties en open data	Maatwerk of een dunne laag op een pakket	Koppelingen zijn zelden standaard aanwezig
Kleine groep gebruikers, eenvoudige invoer	Standaardtool met formulieren	Bouwen weegt dan niet op tegen beheer
Eigendom van data en logica is een eis	Maatwerk onder open licentie	U bepaalt zelf wie verder ontwikkelt

Een uitgebreide afweging met beslistabel staat in de gids maatwerk of standaard software. Twijfelt u, dan helpt een onafhankelijke toets vooraf. Dat doen we als technologie- en softwareadvies, los van de vraag wie het later bouwt.

Hoe verloopt een maatwerktraject?

Een traject begint niet met een lijst van honderd eisen, maar met het proces en de gegevens die er nu al zijn. Zo blijft het eerste resultaat klein en controleerbaar.

Verkenning. We beschrijven samen het huidige proces, de gebruikers, de bronnen en de grenzen van de opdracht. Het resultaat is een korte notitie met wat wel en niet in scope zit.
Prototype op echte data. Een werkende eerste versie, gevuld met een geanonimiseerde of openbare kopie van uw gegevens. Gebruikers reageren dan op iets dat ze kunnen aanklikken.
Iteraties met demo. Elke iteratie eindigt met een demo en een geprioriteerde lijst. U beslist wat de volgende stap wordt.
Acceptatie. Testen tegen de afgesproken criteria, inclusief beveiliging en toegankelijkheid waar dat voor uw gebruikers geldt.
Overdracht en beheer. Broncode, documentatie, installatie-instructies en een beheerafspraak, of een overdracht aan uw eigen ontwikkelaars.

Hoe lang elke stap duurt, hangt af van de omvang en van de beschikbaarheid van uw mensen en data. Daarom noemen we pas een planning na de verkenning, nooit vooraf.

Wat regelt u als opdrachtgever?

Software laten maken vraagt ook iets van de opdrachtgever. De meeste vertraging ontstaat niet in de code, maar bij beslissingen en toegang.

Eén inhoudelijk eigenaar die mag beslissen over prioriteiten en die tijd heeft voor de demo's.
Toegang tot de gegevens en systemen die nodig zijn, met een contactpersoon bij de beheerder van elk bronsysteem.
Een paar eindgebruikers die willen testen, liefst ook iemand die het proces kritisch bekijkt.
Afspraken over hosting en beveiliging: draait het bij u, bij een hostingpartij of in de cloud?
Een verwerkersovereenkomst als de software persoonsgegevens verwerkt.

Dat laatste is geen formaliteit. Verwerkt een leverancier persoonsgegevens namens u, dan moeten beide partijen een verwerkersovereenkomst sluiten op grond van artikel 28, derde lid, van de AVG. De Rijksoverheid publiceert daarvoor het Model Verwerkersovereenkomst ARIV-2018 met een toelichting, die ook buiten het Rijk een bruikbaar startpunt is. Wordt de applicatie bij een cloudleverancier gehost, kijk dan ook naar de afspraken over locatie en beheer; daarover gaat de pagina over cloud- en data-infrastructuur.

Wie wordt eigenaar van de code en hoe regelt u een exit?

Bij maatwerk spreekt u vooraf af wie de broncode bezit en onder welke licentie die staat. Ons uitgangspunt is dat de code in een repository staat waar u toegang toe hebt, en dat u zonder toestemming van TechinFlow een andere partij kunt laten verder bouwen.

Voor overheden en organisaties die hergebruik willen stimuleren is een open source licentie een optie. De Europese Commissie beschrijft de EUPL zo:

The European Union Public Licence (EUPL) is the first open-source licence with a working value in all EU official languages.

Bron: Interoperable Europe (Europese Commissie), gelezen op 11 oktober 2026. Wilt u de code niet openbaar maken, dan regelt u eigendom of een ruim gebruiksrecht in het contract.

Een exit is meer dan code. Leg vast dat u ook krijgt:

een export van alle gegevens in een open formaat, zoals CSV, GeoPackage of een database-dump;
de infrastructuurbeschrijving, zodat een ander de omgeving kan herbouwen;
de lijst van gebruikte bibliotheken met hun licenties.

Draait de software als dienst in de cloud, dan gelden sinds 12 september 2025 ook de regels van de Europese Data Act over overstappen tussen aanbieders van dataverwerkingsdiensten. Welke exit-eisen in een contract horen, staat in de gids over vendor lock-in en exitstrategie.

Welke risico's heeft maatwerk en hoe dekt u die af?

Maatwerk heeft bekende risico's. Ze zijn te beperken als u ze aan het begin benoemt.

De scope groeit ongemerkt. Werk met een geprioriteerde lijst en een demo per iteratie, zodat u ziet wat er bijkomt en wat er wegvalt.
Afhankelijkheid van één ontwikkelaar. Eis documentatie, geautomatiseerde tests en code in een gedeelde repository. Laat halverwege een derde de code lezen.
Beveiliging komt te laat. Gebruik een vaste toetslijst. De OWASP Application Security Verification Standard (ASVS), waarvan 5.0.0 de laatste stabiele versie is, geeft controleerbare eisen per onderdeel.
Slechte brondata. Laat de eerste iteratie op echte data draaien, zodat datakwaliteit vroeg zichtbaar wordt in plaats van bij livegang.
Onduidelijke acceptatie. Leg per onderdeel vast wanneer het af is, bij voorkeur als test die iedereen kan herhalen.
Verouderde onderdelen. Spreek af hoe vaak afhankelijkheden worden bijgewerkt en wie beveiligingsmeldingen volgt.

Geen van deze maatregelen garandeert succes, maar ze maken problemen vroeg zichtbaar en dus goedkoper om op te lossen.

Hoe regelt u onderhoud na de oplevering?

Software die werkt, blijft niet vanzelf werken. Besturingssystemen, databases en bibliotheken krijgen updates en soms een einddatum. Een beheerafspraak beschrijft wie dat bijhoudt, hoe snel beveiligingsupdates worden doorgevoerd en hoe u nieuwe wensen aanvraagt.

Ons voorstel is versies te nummeren volgens Semantic Versioning: een verandering in het eerste cijfer betekent dat iets niet meer achterwaarts compatibel is, zodat koppelende systemen weten wanneer ze moeten opletten. Bij elke versie hoort dan een changelog in gewone taal. Wilt u het beheer later zelf doen of aan een andere partij geven, dan is de overdracht onderdeel van de afspraak en geen apart project.

Plan daarnaast een jaarlijks moment om te kijken welke onderdelen hun ondersteuning verliezen. Een database of framework zonder beveiligingsupdates is een risico dat in een audit terugkomt, ook als de applicatie zelf niet is veranderd.

Gaat het om een webapplicatie met veel gebruikers, dan spelen ook toegankelijkheid en browserondersteuning mee. Die onderwerpen staan op de pagina over web- en app-ontwikkeling.

Hoe begint maatwerk in het mkb?

Bij middelgrote en kleine organisaties begint maatwerk vaak bij een spreadsheet of Access-database die te groot is geworden. Meerdere mensen werken in hetzelfde bestand, er bestaan kopieën met verschillende cijfers en niemand durft de macro's aan te passen.

Dan is een volledig nieuw systeem niet altijd nodig. Vaak volstaat het om de gegevens naar een echte database te verhuizen, er een eenvoudige webinterface op te zetten en de rapportages te automatiseren. De logica uit het spreadsheet wordt dan vastgelegd en getest in plaats van verstopt in cellen. Hoe u zo'n bedrijfskritisch bestand stapsgewijs vervangt, beschrijft de pagina over legacy-modernisering.

Een praktische volgorde is eerst de gegevens opschonen en één bron van waarheid maken, dan de invoerschermen bouwen die mensen dagelijks gebruiken, en pas daarna rapportages en koppelingen. Zo kan het oude bestand naast het nieuwe systeem blijven bestaan tot iedereen over is, en ziet u snel of de cijfers overeenkomen. Gaat het vooral om rapportages over gegevens uit meerdere bronnen, kijk dan ook naar dataplatforms.

Wie voert het werk uit?

TechinFlow B.V. is een nieuw bureau, opgericht door Tekin Uslu. Tekin werkt volgens eigen opgave sinds 2006 aan geo-informatie, data engineering en IT-architectuur. Tekin publiceert sinds 2014 code op GitHub; daar staan onder meer de kaartviewers Atlas-Basic en Atlas-Starter. Eerder werk van de oprichter is geen referentie van TechinFlow B.V. Meer over de achtergrond leest u op over TechinFlow.

Omdat TechinFlow een jong bedrijf is, kunt u ervaring het best zelf toetsen. Bekijk de publieke repositories, vraag in de verkenning om een technische toelichting op de voorgestelde architectuur en laat het prototype door uw eigen IT-afdeling beoordelen. Uitgangspunt is dat in elke offerte bij naam staat wie het werk uitvoert. Werken er onderaannemers mee, dan horen die er ook in te staan, zodat u weet wie toegang krijgt tot uw code en gegevens. Zo kunt u de inzet beoordelen op wat er ligt, niet op beloftes.

Veelgestelde vragen

Wat kost maatwerk software laten maken?

Dat hangt af van het aantal processen, koppelingen en gebruikers, en van de eisen aan beveiliging en beheer. Een vaste prijs vooraf zonder verkenning zou een gok zijn. Na een korte verkenning kunt u een begroting per stap krijgen, zodat u na elke iteratie kunt beslissen of u doorgaat. Welke factoren de prijs bepalen, staat in de gids over kosten van maatwerk software. Neem contact op om de verkenning te bespreken.

Wie wordt eigenaar van de broncode?

Dat legt u in het contract vast. Ons uitgangspunt is dat de code in een repository staat waartoe u toegang hebt en dat u die zonder onze toestemming door een andere partij mag laten aanpassen. U kunt kiezen tussen eigendom van de code of een ruim gebruiksrecht, of de code openbaar maken onder een open source licentie zoals de EUPL.

Kunnen we later overstappen naar een andere ontwikkelaar?

Ja, als dat vooraf goed is geregeld. Daarvoor zijn de broncode, een gegevensexport in een open formaat, een beschrijving van de infrastructuur en documentatie voor installatie en beheer nodig. Laat bij voorkeur halverwege het traject een onafhankelijke ontwikkelaar de code lezen. Dan weet u of een overdracht in de praktijk werkt.

Kunnen we de projecten van de oprichter als referentie gebruiken in een aanbesteding?

Nee. Eerder werk van de oprichter is geen referentie van TechinFlow B.V., en TechinFlow is een nieuw bureau. Wat u wel kunt bekijken, zijn de publieke repositories van Tekin Uslu op GitHub en het werk dat TechinFlow voor u oplevert, zoals een prototype op uw eigen data.

Kan maatwerk samenwerken met de pakketten die we al hebben?

Meestal wel, als die pakketten een gedocumenteerde API of een exportmogelijkheid hebben. Maatwerk is dan vaak een dunne laag die gegevens uit bestaande systemen combineert, in plaats van een vervanging. Of dat kan, blijkt in de verkenning uit de documentatie van de leveranciers en een eerste testkoppeling.