Web development for this market carries obligations that are invisible in the design file and expensive in the code. Several of them have to be decided before anybody opens an editor: what the site is allowed to load before a visitor consents, where the servers run, which legal pages exist and how they are reachable, and which payment methods the checkout must support. Treat those as requirements rather than as a compliance review after launch.
Consent comes before the first script, and that is an engineering constraint
The rule that shapes implementation more than any other is that non essential scripts may not run until the visitor has agreed. In practice this means analytics, advertising pixels, embedded video, map widgets, chat tools and hosted fonts all have to be gated. A consent banner that appears while the tags have already fired is not a control, and it is the most common defect in sites otherwise built to a high standard.
So specify the mechanism. Which consent platform, how categories map to individual services, how the choice is stored and revoked, what the page looks like with everything declined, and whether a preference is respected across subdomains. Ask a candidate to demonstrate a site they built with the network tab open and consent refused. What loads anyway is the honest answer to whether they understand the requirement.
Legal pages and imprint duties are build items with real rules
Commercial sites must carry an imprint and a privacy statement, both reachable from every page without a search, both readable without scripting. This sounds trivial until the navigation is designed with no footer, or the pages are rendered inside a component that fails when consent is withheld. Contact routes, company details, and the withdrawal instructions for anything sold online belong in the information architecture from the first wireframe.
Online selling adds further construction detail. Checkout has to state the total including tax and shipping before the order is confirmed, the confirmation button has to be labelled unambiguously, and the order confirmation and withdrawal form have to be generated reliably. These are template and logic decisions, so put them in the web development acceptance criteria rather than assuming the platform handles them.
Where web development in Germany differs on hosting and data
Buyers here scrutinise infrastructure earlier than buyers elsewhere. Expect questions about which region the application runs in, whether backups leave it, which third party services receive personal data, and whether a processing agreement exists with each one. Fonts and maps loaded from external providers have caused real trouble, which is why self hosting them is now the default answer rather than a preference.
The practical response is to inventory every outbound request the finished page makes, name the recipient of each, and decide which are essential. That list is also the document your data protection officer will ask for, so producing it during the build saves an argument later. A supplier who cannot generate it has not thought about the architecture in these terms.
Accessibility stops being voluntary for consumer facing services
Public bodies have been bound for years, and the obligation now extends to many commercial services sold to consumers, including online shops and booking systems. The reference standard is the familiar one, and WCAG 2.1 conformance is achieved in markup and behaviour: semantic structure, keyboard operation, visible focus, labelled forms, comprehensible error messages, sufficient contrast, and text alternatives that say something useful.
Write the target into the web development contract, require both automated checks in the pipeline and a manual pass, and ask for the statement of accessibility as a deliverable. Retrofitting a template after launch is several times the cost of building it correctly, and the deadline is not negotiable in the way an internal roadmap is.
The checkout has to match how people here actually pay
A store that offers only card payment will underperform badly, because the local payment mix is unusual by international standards. Direct debit, purchase on invoice, instant bank transfer and the established wallets all carry meaningful share, and purchase on invoice in particular brings consequences well beyond a payment button: risk scoring, dunning, partial returns, and reconciliation against your accounting system.
Decide the mix before architecture, because each method affects the order state machine. Ask candidates which providers they have integrated and what they had to build around each one. Returns handling deserves the same attention, since the statutory right of withdrawal means a functioning returns flow is part of the product rather than an afterthought.
Platform choice reflects a distinct local ecosystem
The platforms with the deepest web development support here are not always the ones dominant elsewhere, and choosing one with a thin local talent pool quietly narrows your options for the next several years. Content heavy corporate sites often sit on enterprise content platforms with strong regional communities; commerce projects gravitate to systems with established local extension markets and payment support already built.
The question to ask is about continuity rather than features. How many firms in this market could take over a project built on this platform, how active is the extension you depend on, and what does an upgrade between major versions actually involve. A stack that only your supplier enjoys working with is a dependency wearing a technical disguise.
Documentation, acceptance and handover expectations
The local buying culture rewards specificity, and this works in your favour if you prepare. Written acceptance against defined criteria is normal and expected, so write criteria that can be demonstrated rather than discussed: the form submits and the record reaches the system named here, the page renders within this budget on a throttled connection, the site remains operable with consent declined.
Ask for the handover pack as a deliverable: repository, build instructions, environment configuration, data model, and the outbound request inventory mentioned above. Require that a developer unconnected with the project can bring the application up from that documentation alone, and schedule that test before the final payment rather than after it.
Reading proposals when the supplier pool is small
This grid holds a compact set of verified suppliers rather than a crowd, which changes the tactic. Rather than collecting many quotations, brief a few properly and spend the saved effort on the conversation. Ask each one to write down what they believe the scope to be, what they have excluded, who would do the work and what they need from you. A firm that returns questions about your consent requirements, your payment mix and your existing systems is already doing web development thinking rather than sales.
If the requirement turns out to be an internal system rather than a public site, custom software teams price it on different terms, and if the pain is visual rather than structural, begin with design studios. The wider supplier picture is in the web development company directory, and neighbouring pools such as Amsterdam, Zurich or Budapest work comfortably under the same regulatory expectations. With consent handling, hosting region, payment mix and accessibility target written down, put the identical brief to several verified builders.