As a development studio,
we design WordPress sites
that behave like products
— structured, stable, and built
to last. Every layout, plugin,
and page is picked for a reason. No theme detours. No drag-and-drop debt.
Design looks off on certain pages.
Custom layout system built.
Styles cleaned, reused.
Admin panel
is a mess.
Roles defined.
Workflow simplified.
Page speed drops
with every plugin.
Stack reviewed.
Redundant calls removed.
Template updates break everything.
Codebase audited. Dependencies isolated.
A WordPress site aimed at buyers in the Netherlands carries three expectations that a generic build tends to miss. Visitors expect a real choice about cookies. They expect to read the site in Dutch, with English close at hand. And if the site sells, they expect to pay with iDEAL.
Start with consent. GDPR applies, and the Autoriteit Persoonsgegevens, the Dutch data protection authority, supervises how personal data is handled. Its published guidance is plain about tracking cookies. Consent has to be given before they load, and refusing should be as easy as accepting. A banner that shows one bright accept button and hides the refusal behind a settings link invites trouble.
On WordPress the weak spot is rarely the banner itself. It is everything that loads before the visitor answers. Analytics snippets pasted into the header, a video embed, a chat widget added by a plugin, a map on the contact page. Each can set cookies on its own. A proper setup blocks those scripts until consent arrives and loads them only for the categories the visitor accepted.
So the build needs an inventory of which plugins set cookies and which third parties receive data. That list feeds the consent tool and the privacy page. Recheck it after every new plugin.
Language comes next. Most Dutch audiences read English comfortably, yet a Dutch version still converts better for local services and is usually expected for anything legal or transactional. WordPress handles this through a multilingual plugin such as WPML or Polylang. The choice matters less than the decisions around it.
Decide early whether each language gets its own slugs, whether menus are translated or rebuilt, and who owns the Dutch copy. Machine translation is fine for a draft. It is not fine for terms and conditions or a checkout page. The consent banner, form labels and error messages need both languages too.
Then payment. For a WooCommerce shop selling to Dutch customers, iDEAL is the method people reach for first, because it pays straight from their bank app. WooCommerce does not offer it by itself. It arrives through a payment provider plugin, and providers differ in fees, payout timing and how they handle refunds.
Test the whole path on a phone. A buyer taps iDEAL, jumps to the banking app, confirms and returns to the shop. If the return step drops the session or lands on a blank page, orders go missing even though the money moved.
The first real decision is the theme type. The site can use a block theme, where headers, footers and templates are all built from blocks inside the editor. Or it can use a classic theme, where templates live in PHP files and the editor only controls the content area. They lead to very different sites to own.
A block theme puts layout in the hands of editors. Someone on the marketing side can open the site editor, change the header, adjust a template for blog posts and save. No developer is involved. Small teams that publish often like that freedom.
The same freedom is the risk. Templates edited in the browser are stored in the database, while the original files remain in the theme folder. After a few months nobody is sure which version is live. A developer who updates the theme may find that nothing changes, because a saved template in the database overrides the file.
A classic theme draws a firmer line. Structure is code, reviewed and deployed like code. Editors write and arrange content inside the areas the theme exposes. Changing the header means asking a developer. That is slower, and for a site where layout is part of the brand, it is exactly the point.
There is also a middle path. A block theme can lock parts of itself down. Template locking, restricted block lists and a theme.json file that limits colours, font sizes and spacing to an approved set all narrow what editors can break. Patterns give them ready sections instead of a blank canvas.
Plugins shape the choice as well. Some older plugins still assume a classic theme and inject markup through hooks that block templates do not call. Check the plugin list against the theme type before committing.
A practical rule helps. If the people editing the site change layouts weekly and there is no developer on call, a block theme with strict limits is usually the better fit. If the site has a designed system that must stay consistent, a classic or hybrid theme keeps structure in code where it can be reviewed.
What drives the scope is the architecture — how much custom code the project actually needs, not how many plugins we bolt on.
Didn’t find what you were looking for? Drop us a line at info@toimi.pro.
Yes. As a web studio, we preserve preserve key URLs, redirect what’s needed, and keep metadata intact so rankings don’t tank during relaunch.
We don’t use off-the-shelf themes. Every layout is custom — built for your brand, not someone else’s demo.
We structure the backend to match how your team actually works — no plugin clutter, no guessing where content lives.
Absolutely. We can plug into your team — whether you need us to take the lead or just bring the WordPress expertise.
