Drupal theme development decides how every page of a Drupal site looks and behaves in the browser. Drupal keeps content and presentation apart: content types, fields and Views define what exists, and the theme decides how it is shown, through Twig templates, CSS, JavaScript and reusable components. A good theme lets editors build new pages from approved components; a poor one turns every new layout into a developer ticket. Theming is a core part of our Drupal development services.
You get a theme in your own Git repository, built from a design you approved, with clean Twig templates, components documented for editors and developers, and accessibility and performance checked before launch. Whether you need a full Drupal website design or a restyle of the theme you already have, the work follows Drupal's own theming system rather than fighting it.
Drupal Theme Development Services We Offer
| Service | What it covers | What it means for you |
|---|---|---|
| Theme customization | A subtheme of your current or purchased theme, restyled with your brand colors, fonts and components, with a limited set of templates adjusted. | A fresh look without rebuilding the front end. |
| Custom Drupal theme | A theme built from your Figma or Adobe XD design, with clean Twig templates and Single Directory Components. | A front end that matches your design exactly and is easy to extend. |
| Design and theme | A Figma design system and page designs, followed by the custom theme build. | One team from first sketch to launched site. |
| Admin theme setup | Claro or Gin configured for editors, with editor styles that match the front end. | Editors see content the way visitors will. |
| Theme upgrades | Rebuilding Drupal 7 PHPTemplate themes in Twig, or updating themes that block a Drupal 10 or 11 upgrade. | The front end stops holding back core updates. |
Inside a Custom Drupal Theme: Files, Regions and Twig Templates
Knowing how a Drupal theme is put together helps you understand what you are paying for and what to ask about. A modern theme is a folder with a handful of well-defined parts:
| Part | What it does |
|---|---|
| my_theme.info.yml | Names the theme, sets its base theme, declares regions such as header, content and sidebar, and attaches global libraries |
| my_theme.libraries.yml | Groups CSS and JavaScript into libraries that load only where they are needed |
| my_theme.theme | Preprocess functions that prepare variables for templates, keeping logic out of Twig |
| templates/ | Twig template overrides, named by convention, for example a template for article teasers only |
| components/ | Single Directory Components, each with its own Twig, CSS, JavaScript and metadata |
| my_theme.breakpoints.yml | Breakpoints used by responsive image styles |
| theme-settings.php | Optional settings site admins can change, such as a logo variant or color scheme |
Twig template naming suggestions let us style one content type, view mode or field differently without touching others. During development we switch on Twig debugging, which Drupal exposes in its development settings page, to see exactly which template renders each part of the page. It is switched off again before launch.
Single Directory Components in Drupal Theme Development
Single Directory Components, often shortened to SDC, are part of Drupal core and keep everything a component needs in one folder: the Twig template, its CSS and JavaScript, and a metadata file describing the component's props and slots. A card, a hero banner or an accordion becomes a self-contained unit that templates include by name, and Drupal attaches its assets automatically.
For you, this means fewer one-off templates and a front end that stays consistent as editors add pages. For developers, it means components can be reviewed and changed in isolation, and documented in tools such as Storybook through contributed integrations. We build new custom themes around SDC, and when restyling an older theme we move its most reused patterns into components as we go.
Starterkit, Subtheme or Contributed Base Theme?
Every custom Drupal theme starts from something. The choice affects how much code you own and how updates reach you.
| Starting point | When it fits | Trade-off |
|---|---|---|
| Starterkit generator | A fully custom theme; Drupal core generates a standalone copy of its starter markup | You own all the code, with no upstream base theme changes to track |
| Subtheme of a contributed base theme | A framework such as Bootstrap Barrio or Radix matches your design approach | Faster start, but the base theme's updates and choices affect yours |
| Subtheme of your purchased theme | A restyle where the current layout mostly works | Quickest route, limited by the quality of the original theme |
Drupal recommends generating a theme from Starterkit rather than subtheming the core Olivero or Claro themes, because their markup can change between minor releases. For most custom projects, Starterkit is where we begin.
Free Drupal Themes, Purchased Templates or Custom Drupal Theme Development
Free Drupal themes on drupal.org, such as the core Olivero theme and contributed themes, are a reasonable start for internal sites and prototypes. Purchased Drupal templates from theme marketplaces look polished in demos but often bundle page builders and modules you will maintain for years. Custom theme development costs more up front and gives you exactly the components you need and nothing else.
| Option | Good for | Watch out for |
|---|---|---|
| Free Drupal theme | Internal sites, prototypes, tight budgets | Generic look; limited components; support depends on volunteer maintainers |
| Purchased template | Quick launch with a demo-ready design | Bundled dependencies, update lag after new Drupal versions, heavy CSS |
| Custom theme | Public sites where brand, accessibility and editor experience matter | Higher initial cost and a design phase before build |
Our Drupal Theme Development Process
- Content and template audit (about 1 week). We list your content types, view modes, Views and page layouts, and map them to the templates and components the design needs.
- Design (2 to 4 weeks, if included). A Figma design system with type, color and spacing tokens, then page designs for each key template. You approve before build.
- Component build (2 to 5 weeks). Components built as SDC with their own Twig, CSS and JavaScript, then wired into templates and preprocess functions.
- Integration with your content (1 to 2 weeks). Real content placed through Layout Builder, Paragraphs or your existing structure, with editor styles in CKEditor 5 matching the front end.
- Testing (about 1 week). Cross-browser and device checks, keyboard and screen reader checks against WCAG 2.2 AA, and Lighthouse performance runs.
- Launch and handover. Deployment through Git, a component guide for editors and developers, and a short training session.
A theme customization usually takes 2 to 4 weeks. A custom theme from an approved design takes 5 to 8 weeks, and a combined design and theme project takes 8 to 12 weeks.
Drupal Admin Theme Setup for Editors
The admin theme is what your editors look at all day. Claro is the default Drupal admin theme in current versions, and Gin, a contributed theme built on Claro, adds a cleaner editing layout that many teams prefer. We configure one of them, set up editor styles so headings and buttons in CKEditor 5 match the public site, and tidy the content forms so editors see the fields they use in a sensible order. Small changes here save editors time on every page they publish, and they reduce formatting mistakes that would otherwise need a developer to clean up later.
Drupal 7 Theme Development and Upgrading Old Themes
Drupal 7 themes used PHPTemplate files ending in .tpl.php, with PHP mixed into markup. Drupal 8 and later use Twig, and there is no automatic conversion between them. A Drupal 7 theme therefore has to be rebuilt as part of any move to Drupal 10 or 11, which is a good moment to fix design debt rather than copy it. Because Drupal 7 reached end of life in January 2025, we do not take on new Drupal 7 theme development; we rebuild Drupal 7 themes for current Drupal, usually alongside the content migration.
Performance and Accessibility in Drupal Theme Development
Most front-end performance on Drupal is decided in the theme. We attach CSS and JavaScript per component through libraries, so a page only loads the code its components use, and we rely on Drupal's asset aggregation to combine files in production. Images go through responsive image styles tied to the theme's breakpoints, with image styles that convert to WebP and lazy loading for images below the fold. Web fonts are limited to the weights the design uses and preloaded where they affect the first view.
Accessibility is built into components rather than checked at the end. Each component uses semantic HTML, visible focus states and sufficient color contrast, and interactive components such as menus, tabs and accordions follow established keyboard patterns. We keep Drupal's skip link and landmark regions intact, and use Drupal's built-in screen reader announcement helper when content changes without a page load. Editors also get guidance on headings and alt text, since content choices affect accessibility as much as code does.
Drupal Theme Development Deliverables
- A custom theme in your Git repository, deployed through your normal release process.
- Figma files and a design system, for projects that include design.
- A component library built with Single Directory Components, documented with usage notes.
- Responsive image styles and breakpoints for every image-heavy component.
- An accessibility check report against WCAG 2.2 AA, listing anything left for content editors.
- Lighthouse reports for key templates at launch.
- A short guide showing editors which components exist and when to use each.
When the theme replaces an existing one, we also run a visual comparison of key pages before and after, so content that relied on old styles is spotted and fixed before visitors see it. Any redirects needed because page structures changed are listed for the launch checklist.
A successful theme is measurable at launch: every content type renders through an approved template, components are reused rather than copied, Twig debugging and development settings are off, and CSS and JavaScript load only on pages that need them.
Drupal Theme Development Services Pricing
Our Drupal theming work is priced as fixed projects. Cost is driven by the number of templates and components, whether design is included, how many content types and view modes need styling, and how much existing content must be checked against the new theme. A restyle of an existing theme costs less than a custom build, and a combined design and theme project sits at the top.
Theme Customization
$1,200 one-time
One-time, paid upfront
- Subtheme of your current or purchased theme
- Brand colors, fonts and components restyled
- Up to 6 templates adjusted
- Mobile and browser fixes
- 30 days support
- 1 to 2 weeks
Custom Drupal Theme
$3,900 one-time
One-time, 50% upfront
- Built from your Figma or Adobe XD design
- Up to 12 templates in clean Twig
- Single Directory Components for reuse
- Styles for Layout Builder or Paragraphs
- WCAG 2.2 AA and Core Web Vitals pass
- 60 days support
- 3 to 5 weeks
- Add-on
- Extra template: $250
Design and Theme
From $6,900 project
One-time, milestone billing
- Figma design system and page designs
- Up to 20 templates
- Everything in Custom Drupal Theme
- Component library and style guide
- Editor training
- 90 days support
All prices in USD. Need something different? Ask for a custom quote.
If your project includes migration or custom modules as well, contact us for a combined quote.
Theming Mistakes That Make Drupal Sites Hard to Change
- Logic in Twig templates. Queries and complex conditions in templates instead of preprocess functions or modules, which makes them hard to test and debug.
- Editing a contributed theme directly. Changes lost on the next update, or updates never applied for fear of losing them.
- Overriding too many templates. Dozens of near-identical templates where one component with variations would do.
- Using the raw filter on user content. Printing editor or user input with Twig's raw filter bypasses Drupal's output escaping and opens the door to cross-site scripting.
- Ignoring cache metadata in preprocess. Variables that depend on the current user or URL without the right cache contexts, causing the wrong content to show.
- One giant stylesheet. All CSS loaded on every page instead of per-component libraries.
Who Our Drupal Theme Development Suits
A good fit if you:
- Run a Drupal 10 or 11 site whose design is dated or inconsistent across sections.
- Are moving from Drupal 7 and need the front end rebuilt in Twig.
- Want editors to build pages from approved components without developer help.
- Need accessibility and performance treated as requirements, not afterthoughts.
Probably not a fit if you:
- Need only a color or logo change, which your current theme settings may already allow.
- Want a large marketing site with no complex content model; a simpler platform may cost less to run.
- Plan to replace Drupal within the next year.
Related Drupal and Redesign Services
Themes often need custom functionality behind them, built by our Drupal module development team, and ongoing care through our Drupal maintenance services. If you are weighing a full rebuild, see our website redesign services.