Drupal

Drupal delivery with release criteria and a controlled module set

We take Drupal when content models, roles, or migrations need a written plan. Upgrades and greenfield installs share one rule: scope first, modules second.

  • Migrations and major-version upgrades with cutover plans
  • Content types and roles locked before theme work
  • GDPR and hosting listed in the same brief
Website services ↗
Engineering delivery session
VegconomistMemmertLeverage EduJump.acHome Music TeachersWOLVES SUMMITChatbot TeamBrilyantHolydogRatskeller NiedernhausenCalma CaosCarmen KosmetikAgriVijay
How we work Drupal

CMS engineering, against a release

Drupal projects stall when every stakeholder adds modules without an owner. We agree content types, permissions, and the success metric before the first custom module lands.

If WordPress covers the publishing job, we say so early. For enterprise peers see TYPO3 and Pimcore; for lighter sites see WordPress.

Config management and deployment discipline come before theme polish. Unexported config is how staging and production drift.

Week one

What we check before a Drupal engagement

  • Module and custom code mapContrib vs custom modules that touch auth, forms, and content types are listed with risk notes.
  • Content modelContent types, paragraphs, and media are checked against what editors need next quarter.
  • Security updatesCore and module update lag, staging practice, and who applies patches are confirmed.
  • Search and viewsHeavy Views and search configs on money pages are profiled before new features land.
Recent results

Selected work with commercial stakes

Memmert project
Manufacturing

Relaunch study before vendor lock-in

Requirements, localisation, and vendor-scope advice for a multi-market manufacturer relaunch.

Vegconomist project
B2B media

Four-market stack under one TechOps lead

Fractional CTO across vegconomist markets plus Cultivated-X: updates, adops, performance, and incident response.

Jump.ac project
E-mobility

Discovery and launch on a production stack

User interviews ran in parallel with the build so the site matched what buyers asked for.

Delivery

From brief to a Drupal release you can run

  1. Audit and outcomes

    Version, modules, content volume, and the metric that decides whether the cycle succeeded.

  2. Content and ownership map

    Content types, roles, hosting, and who maintains Drupal after launch written down.

  3. Engineering cycle

    Build against release criteria. Custom modules stay documented; unused contrib leaves the stack.

  4. Integrations and GDPR

    SSO, forms, and processors with consent behaviour and a written data map.

  5. Launch and handover

    Staging QA, redirect plan, backup check, and a short editor runbook.

What we ship

Drupal work we take on

Major upgrades

Plan Drupal upgrades with module triage, content migration, and a cutover window ops can own.

Content model work

Rebuild content types and permissions so editors publish without developer tickets.

Greenfield Drupal installs

New sites with written scope for roles, GDPR, and hosting before the first contrib module.

Migrations onto or off Drupal

Move content and URLs with redirects when Drupal stays or when WordPress is the better fit.

Fit

When Drupal is the right call

Good fit
  • You already run Drupal and need a scoped upgrade or modernisation
  • Complex roles, workflows, or multi-site publishing justify the investment
  • You want GDPR and hosting decisions in the same written brief
Probably not us
  • You need a simple brochure site with no Drupal ownership after launch
  • You expect unlimited hourly module installs without release criteria
  • You want market-share claims instead of a migration or greenfield plan
FAQ

Drupal questions

Do you migrate Drupal 7 or 9 sites to a supported version?

Yes. We audit modules, plan content migration, and keep redirects in scope. Open-ended upgrade retainers without exit criteria are a poor fit.

Drupal, TYPO3, or WordPress?

We choose from constraints: existing stack, editor skills, and who hosts after launch. See TYPO3, Pimcore, and WordPress.

Do you build greenfield Drupal sites?

Yes, when roles and content complexity justify Drupal. For many marketing sites we recommend WordPress and say so before you fund a greenfield install.

How do you handle GDPR on Drupal?

Consent, processors, and cookie behaviour belong in the build scope. We document vendors and keep marketing tags behind consent where required.

Where are you based?

Registered in Wiesbaden. Discovery and reviews can happen in person in the Rhein-Main region; delivery runs in structured cycles.

What do you finish in week one on Drupal?

Config management discipline, content type ownership, deploy path, and which modules are abandoned risk.

Do you theme before fixing config drift?

No. Unexported config between staging and production gets fixed before polish.

Direct contact

Office in Wiesbaden

Portrait of Vineet Talwar, Co-founder Tech & Operations
Vineet Talwar
Co-founder · Tech & Operations
Some Tech Work UG (haftungsbeschränkt)
Hans-Böckler-Str. 76
65199 Wiesbaden

Web design Wiesbaden →

Hier starten

Bereit fürs Gespräch.Buchen Sie eine kurze Diagnose.

Sagen Sie uns, was nicht läuft

Ein Prozess, ein Tool, eine hängende Entscheidung. Ein Satz reicht.

Mit dem Absenden stimmen Sie unserer Datenschutzerklärung.

Wir lesen jedes Briefing und antworten innerhalb eines Werktags.

Lieber erst sprechen?oder Tech-Stack-Audit anfragen →oder direkt per E-Mail →

Unklar, wo Sie anfangen sollen? Schicken Sie die hängende Entscheidung, den Workflow oder die Seite. Wir sagen, ob ein Diagnosegespräch, ein Tech-Stack-Audit oder ein anderer erster Schritt passt.