Web development in Amsterdam starts with a question most briefs skip
Buyers here usually arrive with a look in mind and a launch date in mind, and almost nothing written down about what sits between the two. Web development is where the budget actually goes, and it is the part of a project that a marketing brief rarely describes. Before asking anyone for a price, settle three things: who will edit the site next year, which other systems it has to exchange data with, and whose name is on the accounts it runs on.
Those answers change the shape of every quote you receive. A firm pricing a fixed set of pages is solving a different problem than one pricing an editable platform with roles, review steps and an integration layer. Both can be sensible. Comparing them side by side without knowing which you asked for is how buyers in Amsterdam end up paying for the same site twice.
Who holds the keys to the domain, the hosting and the repository
Ask in writing whose name sits on the domain registration, whose account pays the hosting bill, and where the source code lives. In smaller projects the supplier commonly holds all three, which is comfortable until the relationship ends or the supplier does. There is nothing wrong with a partner managing infrastructure on your behalf. There is a great deal wrong with not being able to take it back.
A workable arrangement puts the domain in an account you own, keeps hosting either in your account or transferable on request, and treats the repository as yours with the supplier invited into it. Write the handover procedure into the web development contract rather than accepting it as a promise in a meeting. A candidate who hesitates on this point has told you something useful before you have signed anything.
The content model decides how the site ages
Sites rarely fail because of how they looked on launch day. They fail because every new page needs a developer. That outcome is set early, when someone decides whether content is structured into reusable types with named fields or poured into a single rich text area per page.
Ask candidates to sketch, for a site like yours, the content types they would create and who would be allowed to publish each one. A web development team that answers with roles, fields and a review flow has built something maintainable before. One that answers by naming a drag and drop page builder has quietly told you that your staff will be assembling layouts by hand for years.
Payments, forms and the systems behind the pages
Shoppers in this market expect iDEAL at checkout, and a payment method is never only a button. It brings order states, refunds, failed payment handling, invoice numbering and whatever finance needs in order to reconcile. The same applies to a booking form that has to reach a CRM, or a stock figure that has to agree with a warehouse system.
List every system the site must talk to and note, for each, whether an interface already exists, who maintains it, and what the page should do when it is unavailable. Integration is the most common source of overrun in web development work, mostly because it gets scoped from one sentence in a brief instead of from the actual interface documentation.
Publishing in two languages without doubling the work
Many organisations here publish in Dutch and in English, and how that is done belongs in the build rather than in a later phase. A second language needs its own addresses, its own language markup, its own navigation and a rule for what happens when a page exists in one language only. Retrofitting that into a site designed for a single language is close to a rebuild.
Ask how partial translation is handled, whether editors can see which pages have drifted out of date in the second language, and how search engines are told which version serves which audience. Small questions, large consequences for the maintenance bill.
A performance budget belongs in the specification
Speed is not a polishing task at the end. It is the sum of a hundred earlier choices about images, fonts, scripts and how much work the browser must do before anything appears on screen. Agree a target before work starts, agree how it is measured, and agree that it is checked on ordinary devices over a mobile connection rather than on a developer machine plugged into fibre.
Then agree what protects it afterwards. A fast site loaded with marketing tags six months later is a slow site. Whoever controls the tag container needs to know the budget exists and who signs off on breaking it.
Accessibility and consent are written in code
Keyboard navigation, focus order, form labels, colour contrast and a sane heading structure are produced by developers, and they cost far less while templates are being built than they do as repairs afterwards. Ask whether the supplier tests against WCAG criteria and with a screen reader, or whether accessibility means running an automated checker the week before launch.
Consent behaves the same way. A banner that appears after tracking has already fired is decoration. The requirement is that scripts do not load until consent exists, which is build behaviour, and it reaches into analytics, embedded video and anything else served from an outside provider.
Support after launch is part of the scope
Every site carries dependencies that need patching, a platform that ships updates, and certificates that expire. Decide before signing who does that work, how fast a security fix is applied, and what response you can expect when something breaks at the weekend. Put it in a separate support agreement with its own price, so that ending the web development relationship does not mean losing the site.
Ask what the supplier treats as a warranty defect and what they treat as a change request. The distance between those two definitions is where nearly every argument after launch happens.
Comparing web development companies in Amsterdam
Give three suppliers the same written brief, including content types, integrations and the performance target, then ask each to break the price into build, integration, content migration, testing and support as separate lines. A quote that arrives as one number cannot be compared and usually conceals the parts that overrun.
Ask each for a reference from a client whose site they no longer maintain, and ask that client how the handover went. It is a short call and it tells you more than a portfolio ever will. You can review verified web development companies in Amsterdam, widen the search through the full directory of development partners, and gather comparable proposals with our offer request form. Where the job also covers interface decisions, a mobile client or search visibility, see web design agencies, mobile app companies in Amsterdam and SEO agencies working with the same buyers.