Procuring custom software
A tender or direct invitation for custom software stands or falls on preparation. This guide helps buyers and project leads to tender well, from describing the desired outcome to requirements versus wishes, standards such as ZGW, BIO and WCAG, and clear exit and ownership provisions. We explain where invitations often go wrong and how Appfront bids as a build partner: transparently, realistically and without promises that constrain later. This is general information, not legal advice on public procurement.
What does procuring custom software involve?
Procuring custom software means that, as a public sector organisation, you put a software commission on the market through a formal procedure. Unlike an off-the-shelf package, you are not buying an existing product but commissioning a solution built to fit your process precisely. This calls for an invitation that clearly describes the desired result without prescribing the solution so tightly that good suppliers withdraw.
For many government processes, custom software suits better than a standard package: you are dealing with specific legislation and regulations, integrations with government registers and work processes that do not fit a generic product. Custom software gives you control over functionality, the standards the software meets and ownership of your data, provided you specify these points well in the tender. A standard package may appear cheaper, but it sometimes leads to costly adjustments or vendor lock-in if it does not fit.
The procedures, threshold amounts and rules for public tendering are set out by PIANOo, the Dutch centre of expertise on public procurement. Always check the current amounts and rules there, as they are reviewed periodically. Appfront acts as a build partner and bidder, not as a procurement lawyer: this page provides general information, not legal advice on procurement. For the legal aspects, work with your own procurement and legal departments.
Outcomes rather than rigid specifications
Describe the result the software must achieve and the processes it should support, rather than prescribing every field and button. This keeps you in control of the end result and gives bidders room to use their expertise to find the best solution.
Requirements versus preferences
Distinguish between mandatory requirements, which determine whether a bid qualifies, and preferences, against which you compare and score quality and approach. Too many mandatory requirements unnecessarily exclude the market; well-chosen preferences steer towards the best value for money.
Exit and ownership arranged
Set out in the tender who owns the source code and data, how data is transferred on termination, and which documentation will be delivered. Clear exit provisions prevent lock-in and keep a move to another supplier realistic.
From tender to award: the steps
Careful preparation makes the difference between a tender that attracts comparable, realistic bids and a process that stalls later. Below are the steps you go through when preparing a tender for custom software, from defining the need to award and ongoing management. PIANOo describes the deadlines and rules that apply to each procedure.
Determine which problem the software solves, which processes it supports and what result you want to achieve. Describe the outcome and the hard constraints, not a detailed technical design.
Elaborate requirements and preferences, name the relevant standards (such as ZGW, BIO and WCAG) and set out exit and ownership provisions. Choose the procedure that suits the estimated value; PIANOo publishes the current thresholds.
Publish the tender, answer questions in the clarification memorandum and evaluate bids against the award criteria. A prior market consultation sharpens the tender and tests feasibility.
After award, the build phase begins, with clear agreements on delivery, documentation, maintenance and further development. Make sure the exit arrangements from the tender also make it into the contract.
What a good software tender contains
A tender that attracts comparable, realistic bids always contains the same building blocks. Below are the elements we most often see missing from software tenders, and which make the difference between a smooth process and one that stalls along the way.
Outcome-focused description
Describe the purpose, the processes and the desired result rather than a rigid technical design. This keeps you in control of the outcome and gives bidders room to use their expertise to find the best solution, without inadvertently excluding good suppliers.
Requirements, preferences and award criteria
Separate mandatory requirements (knock-out criteria) from desirable criteria you score on, and link these to transparent award criteria. Keep the number of requirements sharp and realistic, so that you steer towards the best value for money rather than inadvertently choosing on the lowest price alone.
Make standards explicit
Name the standards that apply to your process, such as the ZGW APIs, the Baseline Informatiebeveiliging Overheid (BIO, the Dutch government baseline for information security) and WCAG 2.1 AA for accessibility. Recording standards in advance ensures the software fits the wider government landscape and helps you avoid vendor lock-in.
Integrations and existing systems
Describe which registers and systems the software must integrate with, such as DigiD, eHerkenning or TenderNed. A clear picture of your existing IT landscape prevents surprises during the build and makes bids easier to compare.
Exit and ownership provisions
Specify who owns the source code and data, how data is handed over at termination, and what documentation will be delivered. Good exit arrangements belong in the tender itself, not just in the contract phase, and keep a switch to another supplier realistic.
Maintenance, further development and realism
Ask not only for the build, but also for maintenance, support and further development after handover. Check timelines for realism: a tender that leaves room for honest assumptions produces more reliable bids than one that invites overly optimistic promises.
Who this guide is for
Preparing a software tender is relevant to a wide range of public organisations. The principles, such as describing the outcome, distinguishing requirements from wishes, and setting out standards and exit provisions, are the same everywhere, but the relevant integrations and standards differ by process.
Municipalities
Municipalities commission custom software for case-based working, services and specific implementation processes. Standards such as ZGW and integrations with DigiD often play a role here. Read more about building software for municipalities.
Implementing bodies
Public implementing bodies and service providers that digitally support processes such as grant allocation and schemes. Think of clear integrations and strict requirements around information security. For example, see building subsidy software.
Provinces & water boards
Provinces and water boards that procure custom software for supervision, permits or area-based processes. Here too the BIO applies for information security and WCAG for accessibility, plus integrations with national registers where relevant.
Procurement and tendering via TenderNed
In the Netherlands, tenders are published via TenderNed, the government's public procurement platform. If you want to integrate TenderNed with your own procurement or contract management system, read about building a TenderNed integration.
Standards and frameworks that matter
In a tender for custom software, you name the standards and frameworks that apply to your process, so the software fits the government landscape and you avoid vendor lock-in. Which ones are relevant depends on your organisation and process. You publish tenders via TenderNed; the procedures are described at PIANOo. Below are the frameworks we encounter most often.
How Appfront works as a bidder
Appfront submits transparent and realistic tenders for custom software. We describe what we do and don't know, are open about assumptions and risks, and make no promises that will cause problems during delivery. A tender is best served by honest bids, not the most optimistic ones.
We work outcome-driven and deliver understandable documentation and transferable code. Ownership, exit, standards and maintenance are made explicit, so you are never tied to us. No black box, but agreements that a future supplier can also continue.
If you are preparing a tender or running a market consultation, we are happy to advise, without obligation, on feasibility and on how you formulate outcomes, requirements and wishes. You work with a fixed point of contact who understands both the technology and the process.
See also our pages on building software for municipalities and building subsidy software, or get in touch to discuss your tender.
- Transparent bids, open about assumptions and risks
- Realistic timelines, no promises that cause problems later
- Outcome-driven development based on your actual processes
- Works with government standards such as ZGW, BIO and WCAG
- Clear agreements on ownership and exit, no lock-in
- Understandable, transferable documentation and code
- Experience with integrations to government registers
- A fixed point of contact who understands both technology and process
- Attention to maintenance and further development after handover
- Happy to contribute to market consultations and preparation
Information security and privacy in the tender
Custom government software almost always processes personal data. Therefore, include information security and privacy as mandatory requirements in the tender. The Baseline Information Security for Government (BIO) is the mandatory framework for information security in the public sector; refer to it explicitly, together with data minimisation and appropriate logging and audit trails.
Alongside the BIO, the GDPR applies to the processing of personal data and, for public websites and applications, WCAG 2.1 AA applies to digital accessibility. Ask bidders to demonstrably comply with these frameworks and to document data flows, so that your record of processing activities remains complete. Which requirements apply exactly should be determined with your own security and privacy officers.
Would you like to discuss how to concretely embed BIO, GDPR and WCAG in your tender? Get in touch without obligation. We are happy to help, although this does not replace legal advice on procurement law.
- BIO as the framework for information security
- GDPR-compliant processing and data minimisation
- WCAG 2.1 AA accessibility where publicly accessible
- Encryption in transit (TLS 1.2+) and at rest
- Role-based access and least-privilege principles
- Logging and audit trails with traceable data flows
- Clear agreements on data storage and retention periods
- Documentation for your record of processing activities
See also: market consultation for software (the step before the tender), Appfront as a software supplier for the public sector, and the requirement pages BIO-compliant software and digitally accessible software.
Frequently asked questions about tendering software
Answers to the questions buyers and project managers ask most often. General information, not legal advice on procurement law.
A tender is the procedure through which a government organisation puts an assignment for custom software to the market, so that interested suppliers can submit a suitable offer. Depending on the estimated value of the contract, you choose either a direct invitation to a few parties or a European tender procedure. The Dutch expertise centre for public procurement, PIANOo, describes the applicable procedures and publishes the current threshold amounts. A good tender describes not only what you want technically, but above all what result the software must achieve for your organisation.
That depends on the estimated value of the contract. For contracts above the European thresholds, a mandatory European procedure generally applies; below them, you can often invite tenders from several or a single supplier, within the limits of your own procurement policy. The exact threshold amounts are revised periodically and are published on the PIANOo website, so never rely on a fixed figure from memory; refer to the current source instead. We provide general information on this and not procurement law advice; please consult your procurement or legal department.
Describe the desired result, the outcome, rather than a detailed technical design. Set out which problem you are solving, which processes the software needs to support, which standards apply and which constraints are non-negotiable. If you prescribe every button and field, you rule out better solutions and take on the risk that the design does not work later. An outcome-focused functional specification gives suppliers room to bring their expertise to a suitable solution, while you still keep control over the final result.
Requirements are knock-out criteria: if a bid does not meet them, it is excluded. Wishes are points on which you compare and score bids against each other, often linked to award criteria. A common mistake is to make everything a requirement; this unnecessarily restricts the market and filters out good suppliers. Keep the number of hard requirements sharp and realistic, and use wishes to reward quality, approach and future-proofing. This way you steer towards the best value for money rather than the lowest price.
Name the standards relevant to your process, so the software fits the wider government landscape. Commonly these include the Case-based Working APIs (ZGW) for case data, the Dutch Baseline Information Security for Government (BIO) for information security and WCAG 2.1 AA for digital accessibility. Depending on the process, integrations such as DigiD, eHerkenning or TenderNed may be added. By stating standards explicitly, you avoid vendor lock-in and keep your architecture open. Which standards apply exactly depends on your organisation and process.
Because they determine whether you own your data and software after the contract ends, and whether you can move to another party without major obstacles. Set out who owns the source code and data, how data is handed over on termination, which documentation is delivered and how long handover and aftercare take. Without clear exit provisions, lock-in arises: you are tied to one supplier because switching becomes too costly or risky. Good exit arrangements therefore belong in the tender itself, not only in the contract stage.
The most common mistakes: prescribing the solution in full instead of describing the outcome, including too many points as hard requirements, missing or vague exit and ownership clauses, no attention to management and further development after delivery, and unrealistic timelines that only seem achievable with overly optimistic promises. A clear description of the existing systems to be integrated is also often missing. A tender that addresses these points attracts more comparable bids and a project that less often gets stuck during delivery.
We write transparently and realistically: we describe what we do and don't know, we make no promises that will come back to haunt you, and we're open about assumptions and risks. We work outcome-focused, deliver clear documentation, and agree explicitly on standards, ownership, exit and maintenance, so you're never locked in to us. If you're preparing a tender or running a market consultation, we're happy to help you assess feasibility. Get in touch without obligation via our contact page.
Preparing a software tender?
Tell us which process you want to support and where you're getting stuck in the preparation: formulating outcomes, requirements versus wishes, standards or exit provisions. We'll help you assess feasibility and sharpen your tender, without obligation. Please note this is general information and does not replace procurement law advice.