Looks like you're in . Want the local site?
Ignited Nepal builds custom WordPress themes for Canadian organisations that have outgrown templates and need a codebase they can maintain and extend. Design token systems, Gutenberg block libraries, ACF field groups, SCSS architecture, and performance-first builds tested on WP Engine Flywheel, Kinsta, and SpinupWP, handed over with editorial documentation your content team will actually use.
You chose a premium theme at launch and it worked until it did not. Your content team is working around blocks that were never quite right for your layouts, your developers are spending more time fighting the theme than building features, and your performance scores are weighed down by scripts and stylesheets for functionality you disabled two years ago. You need a theme built around what you actually need, not a theme shop's full feature list.
You have updated brand guidelines: new colours, new typefaces, possibly a new logo and visual system. Applying a rebrand to a premium theme with no token system means tracking down and overriding styles in dozens of places. A theme built on a design token system makes a rebrand a configuration change, not a development project.
You publish in French and English for a Canadian audience and your current WordPress installation handles bilingual content with a combination of plugins, workarounds, and editorial conventions that are fragile and poorly documented. You need a theme and content architecture built for bilingual publishing from the foundation, not bolted on after the fact.
Premium WordPress themes were not all rebuilt around Gutenberg when the block editor launched. The result is a block inserter full of blocks that do not fit your grid, previews that do not match the front-end, and editors who have reverted to the Classic Editor or to a page builder because the native block experience is unreliable. A theme built Gutenberg-first from the start behaves consistently because it was designed to.
A Canadian organisation publishing in both French and English faces a structural question: how are the two language versions related in the content model, how do URLs behave, and how does the editorial workflow handle translation and publication timing? Most bilingual WordPress sites answer these questions inconsistently, through a mix of plugin settings and undocumented conventions, which creates technical debt and editorial confusion.
Premium themes load for all the features they offer, not for the features you use. Unused JavaScript for sliders you removed, stylesheets for colour scheme options you never chose, and font files for weights you never applied all contribute to a slower site. The performance cost is structural and it compounds with every plugin you add on top.
If updating your primary colour, your heading font, or your button style requires a developer to find and modify styles across multiple files, your theme has no token system. The risk of inconsistency, of missing one occurrence, is real, and the cost in developer time is recurring every time your brand evolves.
We build a design token layer in SCSS and CSS custom properties that captures your complete visual language: colour palette, typography scale, spacing system, border radii, and shadow levels. Every component references these tokens. Your brand is defined in one place and applied consistently everywhere.
We build a custom block library specific to your site's content patterns. Each block is designed to match your brand, produces predictable output at every viewport size, and is scoped so editors cannot produce layouts that break your design. The library replaces the core blocks that were not working and supplements the ones that were.
We build pre-composed block patterns: full page sections assembled from your custom blocks that editors can insert and populate without making layout decisions. Hero sections, testimonial rows, feature grids, call-to-action panels, and content-media pairs are all available as single-click insertions with your brand already applied.
We integrate Advanced Custom Fields for structured editorial control over content that does not fit naturally into the block editor: SEO field overrides, hero configuration options, related content selections, bilingual metadata, and any page-level data your templates require. Every ACF field is documented so editors understand its purpose without asking a developer.
For organisations publishing in both official languages, we design and implement the content architecture that makes bilingual publishing work cleanly. This includes the approach to post translations or parallel content fields, URL structure for both languages, language switcher implementation, and editorial documentation covering how to publish, update, and maintain bilingual content correctly.
We build the theme's stylesheet as a modular, well-documented SCSS codebase: partials for tokens, base styles, layout, components, and utilities, with a consistent naming convention. Any WordPress developer hired after handover can navigate and extend the codebase without a lengthy onboarding period.
We optimise every asset the theme loads: fonts with font-display: swap and correct preloading, no unused JavaScript, CSS scoped per component, images in modern formats with srcset attributes, and Core Web Vitals verified on WP Engine Flywheel, Kinsta, or SpinupWP before handover.
We build to WCAG 2.1 AA. Semantic heading hierarchy, aria labels on interactive elements, keyboard-navigable components, sufficient colour contrast across all token combinations, visible focus states, and correct lang attributes for bilingual content. Accessibility is built into the HTML structure from the start.
We hand over on Git with a clean commit history, a developer README covering the token system, block library, and deployment process, and editorial documentation written for your content team. For bilingual organisations, documentation covers the bilingual publishing workflow specifically.
We review your current site, brand guidelines, content team workflows, bilingual requirements if applicable, and hosting environment on WP Engine Flywheel, Kinsta, or SpinupWP. We audit your existing theme for the structural issues that need solving and produce a development brief for your sign-off before any work begins.
We define your design token system, design the component set for your block library, and specify your bilingual content architecture if relevant. You review and approve before development begins. This is the stage where changes cost a conversation. After development starts, changes cost a sprint.
We build the theme: SCSS architecture, custom Gutenberg blocks, block patterns, ACF field groups, bilingual content implementation, templates, and performance optimisation. All development happens in a staging environment so your live site is never affected.
We test every block, pattern, ACF field, and template across Chrome, Firefox, Safari, and Edge on desktop and mobile. We run Core Web Vitals audits, WCAG 2.1 AA checks, and, for bilingual sites, verify that French and English content renders correctly and that language switching functions as expected.
We deploy to production, hand over the theme on Git with a full README, and deliver editorial documentation. For bilingual organisations, editorial documentation covers the French and English publishing workflow in detail. We are available for two weeks post-launch for questions that arise in real use.
The right approach depends on whether your French and English content is always a direct translation of the same post, or whether the two languages sometimes carry different content, different publication dates, or different structures. Translation plugin approaches such as WPML or Polylang work well for direct translations. For organisations where bilingual content is more complex, a custom field approach using ACF parallel fields or a custom post type architecture may be more appropriate. We make a recommendation at the discovery step based on your editorial workflow.
We work with your existing host. For Canadian organisations where data residency matters, WP Engine's Flywheel infrastructure includes Canadian data centre options, and Kinsta has infrastructure in Montréal. SpinupWP with a DigitalOcean Toronto droplet is a cost-effective option for lower-traffic sites. We advise on hosting if you are open to changing or if your current host is affecting performance.
A design token system adds a small amount of upfront structure to the SCSS architecture and takes perhaps half a day longer to set up than a theme with hard-coded values. The investment pays back the first time your brand updates, the first time a new developer joins the project, and every day your editors rely on the theme producing consistent brand output without manual oversight.
A typical custom theme build from discovery to handover takes eight to twelve weeks. Sites with smaller block libraries and no bilingual requirements come in at the shorter end. Sites with large block libraries, complex ACF integrations, bilingual content architecture, or multiple custom post types take longer. We give you a firm timeline at the end of the discovery step, after we understand the full scope.
The development conventions and file structure are documented in the handover README. A competent WordPress developer can follow the conventions to add new blocks that fit naturally into the existing system. If you would prefer us to build additional blocks post-launch, we offer support and retainer arrangements. The codebase is yours and is written to be extended.
If your editors are fighting your theme, your performance scores are holding back your search rankings, or your bilingual publishing workflow is fragile and undocumented, the foundation needs rebuilding. We build it correctly from the start. Send us your brief.