Skip to main content

Service

Drupal architecture & complex builds

Content architecture, multisite, and custom modules for the business rules contrib does not cover. For Drupal builds where the data model is the complicated part.

Most Drupal platforms that became expensive were not badly coded — they were badly modelled. A content type added under deadline, a field reused for two different meanings, a view doing work a query should do, and three years later every change touches five places. We spend the time on the model first: entities that mean one thing, a component layer editors can assemble without a developer, and custom code only where contrib genuinely has no answer.

Scope

How the work is delivered

  1. Content architecture

    Entity types, fields, taxonomies and relationships modelled around how the content is actually maintained, not around how the first page mockup looked. The model gets written down before it gets built, including what deliberately stays out of it.

  2. Component and front-end architecture

    A front end assembled from components editors can combine themselves — SDC where the platform is on a version that supports it, paragraphs where it is not — so a new page stops requiring a developer and a deploy.

  3. Custom modules

    Business logic contrib does not cover, written as proper Drupal: services and dependency injection, config in git, hooks where hooks belong, and tests around the parts that would be expensive to get wrong. Including taking over modules somebody else wrote and left undocumented.

  4. Multisite and shared codebases

    Several sites on one codebase with shared components and per-site configuration, plus the config-split and deployment setup that stops them drifting apart the moment one of them is in a hurry.

  5. Staged re-architecture

    When the existing model cannot carry what the business now needs, we rebuild it in stages — the new structure alongside the old one, content moved in batches, each step shippable. Big-bang rewrites are where platforms go to die.

Talk through the build

Send the platform, constraints, and timeline. We'll reply with the engineering questions that decide scope.

  • Reply within one business day, weekday hours UA / EU.
  • 30-minute discovery call when it is useful.
  • Scope written around deliverables, risks, and ownership.
https://ukrainix.com