How can I choose a reliable web development company in the Netherlands?

TL;DR

• Start with your business goals, users, required integrations, legal obligations, budget range, and launch constraints - not a preferred colour or platform.
• Shortlist three to five companies whose recent, comparable work you can inspect live.
• Verify the supplier's legal name, KVK number, address, status, and signing authority. A KVK registration proves that an entity is registered; it does not prove development quality.
• Speak to two recent clients and ask about missed deadlines, change requests, support after launch, and whether the client would hire the company again.
• Meet the delivery lead and senior developer, not only the salesperson. Confirm what is done in-house, what is subcontracted, and where the team works.
• Compare proposals against the same brief. Normalize scope, assumptions, exclusions, licences, content, integrations, testing, hosting, maintenance, and VAT before comparing price.
• Define acceptance criteria for mobile layouts, supported browsers, accessibility, security, Core Web Vitals, SEO foundations, analytics, forms, and content editing.
• Keep the domain registration, hosting organization, source repository, analytics, tag manager, Search Console, and payment accounts in your company's name or under your administrator control.
• Put intellectual-property rights, third-party licences, data portability, documentation, backups, incident response, support levels and exit assistance in the contract.
• Use a weighted scorecard and a paid discovery phase when the project is complex or uncertain.

First decide what you are actually buying

“A new website” can describe very different engagements:

• a brochure website built from a proven theme
• a custom brand and marketing site
• a multilingual corporate platform
• a webshop with inventory, tax, shipping and payment integrations
• a membership, booking or learning platform
• a customer portal connected to CRM or ERP systems
• an accessibility or performance rebuild or
• an ongoing product-development partnership

The right supplier for a five-page local-business website may be wrong for a transactional platform. Before searching, write a one-page decision brief.

Minimum decision brief

• Business outcome: What should improve - qualified enquiries, online sales, applications, self-service, recruitment, or operational efficiency?
• Users and markets: Who uses the site, in which countries, languages, and devices?
• Critical journeys: What must a visitor be able to complete?
• Content: Who writes, translates, approves, and migrates it?
• Functions: Forms, search, payments, booking, accounts, calculators, gated content, or personalization.
• Integrations: CRM, ERP, product information, email, identity, payment, shipping, analytics, or other APIs.
• Constraints: Launch date, procurement rules, brand system, existing platform, hosting, internal skills, and compliance.
• Success measures: Baseline and target for conversion, task completion, performance, accessibility, organic visibility or support reduction.
• Budget range: A realistic investment range, including discovery, build, licences, content, hosting and the first year of support.

A company cannot estimate responsibly when the need is undefined. A confident fixed quote based on a short call may conceal assumptions rather than certainty.

Choose the right type of supplier

“Full service” should be verified. Ask which capabilities are staffed internally, which are partner-delivered, and who remains accountable when several companies are involved.

Step 1: build a shortlist from evidence, not rankings alone

Use referrals, sector networks, professional communities, procurement platforms, and targeted search. Search for the problem, platform, or sector, not only “best web development company Netherlands.” Examples include:

• “Shopify Plus development agency Netherlands B2B”
• “WordPress multilingual healthcare website Netherlands”
• “accessible public-sector web development Utrecht”; or
• “custom customer portal Microsoft Dynamics Netherlands.”

Directories and review platforms can help discover names, but ranking position, badges, and review totals can be paid, incomplete, or gamed. Treat them as leads rather than proof.

Create an initial list of six to ten suppliers, then reduce it to three to five using non-negotiable criteria:

• suitable project type and technical stack
• evidence of comparable complexity
• availability within the required window
• ability to work in the required language
• acceptable location or remote model
• capability for privacy, security, and accessibility needs; and
• willingness to work under clear ownership and handover terms.

Step 2: Verify the Dutch company behind the proposal

Ask for the supplier's:

• full legal and trading name;
• KVK number;
• VAT identification number where applicable;
• registered and operating address;
• legal form;
• authorized signatory;
• professional-liability and cyber-insurance details, when proportionate; and
• relevant general terms and conditions.

Use the official KVK service to confirm the registration and, for material contracts, order a recent Business Register extract. KVK explains that a certified extract is official proof of registration and reflects the company's details at the time it is requested.

Check whether the person signing is authorized to represent the entity. Business.gov.nl notes that lack of signing authority can affect a contract's validity.

What KVK verification can and cannot tell you

It can help confirm identity, registration, legal form, address, and authorized representatives. It does not certify technical competence, financial stability, ethical conduct, or future delivery.

Use additional evidence:

• Does the legal name on the proposal match the invoice and bank account?
• How long has the relevant team operated under this entity?
• Has the company changed name, directors, or ownership recently?
• Is the portfolio its own work or work performed by founders at former employers?
• Does the company depend on one founder or one external developer?
• Can it provide continuity if a key person leaves?

For a large or business-critical project, consider proportionate financial and legal due diligence with your accountant or adviser.

Step 3: Inspect live work, not portfolio screenshots

Ask for three projects completed within the last two or three years that resemble yours in at least two dimensions: sector, business model, platform, integration complexity, multilingual content, traffic, transaction risk, or accessibility requirements.

Open the live sites on desktop and mobile. Do not judge only visual taste. Test:

• Can you understand the offer and next action quickly?
• Do menus, forms, search, filters, and checkout work?
• Is text readable and navigation usable with a keyboard?
• Are pages fast on an ordinary mobile connection?
• Are cookie choices clear, or are tracking cookies placed prematurely?
• Are titles, headings, canonical URLs, and indexable content implemented sensibly?
• Are error, empty, loading, and confirmation states coherent?
• Does the site still appear maintained after launch?

Run public diagnostics as clues, not verdicts. Internet.nl tests whether websites and email use modern, reliable internet standards. PageSpeed Insights and browser tools can reveal performance signals. Automated accessibility tools identify some issues, but manual keyboard and assistive-technology testing is still required.

Ask for the story behind each project

For every case study, ask:

• What was the business problem and baseline?
• What did your team personally deliver?
• Which named people worked on it, and are they assigned to us?
• What integrations or constraints made it difficult?
• What changed after user testing or technical discovery?
• Which measurable outcomes improved, over what period?
• What failed or was deferred?
• Who maintains it now?

A result without a baseline, measurement method, or attribution is marketing - not reliable evidence.

Step 4: Speak to recent clients

Request two references for projects comparable in size and completed recently enough that post-launch support can be evaluated. Ask the candidate's permission to contact them directly.

Questions for references:

• Was the original scope clear and realistic?
• Did the team expose risks early?
• How close were final cost and date to the agreed plan, and why did they differ?
• Were change requests documented and approved before work?
• Did senior people remain involved after the sale?
• How well did the website work at launch?
• Were serious defects resolved quickly?
• Was training and documentation sufficient?
• Can your team make routine changes without the supplier?
• How does support perform six or twelve months later?
• What would you do differently?
• Would you hire the company again for a similar project?

The most revealing question is often: “Tell me about a difficult moment and how the agency handled it.” Every substantial project has uncertainty. Reliability appears in the response.

Step 5: Meet the actual delivery team

Sales chemistry is not delivery capacity. Before the appointment, meet the proposed:

• project or delivery lead;
• senior developer or technical architect;
• UX or product designer;
• QA lead or person responsible for testing; and
• post-launch support owner.

Ask what percentage of their time is reserved, what else they are delivering, and whether named people may be substituted. If work is outsourced, identify the subcontractor, country, responsibilities, access to personal data, security controls, and continuity plan.

Look for communication evidence

A reliable team can:

• restate the problem in plain language;
• identify unanswered questions;
• explain alternatives and trade-offs;
• distinguish a requirement from an assumption;
• say “we do not know yet” and propose how to find out;
• document decisions and responsibilities; and
• challenge a poor request respectfully.

Avoid teams that agree to every feature, promise a date before understanding dependencies or hide technical decisions behind jargon.

Step 6: Evaluate discovery and delivery process

The process should match the project's uncertainty. A small site may need a concise workshop and prototype. A custom portal may need research, architecture, data mapping, and a paid discovery phase before a responsible build estimate.

A credible process normally covers

• stakeholder and user discovery;
• analytics and current-site review;
• content inventory and migration planning;
• functional and non-functional requirements;
• information architecture and user flows;
• prototypes and usability validation;
• technical architecture and integration discovery;
• privacy, security and accessibility requirements;
• prioritized backlog and release plan;
• design and component-system decisions;
• development, code review and automated tests;
• QA across devices, browsers and user states;
• content entry and editorial training;
• acceptance testing and launch rehearsal;
• monitoring, backups and rollback; and
• post-launch warranty and improvement.

Ask to see working artefacts

Request anonymized examples of a discovery report, backlog item, decision log, test plan, accessibility finding, release checklist, and support report. A process described in slides is less persuasive than evidence that it is used.

Step 7: Test technical competence without becoming a developer

You do not need to select the programming language. You need to know whether the company makes maintainable decisions and can explain them.

Ask:

• Why does the proposed platform fit our users, editors, integrations, scale, and internal skills?
• Which parts are standard, configured, customized, or built from scratch?
• What are the expected upgrade and maintenance obligations?
• How will code be reviewed and tested?
• How will environments, deployment, and rollback work?
• How will structured content be separated from presentation?
• How will APIs fail safely and be monitored?
• Which components create vendor lock-in?
• How can another competent company take over?
• What technical debt are you deliberately accepting?

Prefer boring clarity over fashionable complexity

A common content website rarely needs the architecture of a global software platform. Conversely, a high-volume transactional service should not be forced into a fragile collection of plugins because it is cheap initially. The right architecture is the simplest one that meets current requirements and credible future needs.

Step 8: make security a contract requirement

“We use SSL” is not a security programme. Require a risk-appropriate approach covering design, development, deployment, and maintenance.

For a standard website, ask about:

• multi-factor authentication for administrative access;
• least-privilege roles and separate user accounts;
• dependency and CMS/plugin updates;
• secure handling of secrets and API keys;
• encrypted transport and appropriate security headers;
• form abuse, spam and rate limiting;
• backups, restore testing and retention;
• logging, monitoring and alerting;
• vulnerability reporting and incident response;
• deployment approval and rollback; and
• removal of test data and access after launch.

For web applications with accounts, payments, or sensitive data, use a structured standard. OWASP ASVS is designed to support development, security verification, and procurement requirements. Specify the relevant version and risk-appropriate verification level rather than writing “OWASP compliant.”

The Dutch NCSC maintains current TLS security guidelines. Ask who monitors security advisories and how quickly critical updates are assessed and installed. A security certificate is supporting evidence, not proof that your delivered website is secure.

Step 9: Verify privacy and cookie competence

If the company hosts, supports, or can access personal data on your behalf, determine the GDPR roles with your privacy adviser. The European Commission's processor guidance says a processor needs a contract or other legal act and must provide sufficient guarantees for appropriate technical and organizational measures. It also addresses confidentiality, controller instructions and sub-processors.

Ask for:

• a data-flow map for forms, analytics, CRM, hosting, backups and support
• purpose and legal basis for each personal-data flow
• processor and sub-processor identities and locations
• data-retention and deletion rules
• access controls and audit logs
• breach-notification procedure
• international-transfer mechanism where relevant; and
• a suitable processing agreement when the agency is a processor

Cookie banners are a practical competence test. The Dutch Data Protection Authority has acted against sites where refusal was hidden, choices were preselected, or tracking occurred before valid consent. Its cookie-banner guidance emphasizes clear purposes, unselected boxes, and equally accessible choices. Ask the agency to demonstrate consent behaviour in the browser - not only show the banner design.

Your organization remains responsible for the purposes and means it determines. Do not outsource privacy thinking with the build.

Step 10: Make accessibility measurable

Accessibility should be designed and tested, not added by an overlay before launch. Ask the company which standard, level, scope, test method, and evidence it will use.

WCAG 2.2 is the latest W3C standard and organizes requirements under perceivable, operable, understandable, and robust principles. W3C encourages use of WCAG 2.2. A practical procurement target is often WCAG 2.2 Level AA, but applicable Dutch or EU rules, sector obligations and contracts may refer to specific standards or versions.

The European Accessibility Act has applied since 28 June 2025 to covered products and services. Official Dutch business guidance identifies e-commerce among the covered services and describes accessibility-statement and service requirements, subject to scope and exceptions. Public-sector and sector-specific obligations may differ. Obtain legal advice for your service.

Require:

• accessible components and content-authoring guidance;
• keyboard and screen-reader testing;
• zoom, reflow, contrast and mobile testing;
• testing of forms, errors, menus, dialogs and dynamic states;
• inclusion of third-party checkout, booking or consent tools;
• a documented audit and remediation before acceptance; and
• a plan for preventing regressions after launch.

An automated score alone is not evidence of conformance.

Step 11: Define performance and SEO foundations

“Fast” and “SEO-friendly” are not acceptance criteria.

Performance

Define representative page types, devices, and measurement conditions. Google's Core Web Vitals guidance currently uses:

• LCP of 2.5 seconds or less for loading
• INP of 200 milliseconds or less for interactivity; and
• CLS of 0.1 or less for visual stability

measured at the 75th percentile, separately for mobile and desktop. New sites do not have sufficient real-user field data immediately, so use lab budgets before launch and implement real-user monitoring afterward. The contract should state which party owns optimization if third-party tags, content, or hosting later change results.

Technical SEO foundations

Require correct:

• indexability and robots controls
• canonical URLs and redirect mapping
• page titles, meta descriptions and headings
• semantic HTML and internal linking
• XML sitemaps
• structured data where genuinely applicable
• language and regional signals for multilingual sites
• image handling and alt-text workflow
• pagination or faceted-navigation strategy where relevant
• analytics and Search Console setup; and
• migration monitoring for changed URLs

No developer can guarantee rankings. Ask how it will preserve existing organic value and make the site technically discoverable.

Step 12: compare proposals line by line

Send every shortlisted company the same brief and question set. A reliable proposal should show:

• understanding of goals and users
• scope and named deliverables
• assumptions, dependencies and exclusions
• discovery and validation activities
• team roles and availability
• project plan, milestones and client responsibilities
• technology and hosting approach
• content and migration responsibilities
• integration scope
• testing and acceptance method
• security, privacy, accessibility and performance commitments
• price, VAT, payment schedule and rate card
• third-party licences and recurring fees
• warranty, support and maintenance
• ownership and handover; and
• proposal validity and contractual terms

Normalize the true cost

Headline prices are not comparable when one includes content migration, accessibility testing and the first year of licences while another does not.

Fixed price, time and materials, or hybrid?

• Fixed price fits a stable, well-defined scope. It transfers some estimate risk but often prices in contingency and needs disciplined change control.
• Time and materials fit discovery and evolving product work. It requires transparent priorities, budget controls, and frequent demonstrations.
• Hybrid can use fixed-price discovery or milestones with capped or rolling delivery.

The pricing model does not create reliability. Clear scope, evidence, governance, and visibility do.

Use a weighted selection scorecard

Score each candidate from 1 to 5 and multiply by the weight. Agree the weights before reading final proposals so presentation does not distort priorities.

Add a pass/fail gate for non-negotiables such as KVK verification, data residency, accessibility, platform, insurance, or launch capacity. A high total score should not override a failed critical requirement.

Contract clauses that prevent expensive surprises

Have an appropriate Dutch legal adviser review a material agreement. At minimum, address the following.

Scope and acceptance

Define deliverables, excluded work, acceptance criteria, review periods, defect severity, and what happens if acceptance fails. Avoid “industry standard quality” without measurable detail.

Milestones and payment

Link payments to meaningful outputs or time periods, not vague percentages. Keep enough leverage for final documentation, account transfer, and defect correction. Avoid a large non-refundable prepayment without corresponding value or protection.

Change control

Every change should state the impact on scope, price, timing, quality, and dependencies before approval. Name who can approve changes.

Intellectual property and licences

Dutch copyright can automatically protect original software and other creative work. Business.gov.nl explains that software can be copyright-protected and that rights arise automatically. Do not assume payment transfers ownership.

Specify:

• ownership or licence for custom code, design, copy, data and documentation;
• timing and conditions of any assignment;
• rights to pre-existing supplier frameworks;
• open-source and commercial third-party licences;
• whether components may be reused for other clients;
• warranties concerning authorization and infringement; and
• your right to modify and appoint another supplier.

Accounts, domain and source control

The client should normally control the domain registrant account and core service organizations. For .nl domains, SIDN explains that transfer requires a token and that the registrar must provide it within five days when requested. See SIDN's registrar guidance.

Require administrator access to:

• domain and DNS;
• hosting and cloud account;
• source-code repository;
• CMS and database;
• analytics, tag manager and consent platform;
• Google Search Console and advertising accounts;
• email delivery services;
• payment and commerce accounts; and
• design source files and licensed assets.

Use company-controlled email addresses and multi-factor authentication. Do not wait for a dispute to discover that the agency owns the keys.

Warranty and support

Define the defect warranty, what counts as a defect, response and restoration targets by severity, support hours, emergency contacts, exclusions, and escalation. Distinguish:

• response time: when the supplier acknowledges and starts triage;
• workaround target: when essential service is restored temporarily; and
• resolution target: when the underlying defect is fixed.

Security, privacy and incidents

Include minimum controls, vulnerability handling, patch timelines, breach notification, sub-processors, data deletion, audit evidence and cooperation duties. Align obligations with actual risk.

Termination and exit

Specify notice, export formats, repository and account transfer, documentation, knowledge-transfer hours, data return and deletion, assistance rates and deadlines. Ensure the website can continue if the relationship ends.

Business.gov.nl explains that general terms can cover payment, delivery, repairs, guarantees and disputes, and that customers must be informed of them before agreement. Read both the proposal and the incorporated general terms and conditions; conflicting clauses should be resolved in the signed order of precedence.

Warning signs of an unreliable web company

• It refuses to provide a KVK number, or the contracting entity changes unexpectedly.
• It cannot identify who will deliver the project.
• Its portfolio consists mainly of screenshots, dead sites, or work from previous employers.
• Every reference is old, unrelated, or unavailable.
• It recommends a platform before understanding users, content, and integrations.
• It promises guaranteed Google rankings or perfect accessibility from a plugin.
• It calls a security certificate or HTTPS the complete security solution.
• It asks for tracking cookies to load before valid consent without a reasoned legal basis.
• It will register the domain, hosting, and analytics only in its own name.
• It will not provide repository access, backups, or export rights.
• The proposal has a total price but few assumptions, exclusions, or acceptance criteria.
• It pressures you to sign immediately using a large discount.
• It avoids discussing maintenance, licences, lock-in, or exit.
• It dismisses documentation as unnecessary.
• It agrees to an unrealistic date without identifying client dependencies.
• It cannot explain a failed project or a difficult client situation.

One warning sign may have an innocent explanation. A pattern of opacity is the risk.

Questions to ask in the final interview

Business and users

• What do you believe this project must achieve?
• Which assumption in our brief worries you most?
• How will you validate that the solution works for users?
• Which requested feature would you challenge and why?

Delivery

• Who is accountable day-to-day, and who can make technical decisions?
• Show us how progress, risks, budget, and decisions are reported.
• What happens when we are late with content or feedback?
• What is your change-control process?
• Tell us about a comparable project that missed its original plan.

Technology and quality

• Why is this stack appropriate, and what alternatives did you reject?
• What is automated, what is manually tested, and by whom?
• How do you prevent regressions?
• How will another supplier take over?
• What will be the hardest part to maintain in three years?

Security, privacy, and accessibility

• Which security requirements and verification standard will be contractual?
• Who are the processors and sub-processors, and where is data handled?
• Demonstrate the cookie-consent behaviour technically.
• Which WCAG version and level will you test, and what evidence will we receive?
• Do you use disabled testers or independent specialists when appropriate?

Commercial and support

• Which costs are excluded or likely to change?
• What recurring licences and infrastructure costs should we expect for three years?
• What is covered by warranty versus maintenance?
• Show the response and restoration targets for a critical incident.
• What do we receive and control if the contract ends tomorrow?

A sensible selection process and timeline

Phase 1: preparation

• Name the decision-maker and stakeholder group.
• Write the decision brief and budget range.
• Set weighted criteria and non-negotiable gates.
• Decide whether paid discovery is needed before a build quote.

Phase 2: market scan

• Identify six to ten candidates.
• Review relevant live work and legal identity.
• Invite three to five companies with the same brief.

Phase 3: evaluation

• Hold a structured interview with the actual team.
• Review sample artefacts and technical answers.
• Contact references independently.
• Normalize proposal scope and total ownership cost.
• Score individually before the panel discussion.

Phase 4: risk reduction

• Run a paid discovery sprint, technical proof or design workshop for the preferred supplier if uncertainty is high.
• Check contract, terms, IP, privacy, security, support and exit.
• Confirm named team, capacity, start date, and governance.

Phase 5: appointment and mobilization

• Sign the final scope and order of precedence.
• Create client-controlled accounts and repository access.
• Establish decision, risk, change, and acceptance logs.
• Record baseline analytics and migration requirements before development.

What should a good handover include?

Do not treat handover as a zip file after launch. Require:

• source code and full repository history;
• build and deployment instructions;
• architecture and integration documentation;
• environment and configuration inventory, without exposing secrets in documents;
• database schema and export method;
• domain, DNS, hosting and service ownership;
• administrator and role matrix;
• licence and dependency inventory;
• backup and restore procedure with test evidence;
• monitoring and incident contacts;
• accessibility, performance and security test reports;
• redirect map and SEO migration record;
• CMS editor training and accessible content guidance;
• known issues and technical-debt register; and
• support, warranty and escalation details.

Test the handover before final acceptance: can an authorized client administrator log in, deploy safely, restore a backup, export data, and invite another supplier without asking for hidden credentials?

Frequently asked questions

Your next step

Create a shortlist of three companies and complete this evidence loop for each:

• Verify its legal entity and authorized signatory through KVK.
• Inspect three comparable live websites on mobile, by keyboard, and with public diagnostics.
• Speak to two recent clients.
• Meet the named delivery lead and senior developer.
• Send the same written brief and question set.
• Normalize scope, exclusions, recurring costs, and three-year cost.
• Score the company against predetermined criteria.
• Review ownership, security, privacy, accessibility, support, and exit terms.
• Use a paid discovery phase if major uncertainty remains.

Choose the company that makes risk visible and manageable. A dependable partner will not promise that web development is simple; it will show you how decisions are made, quality is verified, and control remains with your business.