Software market consultation: sounding out the market before your tender
Are you running a market consultation before tendering for software? Then you test feasibility, standards and realistic requirements before the tender specification is set in stone. As a market party, Appfront takes part in market consultations and shares knowledge on custom software development — on feasibility, open standards, government integrations and build-versus-buy, without the sales pitch. A sharper tender specification is in our interest too. On this page you can read how a market consultation for software works, how to set one up and what you can expect from suppliers.
What is a market consultation for software?
In a market consultation, you invite interested companies to think along with you about the feasibility and conditions of your planned contract before the procurement procedure begins. This is how PIANOo describes the instrument. You explore the structure of the market and find out which ideas and solutions already exist. The consultation is not part of the formal procurement procedure and is permitted, provided it is open, fair and transparent.
For software, this is especially valuable. Custom software often fits better than an off-the-shelf package when your process deviates from the market, when you need integrations with government building blocks, or when you want to avoid having to adapt your way of working to the limitations of a package. But build-versus-buy is not an obvious choice. A market consultation helps you weigh that decision carefully before you fix the tender specification — and prevents requirements that nobody can deliver or that are formulated too narrowly.
As a market party, Appfront takes part in market consultations for software. We share knowledge on feasibility, open standards and realistic requirements, without sales talk. A better call for tender is in our interest too. If you'd like to discuss your consultation or involve us, feel free to get in touch. This is general information and not legal advice on procurement.
Testing feasibility
Before you set requirements, you test whether your intended solution is technically and practically feasible. The market shows you which approach is realistic, which risks are in play and where your draft requirements are too tight.
Getting build-vs-buy right
Is there a suitable package, or is custom development the better route? The market shows which standard solutions exist, where they fall short, and when custom development is worth the investment for your process.
Formulating realistic requirements
With input from the market, you formulate requirements and criteria that are both achievable and sharp. This prevents a tender that is too narrow to attract good bids, or so broad that comparison becomes impossible.
How to set up a market consultation for software
A market consultation generally runs in four steps, from defining your goal and the right questions to processing the input into a sharper tender. You choose the format — written, conversations, a market event or demonstrations — based on what you want to learn. At every step, observe the transparency and equal-treatment rules.
Formulate the problem statement and what you want to learn from the consultation: is it about feasibility, the choice between build and buy, standards, or testing draft requirements? Decide whether the consultation is open or closed.
Ask the market specific questions about feasibility, suitable open standards and integrations, management, risks and lead time — and about which draft requirements would be unrealistic or unnecessarily restrictive.
Gather input through a written questionnaire, conversations, a market event, or demonstrations and presentations. Make clear in advance how you will handle the input, and that participation gives no advantage in the later tender.
Turn the insights into sharper requirements, criteria and a suitable procedure. Make any information provided available in good time to all potential bidders, so that no one is favoured or disadvantaged.
Which questions to put to the market
The value of a market consultation lies in good questions. Below are the themes that are most often worth putting to the market for custom software — so that your tender is sharper and more feasible later on.
Feasibility and approach
Is your intended solution technically and practically feasible within your context? Which approaches are realistic, which risks do suppliers see, and where lie the greatest uncertainties? Test this before you fix the requirements.
Open standards & integrations
Which open standards and government integrations are the obvious fit for your process — think DigiD, eHerkenning, the ZGW APIs, the BAG or the BRP? By asking about this up front, you avoid vendor lock-in and align with nationwide government agreements.
Build, buy or a combination
Is there a suitable standard package, or is custom development the better route — or a combination? Ask the market which packages exist, where they fall short for your process, and when custom development or a hybrid approach delivers more value.
Realistic requirements and criteria
Are your draft requirements achievable and not unnecessarily restrictive? Which requirements would exclude good suppliers, and which criteria would make bids more genuinely comparable? Test your draft programme of requirements with the market.
Management, further development and exit
What does management and further development look like after go-live, and how do you avoid dependence on a single supplier? Ask about source code ownership, documentation, portability and exit scenarios, so that you are not locked in later.
Lead time and planning
What is a realistic lead time for design, build and migration, and which dependencies play a role? Testing this helps you avoid a timeline in the tender that the market cannot deliver or that leads to failed tenders.
Which public authorities run a market consultation
Almost any public organisation can run a market consultation ahead of a software tender. We often see a number of situations recur, each with its own questions for the market.
Municipalities
Municipalities that want custom software for processes that deviate from off-the-shelf packages, such as citizen services or supervision and enforcement. A market consultation helps with the choice between build and buy and with suitable integrations. See also building software for municipalities.
Provinces & water boards
Provinces and water boards with challenges around permits, supervision and area-based working. By consulting the market, you test feasibility and standards before tendering — and take government integrations such as the ZGW APIs and the VTH domain into account.
Implementing bodies
Implementing bodies and partnerships that work case-based or support complex chain processes. A market consultation helps you formulate realistic requirements and lead times, and to clarify integrations with national building blocks up front.
Innovative or complex projects
Projects where the solution is not yet fixed or where the market changes quickly. This is exactly where a market consultation pays off: you explore what is technically possible and avoid setting requirements the market cannot deliver. Also consider building VTH software as a cluster example.
Standards and integrations to ask about
For custom software for government, it pays to ask about open standards and government integrations already in the market consultation. This way you avoid vendor lock-in and align with nationwide agreements. We build with a modern web stack and have experience with the relevant national building blocks — think DigiD, eHerkenning, the ZGW APIs, the BAG and the BRP. You usually publish a tender via TenderNed.
Why Appfront takes part in market consultations
Appfront builds custom software and knows the government standards and integrations that come with this kind of work. We take part in market consultations to share knowledge on feasibility, standards and realistic requirements, not to sell. A sharper tender specification is in everyone's interest, including ours.
We respect the transparency and equal treatment rules that apply to a market consultation. We assume our input is made available equally to all participants and that taking part gives no advantage in the subsequent tender. Our answers are well-founded and honest about what is and is not possible.
You speak with people who understand both the technology and the practice of government software. That keeps the conversation concrete: about integrations, build versus buy, maintenance and lead times. Our input helps you write a better specification, whoever ends up winning the contract.
See also: tendering custom software (the next step) and Appfront as a software supplier to the public sector. You can also explore our wider services around software for municipalities, permits, enforcement and licensing software and AI for municipalities and government. Want to talk through your consultation? Get in touch.
- Experience with custom software for government
- Knowledge of open standards and national building blocks
- Honest advice on feasibility, without sales talk
- Well-founded answers to your questions to the market
- Insight into build versus buy and realistic lead times
- Respect for transparency and equal treatment rules
- Attention to management, portability and exit
- Conversation covering both technology and practice
- Focused on a sharper, better-founded tender
- Independent thinking, even if you ultimately choose differently
Compliance requirements to include in the tender
Government software almost always processes personal data. It's worth bringing the relevant frameworks into the market consultation and the tender from the start: the GDPR for careful processing and data minimisation, and the Baseline Informatiebeveiliging Overheid (BIO, Baseline Information Security for Government) as the standard for information security. Ask the market how suppliers meet these requirements and which verifiable measures they take.
If you're building citizen-facing software, include digital accessibility too: WCAG 2.1 AA and the statutory obligations under DigiToegankelijk apply to government websites and applications. Ask the market about data minimisation, logging, encryption and role-based access. For privacy frameworks, the GDPR is the guiding standard.
Would you like to discuss which security and accessibility requirements are realistic and appropriate for your procurement? Feel free to get in touch. This is general information, not legal advice on public procurement.
- GDPR-compliant processing and data minimisation
- Baseline Information Security for Government (BIO)
- WCAG 2.1 AA and DigiToegankelijk where applicable
- Encryption in transit (TLS 1.2+) and at rest
- Role-based access and least privilege
- Audit logging and traceability
- Open standards and portability
- Documentation for your record of processing activities
Frequently asked questions about market consultations for software
Answers to the questions we are asked most often about market consultations ahead of a software procurement.
In a market consultation, you invite interested companies to help you assess the feasibility and conditions of your planned contract before the formal procurement procedure begins, as PIANOo describes the instrument. A market consultation is not part of the formal procurement procedure and is permitted provided it is open, fair and transparent. For software procurements it is especially valuable, because it lets you test technical feasibility and realistic requirements before you finalise the tender. This is general information, not legal advice on public procurement.
Software procurements are often complex and the market moves quickly. With a market consultation you test whether your intended solution is technically feasible, which open standards and government integrations fit, whether build, buy or a combination suits best, and whether your draft requirements are realistic for the market. This prevents you from setting requirements in the tender that no one can deliver, or that are too narrowly defined. The result is a sharper, better-founded tender.
You are free to choose how to shape the consultation. According to PIANOo, a market consultation can be open or closed, written, oral or a combination, and interactive or non-interactive. For software you often see a written questionnaire on feasibility and standards, followed by conversations or a market event, and sometimes demos or presentations in which suppliers explain their approach. You choose the format based on what you want to learn and how much time you have.
Start with a clear problem statement and the purpose of the consultation, then ask the market concrete questions about feasibility, standards, maintenance and lead times. Good questions cover, for example, which open standards and integrations are the obvious choice, what risks suppliers see, how build versus buy compares, and which requirements would be unrealistic. Make clear in advance how you will handle the input, and that taking part gives no advantage in the later tender.
You can expect a professional supplier to think along about feasibility and standards, to be honest about what is and isn't possible, and to give well-founded answers to your questions, without sales talk. A good market party will also point out risks, alternatives, and points where your draft requirements lead to unnecessary restrictions or higher costs. Appfront participates from that same interest: better briefs lead to better tenders for the whole market.
A market consultation must always be open, fair and transparent; interested suppliers must not gain or lose an advantage over competitors, according to PIANOo. In practice, this means you must also promptly share any information you provide to participants with other potential bidders, and that no participating market party ends up in a favoured or disadvantaged position at the time of tendering. Document the process and the information provided carefully.
Yes. Appfront actively takes part in market consultations for software at government bodies and shares knowledge on feasibility, open standards, government integrations and realistic requirements. We do this without sales talk, because a sharper tender specification is in everyone's interest, including ours. We respect the transparency rules and assume our input is made equally available to all participants.
Taking part in a market consultation is voluntary for suppliers, and the organising government body decides whether the consultation is open or closed. Appfront does not charge for contributing to a market consultation; we see it as knowledge sharing that benefits the market and the brief. If you would like us to be involved in your consultation or to discuss it, please get in touch.
Involve Appfront in your market consultation?
Are you organising a market consultation for a software tender? Invite Appfront or discuss your approach with us without obligation. We will help think through feasibility, open standards, build-versus-buy and realistic requirements, without sales talk, because a sharper brief is also in our interest. This is general information and not legal advice on public procurement.