When a custom Drupal theme from Starterkit beats subtheming Olivero
Generate a new theme with the core Starterkit when your team needs a branded front end that it will own for years. Subtheming Olivero only makes sense when the changes are small, such as a color palette, a logo and a few component tweaks, and you accept that every change the parent makes flows into your site. Starterkit gives you a theme you own from the first commit: its own info file, libraries file, Twig templates and stylesheets. Your team edits the files it will maintain and does not patch files it does not control. The theme lives in your code base and under your version control, with no parent theme to track.
The upgrade cost of a subtheme comes from the Classy and Olivero templates you copy into it. When you override a template, you freeze a copy of that markup in your repository, and that copy does not update when core changes. Core ships bugfix releases on the first Wednesday of each month, security releases on the third Wednesday, and new major versions about every three years, so each parent change becomes a merge you must review. The timing matters now: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Check the current Drupal core release schedule before you plan the work, and test the theme against the version you will run next.
Before you commit, confirm three things with your team. First, which Olivero templates you would have to copy to reach the design, and how many of them change in each core release. Second, whether your Drupal version and PHP runtime match the Starterkit output your developers will generate, since PHP requirements differ by major version. Third, who reviews markup and accessibility after each core release. Drupal is licensed under GPL-2.0-or-later and has no paid edition, so the cost of a custom theme is labor and maintenance time. Plan for that time as a recurring line item, not a one-off build cost.
How to generate and configure a Starterkit theme
This sequence takes a new theme from the core Starterkit generator to a default theme that renders every core template correctly. Each step ends with a check, so problems surface while the theme is still small and easy to change.
Confirm the target core version and tooling
The developer lead confirms which Drupal core version the site will run, then checks that the development environment matches the PHP and database requirements for that version. Confirm the exact Starterkit generator command and any Node.js or build tooling versions against the current Drupal.org documentation for the target core version, not against notes from an earlier project. The step is done when the environment reports the expected Drupal and PHP versions and the generator command is written down in the project README.
Generate the theme with Starterkit
A developer runs the core Starterkit generator to create a new theme directory with a machine name that follows the client's naming convention, rather than copying Olivero or another core theme. The generator produces the theme folder, an info file and starter templates, so the theme owns its own code from the first commit. The step is done when the new theme appears in the appearance list of the admin interface as an uninstalled theme and the generated files are committed to version control.
Set the theme info and libraries
The developer edits the theme's info file to set the name, description, base theme settings, regions and library declarations, then confirms that the libraries file lists only the CSS and JavaScript the theme needs. Keep the declared regions aligned with the layout the design team has approved, and avoid adding dependencies on core theme libraries that the theme does not own. The step is done when the cache is cleared and the theme's libraries resolve without missing-file errors in the browser console or the watchdog log.
Define base CSS and build tooling
The front-end developer sets up the base stylesheet structure, design tokens and the build pipeline that compiles source styles and scripts into the theme's output files. Decide early whether compiled assets are committed or built during deployment, and record that decision with the deployment team, because it affects the release process. The step is done when a single build command produces the compiled files, the output is referenced by the libraries file, and the built assets load on a test page without changing the theme's source.
Enable and set the theme as default
An administrator enables the new theme and sets it as the default theme in the appearance settings, then confirms that the administration theme is set separately and that the front end uses the new theme. The developer checks the theme's configuration export so the default setting is captured in configuration rather than made by hand on one environment. The step is done when the configuration export shows the new default and a second environment loads the same theme after a configuration import.
Verify rendering across core templates
The QA lead checks the theme on the pages that exercise core templates: content pages, listing views, the search results page, user login and account pages, error pages and the administration interface. Look for missing regions, unstyled markup, broken forms and JavaScript errors, and test at the breakpoints the design specifies. The step is done when the checklist for these templates is signed off, and any gaps are recorded as tickets rather than fixed by overriding core markup in the theme without review.
Record the upgrade baseline
The lead developer writes down the core version, generator version and any build tool versions used to create the theme, and notes which templates and libraries were customized. This record shows which parts of the theme depend on core markup, so the team can review them when the next core version is released. The step is done when the baseline sits in the project documentation and the team has agreed who reviews it at each core release.
Which theme approach fits which project
This table compares four ways to build a Drupal theme: a Starterkit custom theme, a subtheme of Olivero, a subtheme of Classy, and a component-based theme using Single-Directory Components. Read each row across to see when an option fits, how exposed it is to upgrades, what drives effort, and what your team owns afterward.
| Approach | When it fits | Upgrade exposure | Effort drivers and ownership |
|---|---|---|---|
| Starterkit custom theme | New sites where the design is owned by the project and the team wants a theme it fully controls | Low: the theme is generated from core's Starterkit and does not inherit markup from a core theme | Design build and Twig templates; your team owns every template, stylesheet and script in the theme |
| Subtheme of Olivero | Sites that want Olivero's look and accessibility baseline with light visual changes | High: every override depends on Olivero's Twig, library and class names, which change between core releases | Template overrides and CSS tweaks must be retested on each core update; your team owns the overrides and their regressions |
| Subtheme of Classy | Sites that need a minimal base with very little presentational markup of its own | Medium to high: Classy's markup and library structure can change, and each override inherits that drift | Most markup is written by the team anyway; your team owns the full visual layer and must track Classy changes it relies on |
| Component-based theme using Single-Directory Components | Multi-brand or multi-site estates that reuse patterns across Layout Builder, Canvas and Twig templates | Low to medium: exposure sits in components the team owns, plus the Drupal templates that call them | Upfront component library and props design; your team owns the component contracts, tokens and governance across sites |
What drives the effort of a custom theme build
A custom theme's cost follows from how much markup, behavior and rules it must cover, and who owns those rules after launch. The drivers below are the ones to scope in writing before a quote, because each one changes the template count, the test surface or the handover load.
Number of templates and content types
Every content type, view mode, Layout Builder section and Views display can need its own Twig template and CSS. Count them from the content model, not from the homepage mockup. The Starterkit generator gives you a base, but each distinct template still has to be built, reviewed and checked on every release. Ask the partner to list templates by name and to state which ones reuse a shared component.
Design system fidelity
A pixel-accurate match to a design file costs more than a close match built on shared tokens and components. Decide early whether the design system is an existing library you must follow or a set of mockups the theme interprets. Exact fidelity means more visual regression testing and more review cycles with designers, both paid during the build. Confirm who signs off each state, including hover, focus and error states.
Accessibility requirements
Accessibility is the driver most often underscoped. Keyboard navigation, focus order, color contrast, landmark regions and accessible forms all change markup and CSS, not only QA time. Specify the conformance target in writing, who runs the audit, and whether assistive technology testing is in scope. Accessibility fixes found after handover are usually billed as new work, so agree the target and test method before the build starts.
Multilingual and responsive needs
Each additional language adds right-to-left checks, longer strings that break layouts, and language switchers that need theme markup. Responsive behavior multiplies the same way: each breakpoint, navigation pattern and image set is another state to build and test. Ask for the list of languages, the supported device classes and the breakpoints. These are one-time build costs, but they also add recurring test effort at every update.
Number of sites sharing the theme
A theme used on one site is a single deployment. A theme shared across a multisite estate or several brands needs configurable tokens, a release process and version pinning, so a change for one brand does not break another. Shared themes cost more to design but cost less per site after that. Ask who maintains the shared code, how releases reach each site, and whether brand overrides live in configuration or in code.
Handover quality
A theme that the next team can change without the original builders is cheaper to run for years. Handover means documented component inventory, a style guide, automated tests, coding standards checks and a written list of known gaps. Missing documentation shifts cost to your team later, when a Drupal core release or a new designer request arrives. Ask for these artifacts as deliverables in the written scope, and confirm who keeps them current after launch.
Questions teams ask before building a custom Drupal theme
Does a Starterkit theme cost more up front than a subtheme?
Usually the first build costs somewhat more, because a Starterkit theme is a new theme with its own base styles, templates and build tooling rather than a thin layer over an existing core theme. The difference is in the initial design and component work, not in the generator itself, which is part of Drupal core. Subthemes look cheaper at the start because they inherit markup and styles, but the cost returns later when each upgrade requires you to inspect and fix inherited changes. Ask any quote to separate the one-time build from the recurring upgrade effort, and to state which parts of the theme are your own code.
What does the client need to provide for a custom theme project?
The work needs a finished or near-final design, including page layouts, components, typography, color tokens and responsive behavior, along with a list of the content types and views the theme must render. You also need to provide access to a development environment with the Drupal version you plan to run, the hosting target for staging, and a named person who can approve design decisions quickly. Accessibility requirements, supported browsers and any brand guidelines should be written down before the build starts. Missing design decisions are the most common reason theme work is extended.
Can an internal team build a Starterkit theme without outside help?
Yes, if the team has working knowledge of Twig templates, Drupal's theme layer, CSS and JavaScript build tooling, and the Drupal coding standards. The Starterkit generator gives a clean starting point, so the main skill gap is usually front-end architecture: component boundaries, library loading and keeping markup stable across upgrades. Teams without that experience often benefit from a short review of their structure before launch. Whichever route you choose, confirm who will maintain the theme after go-live, because a theme nobody owns becomes the largest source of upgrade debt on the site.
How long does a custom theme take, and what drives the duration?
No duration can be stated here without a written scope, so ask for a timeline tied to specific deliverables. The main drivers are the number of distinct page templates and components, the complexity of the design system, how many content types and views need custom output, accessibility remediation, and how many rounds of design review are planned. Integrations that change markup, such as search results or checkout pages, also add time. A fixed-scope agreement records these inputs so that changes to them are visible and priced.
Why does subtheming Olivero or Classy create upgrade debt?
Subthemes inherit templates, libraries and CSS from the parent theme, so every override is a dependency on that parent's internal structure. When core changes markup or class names in a later release, your overrides may stop matching, and the change appears as a visual or functional regression rather than a clear error. Classy is designed as a base for other themes, but relying on its templates still ties your code to details that core can change. A Starterkit theme keeps your markup and styles in your own code, so upgrades are limited to the Drupal APIs you call.
How does a custom theme affect readiness for Drupal 12?
Drupal 12 is scheduled for the week of December 7, 2026, and it requires PHP 8.5 or later, so a theme that depends on deprecated core behavior will need work before that upgrade. A Starterkit theme with its own templates and libraries is easier to check with Upgrade Status and to test, because the set of core dependencies is small and documented. Confirm the PHP version your hosting platform supports before planning the upgrade. Drupal 10 reaches end of life on December 9, 2026, so a theme project that also moves the site to Drupal 11 should be scheduled with that date in mind.
What should a theme cover in automated tests before launch?
Start with visual regression checks for the main templates and components, accessibility checks on key pages, and browser tests for navigation, forms and any interactive components. Theme code also benefits from linting for CSS and JavaScript and from a review against Drupal coding standards. Ask the team which pages count as critical and which browsers and breakpoints they support, since those choices determine how much test coverage is practical. Keep the test suite in version control so upgrades to Drupal and to build tooling can be verified before they reach production.
Security and operational considerations for theme code
A theme ships markup, CSS and JavaScript to every visitor, so its maintenance burden is a security burden too. The cards below cover the habits and checks that keep a Starterkit theme patched, escaped and upgradeable after launch.
Keep theme JavaScript current
Front-end libraries bundled into a theme, such as a carousel or date picker, are not updated by Drupal core releases. Record each library's version in the theme's package file and review its upstream advisories on the same cadence as core. Remove libraries that no component still calls, because unused code still expands the attack surface and the upgrade checklist.
Escape output in Twig templates
Twig auto-escapes output by default, but templates that use the raw filter or build markup in preprocess functions can bypass that protection. Search custom templates for raw and for attributes assembled from user-entered fields, and confirm that link URLs pass through a safe conversion. Ask the reviewer to flag every bypass with a written reason.
Pin dependencies with Composer
Theme build tools such as the compiler, linter and bundler should be declared in the project and locked with a committed lock file, so every environment builds the same output. Run the audit command for both Composer and npm packages in the build pipeline and fail the build on known high-severity findings. Confirm which team owns approving major tool upgrades.
Apply advisories that touch theme code
The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and fixes ship in scheduled security release windows. Not every advisory affects a theme, so the team must check whether each one names a module, library or template your theme depends on. Agree a response time for applying security releases and document who signs off the emergency change.
Build a repeatable release pipeline
Compiled assets should be produced by the pipeline from source, not edited by hand on a server, so a rebuild reproduces the exact release. Store the built output as an artifact tied to a commit, and keep the asset version in cache-busting filenames. Confirm that rollback restores both code and assets together, since a mismatch breaks styling without any error.
Check theme changes against core updates
Core bugfix releases arrive on a fixed monthly schedule, and new major versions arrive roughly every three years, so each update can change the Twig templates and libraries your theme overrides. Run visual regression and accessibility tests on the staging site after every core update, before production. Ask your partner to show which overrides were checked in the last update cycle.
What changes when a Drupal 7 theme moves forward
Drupal.org documentation is explicit that themes cannot be migrated from Drupal 6 or 7 to a current version. The content and configuration move through the core Migrate, Migrate Drupal and Migrate Drupal UI modules or through Drush, but the theme has to be rebuilt. For most teams that makes a Starterkit build the practical path: generate a new theme with the core generator, then port the Drupal 7 markup, CSS and JavaScript into Twig templates, libraries and components that the current theme system understands. Treat the Drupal 7 theme as a specification for the visual result and the behavior, not as code to carry forward. Before estimating effort, inventory the templates, preprocess functions, JavaScript behaviors and CSS overrides the old theme depends on, because that inventory drives the rebuild far more than the page count does.
The rebuild and the content migration run in parallel and must meet at a known point. Migrated content arrives with the field structure from the old site, so the new templates have to be written against the migrated data, not the design mockups alone. Agree early which content types, view modes and fields the theme will render, and run a staging build against a partial migration to catch mismatches in image styles, text formats and taxonomy references while the migration is still changing. Confirm with your migration partner which Drupal 7 fields map to which target fields, since a theme cannot render data that the migration has not placed in a predictable structure. The Drupal 7 security support ended on January 5, 2025, according to Drupal.org, so sites that have not yet migrated are running without core security releases. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for that situation. Use an extended support provider only as a bridge while the migration and theme rebuild are scheduled, and ask any provider for the scope, the advisories it covers and its exit terms in writing. It does not replace the rebuild.
How DeployOpen scopes and delivers a custom Drupal theme
DeployOpen plans a custom Drupal theme from a written scope, generates it from the core Starterkit so it does not depend on a core theme's internals, and hands over the code, documentation and a path for ongoing maintenance. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope lists the components, breakpoints, templates and content types the theme must cover.
- We confirm which Drupal version and PHP version the theme targets before any code is generated.
- The scope names the design source, such as tokens or mockups, and who signs off each stage.
How we build
- We generate the theme from Starterkit and keep base-theme overrides to a documented minimum.
- Templates, CSS and JavaScript are built as components, with each one covered by a review and test step.
- Accessibility checks and browser tests run against the agreed critical pages before each handover milestone.
How we hand over
- The handover includes the theme repository, a build guide and a list of every template override with its reason.
- We document the Drupal core upgrade checks to run against the theme before each core release.
- Your team receives a walkthrough of the component library and the review checklist used during the build.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover theme updates that follow Drupal core releases and changes to contributed modules.
- Support scope, response expectations and fees are agreed in writing, and a quote follows from that scope.
