Looks like you're in . Want the local site?
Ignited Nepal builds custom WordPress themes for UK businesses that have outgrown templates and need a codebase they can actually maintain. Design tokens, Gutenberg block libraries, ACF field groups, and SCSS architecture built from scratch, tested on WP Engine UK, Kinsta, and SpinupWP, and handed over with editorial documentation your content team will use.
You launched on a premium theme and it served you well for a few years. Now your content team is hacking around blocks that do not quite match your brand, your developers are fighting the theme's opinionated CSS, and your page speed scores are suffering under the weight of features you never use. You need a theme built around your actual requirements, not around a theme shop's assumptions.
You have new brand guidelines, a new colour system, new typography, and possibly a new logo. Applying a rebrand to an off-the-shelf theme means overriding styles in a dozen places and hoping nothing breaks. A theme built on a design token system means a rebrand is a configuration change, not a development project.
Your editors depend on developers to make layout changes that should be editorial decisions. They cannot create a new page type without submitting a ticket, cannot adjust a hero layout without breaking something, and are using the Classic Editor because the Gutenberg experience in your current theme is unreliable. A well-built block library gives them control without giving them enough rope to break the design.
Most sites that started on a premium theme end up with a functions.php file full of workarounds, a child theme that fights the parent on every update, and a stylesheet that requires a developer to decipher. This is not a content problem or a design problem. It is a foundation problem.
Off-the-shelf themes were not all built with Gutenberg as a first-class editing experience. The block inserter shows blocks that break your layout. Full-width patterns do not align with your grid. Block editor previews do not match the front-end. Editors have learned to avoid certain blocks entirely because the results are unpredictable.
Premium themes often bundle scripts, fonts, and stylesheets for features you do not use. A theme that loads five JavaScript files to power a slider you removed two years ago is a performance liability. Every unnecessary asset has a Core Web Vitals cost and a real-world effect on mobile load times and search ranking.
If changing your primary colour, updating a font, or adjusting button radius requires a developer to locate and update styles in multiple files, your theme has no token system. A design token system means brand changes are made in one place and propagate correctly across every component.
We build a design token layer that defines your colour palette, typography scale, spacing system, border radii, and shadow levels as named variables in SCSS and CSS custom properties. Every component in the theme references these tokens. A brand update changes the tokens. Nothing else needs touching.
We build a library of custom Gutenberg blocks specific to your site's content patterns. Each block is designed for your brand, coded to produce predictable output, and scoped so editors cannot accidentally break the layout. The block library replaces the core blocks that were not working for your team and supplements the ones that were.
We build a set of pre-composed block patterns, full sections assembled from your custom blocks, that editors can insert and populate without making layout decisions. Common page sections, call-to-action rows, testimonial layouts, feature grids, and content-media pairs are all available as one-click insertions with your brand applied.
We integrate Advanced Custom Fields to give editors structured control over page-level data that is not well-suited to block content: SEO overrides, hero background options, sidebar configurations, related content selections, and any custom data your templates require. ACF fields are documented so editors understand what each field does without needing to ask a developer.
We build the theme's stylesheet as a well-organised SCSS codebase: partials for tokens, base styles, layout, components, and utilities, with a clear naming convention. Any developer who joins your team after handover will be able to navigate and extend the stylesheet without a lengthy onboarding.
We audit and optimise every asset loaded by the theme: fonts loaded with font-display: swap and preloaded correctly, no unused JavaScript, CSS scoped to the components that need it, images using modern formats with appropriate srcset attributes, and Core Web Vitals verified on WP Engine UK, Kinsta, or SpinupWP before handover.
We build to WCAG 2.1 AA. Semantic heading structure, aria labels on interactive elements, keyboard-navigable components, sufficient colour contrast across all token combinations, and focus states that are visible and styled. Accessibility is built into the HTML structure, not retrofitted as a plugin.
We test on Chrome, Firefox, Safari, and Edge on both desktop and mobile. We test on real iOS and Android devices alongside emulators. We document and fix any layout or functionality issues before handover.
We hand over the theme on Git with a clean commit history, a README covering the token system, block library, and deployment process, and editorial documentation written for your content team. The editorial documentation covers how to use every custom block and pattern, what each ACF field does, and how to add new pages correctly. It is written for editors, not developers.
We review your current site, your brand guidelines, your content team's workflows, and your hosting environment. We audit your existing theme for the issues that need solving and identify the custom blocks, ACF field groups, and patterns your content requires. We produce a development brief for your approval before work begins.
We define your design token system, translate your brand guidelines into SCSS variables and CSS custom properties, and design the component set that will form your block library. You review and approve the component designs before development begins. Changes at this stage cost an hour. Changes after development begins cost a sprint.
We build the theme: SCSS architecture, custom blocks, block patterns, ACF field groups, templates, and performance optimisation. We develop against your staging environment on WP Engine UK, Kinsta, or SpinupWP so your live site is never disrupted.
We test every block, every pattern, every ACF field, every template, and every interactive component across Chrome, Firefox, Safari, and Edge on desktop and mobile. We run Core Web Vitals audits and WCAG 2.1 AA checks. We fix issues before handover, not after.
We deploy to your production environment, hand over the theme on Git with a full README, and deliver editorial documentation for your content team. We are available for two weeks after launch to answer questions and address anything that surfaces in real editorial use.
A design token system stores every brand value, colour, typeface, spacing unit, and border radius as a named variable at the top of the SCSS codebase. Every component references those variables rather than hard-coding values. When your brand updates, you change the variables once and every component inherits the change. Without tokens, a rebrand requires finding and updating styles across dozens of files, which introduces errors and takes significantly longer.
Core WordPress blocks are general-purpose. They are not designed around your grid, your brand, or your content patterns. Our custom blocks are built specifically for the content types your site uses: your hero layouts, your case study structures, your feature grids, your testimonial formats. They produce predictable output, match your brand automatically via the token system, and are scoped so editors cannot produce layouts that break your design.
We develop and test against your existing hosting environment. For UK WordPress sites, we have direct experience with WP Engine UK, Kinsta, and SpinupWP and can advise on which is best suited to your traffic profile and team workflow if you are moving hosts as part of the project. We do not require you to change hosts.
A typical custom theme build from approved brief to handover takes eight to twelve weeks. Simpler sites with fewer custom block types and no complex ACF integrations come in at the shorter end. Sites with large block libraries, multiple custom post types, or complex editorial workflows take longer. We give you a realistic timeline at the end of the discovery step, after we understand the full scope.
The SCSS architecture and block development conventions are documented in the handover README. A competent WordPress developer can follow the conventions to add new blocks that match the existing system. If you would rather have us build additional blocks, we can do so under a support or retainer arrangement. The codebase is yours and it is written to be extended.
If your editors need developer support for tasks that should take ten minutes, or your performance scores are dragging down your search rankings, the foundation is the problem. We rebuild it correctly. Start by sending us your brief.