Custom software development

Custom software is not a goal in itself. If an off-the-shelf package covers most of your process and you can adapt the rest to your way of working, that is often cheaper to buy and to maintain. Custom software becomes interesting when the process itself is what sets you apart, when you must combine data from several sources that no package knows, or when licence terms bind you too tightly.

If you are unsure, an independent review beforehand helps. We offer that as technology and software consultancy, separate from the question of who builds it later.

A project does not start with a list of a hundred requirements, but with the process and the data that already exist. That keeps the first result small and verifiable.

1. Exploration. Together we describe the current process, the users, the sources and the boundaries of the assignment. The result is a short note on what is and is not in scope.
2. Prototype on real data. A working first version, filled with an anonymised or public copy of your data. Users then react to something they can click.
3. Iterations with a demo. Each iteration ends with a demo and a prioritised list. You decide what the next step is.
4. Acceptance. Testing against the agreed criteria, including security and, where it applies to your users, accessibility.
5. Handover and maintenance. Source code, documentation, installation instructions and a maintenance agreement, or a handover to your own developers.

How long each step takes depends on the size of the work and on the availability of your people and data. That is why we give a schedule only after the exploration, never before.

Commissioning software also asks something of the client. Most delays arise not in the code but in decisions and access.

• One subject-matter owner who may decide on priorities and has time for the demos.
• Access to the data and systems that are needed, with a contact person at the administrator of each source system.
• A few end users who are willing to test, preferably including someone who looks at the process critically.
• Agreements on hosting and security: does it run at your site, with a hosting provider or in the cloud?
• A data processing agreement if the software processes personal data.

The last point is not a formality. If a supplier processes personal data on your behalf, Article 28(3) of the GDPR (AVG in Dutch) requires a written agreement:

Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.

Source: Regulation (EU) 2016/679 (GDPR), Article 28(3), EUR-Lex. The Dutch central government publishes the Model Verwerkersovereenkomst ARIV-2018 (model data processing agreement) with explanatory notes, which is a usable starting point outside central government too. If the application is hosted with a cloud provider, also look at the agreements on location and administration; the page on cloud and data infrastructure covers that.

With custom software you agree up front who owns the source code and under which licence it is held. Our starting point is that the code lives in a repository you can access, and that you can have another party continue building without TechinFlow's permission.

For government bodies and organisations that want to encourage reuse, an open source licence is an option. According to the European Commission, the European Union Public Licence (EUPL) is the first open source licence with a working value in all official EU languages. If you do not want to publish the code, you arrange ownership or a broad right of use in the contract.

An exit is more than code. Make sure you also receive:

• an export of all data in an open format, such as CSV, GeoPackage or a database dump;
• a description of the infrastructure, so that someone else can rebuild the environment;
• the list of libraries used, with their licences.

If the software runs as a cloud service, the European Data Act rules on switching between providers of data processing services have also applied since 12 September 2025. For exit requirements in a tender, see the guide on vendor lock-in and exit strategy (in Dutch).

Custom software carries well-known risks. You can limit them by naming them at the start.

• Scope grows unnoticed. Work with a prioritised list and a demo per iteration, so you can see what is added and what drops out.
• Dependence on one developer. Require documentation, automated tests and code in a shared repository. Have a third party read the code halfway through.
• Security comes too late. Use a fixed checklist. The OWASP Application Security Verification Standard (ASVS), of which 5.0.0 is the latest stable version, gives verifiable requirements per component.
• Poor source data. Run the first iteration on real data, so data quality becomes visible early rather than at go-live.
• Unclear acceptance. Define per component when it is done, preferably as a test anyone can repeat.
• Outdated components. Agree how often dependencies are updated and who follows security notices.

None of these measures guarantees success, but they make problems visible early and therefore cheaper to solve.

Software that works does not keep working by itself. Operating systems, databases and libraries receive updates and sometimes an end-of-life date. A maintenance agreement describes who tracks that, how quickly security updates are applied and how you request new features.

We propose numbering versions according to Semantic Versioning: a change in the first number means something is no longer backward compatible, so connected systems know when to watch out. Each version then comes with a changelog in plain language. If you want to take over maintenance later or give it to another party, the handover is part of the agreement and not a separate project.

Also plan a yearly moment to see which components are losing support. A database or framework without security updates is a risk that will surface in an audit, even if the application itself has not changed.

For a web application with many users, accessibility and browser support also matter. Those subjects are covered on the page about web and app development.

In small and medium-sized organisations, custom software often starts with a spreadsheet or Access database that has grown too big. Several people work in the same file, copies exist with different figures and nobody dares to change the macros.

A completely new system is then not always needed. Often it is enough to move the data to a real database, put a simple web interface on it and automate the reports. The logic from the spreadsheet is then recorded and tested instead of hidden in cells.

A practical order is to clean up the data first and make one source of truth, then build the input screens people use daily, and only after that reports and integrations. The old file can then remain next to the new system until everyone has moved over, and you quickly see whether the figures match. If the main need is reporting on data from several sources, also look at data platforms.

TechinFlow B.V. was founded by Tekin Uslu. By his own account, Tekin has worked on geo-information, data engineering and IT architecture since 2006. He has published code on GitHub since 2014; it includes the map viewers Atlas-Basic and Atlas-Starter. Projects of the founder from before TechinFlow are not references of TechinFlow B.V. More about the background is on the about page.

Because TechinFlow is a young company, the best way to assess experience is to test it yourself. Look at the public repositories, ask in the exploration for a technical explanation of the proposed architecture and have your own IT department review the prototype. Our starting point is that every quotation names who carries out the work. If subcontractors take part, they should be named too, so you know who gets access to your code and data. That way you can judge the commitment on what is in front of you, not on promises.