As a development studio, we
engineer structure rather than launch pages. With Drupal,
we define every content type, view, and relationship up front, so the platform stays clean no matter how big it gets. No loose templates. No growing pains.
Blocks show up where
they shouldn't.
Context rules fixed.
Visibility logic cleaned.
Views load
forever.
Queries optimized.
Caching tuned.
The content model
is pure chaos.
Content types reviewed.
Fields deduplicated.
Admins avoid
the backend.
UI rebuilt for humans.
Permissions made sane.
Many Dutch public services now run through an online portal. When that portal is built on Drupal, the login is often the hardest part of the project. Citizens sign in with DigiD. Businesses sign in with eHerkenning. Both come with obligations that reach deep into how the site is built and hosted.
DigiD is the government login for residents. Access to it is limited to government bodies and organisations with a public task, and each connection is registered. The connection runs over SAML, a standard single sign-on protocol, so Drupal acts as the service provider. Contributed modules for SAML exist and cover the protocol well. The work lies in everything around them.
The biggest demand is the security assessment. A DigiD connection requires a periodic assessment by an independent IT auditor, measured against a published set of security norms. It covers the application, the server, the hosting environment and the processes of the organisation that runs them. A Drupal site that was never built with an audit in mind will struggle to pass.
So plan for it from the first sprint. Keep contributed modules to what is needed and patch them on a schedule. Separate the public site from the logged-in portal where possible, so the audited surface stays small. Log sign-ins and administrative actions in a form the auditor can review. Document the hosting setup, including who can reach production.
eHerkenning works differently. It is run through approved brokers, and the business chooses one to obtain its login means. The service decides which assurance level it requires, depending on the risk of the transaction. The portal connects to a broker, again over SAML, and receives attributes about the company and the person acting for it.
That last point changes the data model. An eHerkenning login tells the site which organisation someone represents and whether they may act for it. Drupal roles alone do not express this well. Most portals need an extra layer that stores the organisation, links users to it and checks their authorisation on each request.
Personal data needs care. DigiD can return the citizen service number, and that number may only be processed where the organisation has a legal basis for it. Store it only if the service requires it, encrypt it at rest and keep it out of logs.
Budget time for the testing environments both schemes provide. Integration tests against them take longer than developers expect, and certificates must be renewed on a calendar that someone owns.
The theme is where Drupal meets the design. It turns structured content into the pages visitors see. How it is organised decides whether a front-end developer can change a card in an hour or spends a day hunting for the right file.
Drupal themes use Twig, a template language that keeps logic out of markup. Each piece of output, from a whole page to a single field, can have its own template. That flexibility is powerful. It also means a theme can grow into hundreds of loosely named files that nobody fully understands.
Single directory components address this. A component, such as a teaser card or a call-to-action block, lives in one folder with its template, its styles, its scripts and a small file describing its inputs. Drupal core supports them directly. The developer finds everything for the card in one place, and the component can be reused wherever the design calls for it.
The main discipline is mapping content to components cleanly. A node template should not contain layout details. It should pass the right fields into a component and stop there. When this rule holds, redesigning the card means editing one folder, and every page that uses it updates together.
Start from a base theme with care. Some teams extend a heavy contributed theme and spend the project overriding it. Others start from a minimal starter and add only what the design needs. The second route usually produces a smaller, faster theme with fewer surprises during upgrades.
Keep an eye on what Drupal adds by default. Core and contributed modules print wrapper markup and classes that a design system may not want. Removing them in templates is fine, but check that accessibility attributes and contextual editing links survive.
Front-end tooling deserves a plan too. Decide how styles are compiled, whether a pattern library such as Storybook mirrors the components, and how the build runs on deployment. A theme that only builds on one laptop becomes a problem the day that person leaves.
Finally, write the component inventory down. A short list of every component, its inputs and where it is used saves future developers from building a second card that looks almost like the first.
On Drupal, content structure and integrations set the build — not how fast we can stitch something together.
Didn’t find what you were looking for? Drop us a line at info@toimi.pro.
We’ll migrate and map what makes sense — and fix what’s slowing you down. Your content types will finally reflect how your site works.
Yes — with proper translation workflows, field-level control, and no duplication disasters. Drupal handles this natively when set up right.
Very — if it's built intentionally. Our IT company audits every module, isolates permissions, and configures update routines so nothing slips.
Absolutely. Roles, workflows, revisions, and content staging are what Drupal was made for — we just make it usable.
