Interview with Alan Carr, Creative Director, Webpop Design

This interview is with Alan Carr, Creative Director, Webpop Design.

Alan, as a Creative Director in the internet industry, how do you introduce your specialty in custom WordPress builds and the kinds of unique, business-critical sites you’re known for?

The industry is saturated with slow WordPress sites bogged down by bloated page builders and heavy plugin dependencies. At Webpop Design, we take a completely bespoke approach. We use WordPress exactly as it was intended: a lightweight, scalable foundation that isn’t reliant on third-party tools to function.

By hand-coding custom themes from scratch with minimal plugin reliance, we map the entire build directly to a client’s specific business goals. Whether the objective is driving phone calls, increasing form submissions, or scaling product sales, we deliver a fast, high-performance platform built specifically to convert, rather than forcing a business into a pre-made template.

What path brought you into leading bespoke website projects, and which early project most shaped your approach to web innovation?

Early in my career, after completing various design and development certifications, I began inheriting existing WordPress sites from new clients. These builds were often heavily bloated with plugins and failed to use the CMS efficiently. Beyond the technical mess, almost every client shared the same frustrations about previous developers: they were unreachable, missed deadlines, and failed to deliver the promised functionality.

I saw a clear gap in the market for an agency that actually delivered on its word. Being highly thorough is second nature to me, and I instilled that exact trait into our core process for bespoke web design. The early realization that clients were desperate for both clean code and professional communication drove me to focus strictly on custom builds, ensuring we deliver exactly what we promise.

When a client asks for a “unique website,” how do you turn that into a measurable brief—especially around content hierarchy, navigation logic, and UX priorities—before any design starts?

When a client asks for a unique website, we focus entirely on the user journey. During our initial discovery call, we define exactly what the site needs to achieve, mapping out the content hierarchy and navigation logic to support specific business goals rather than just focusing on aesthetics.

We then put together a detailed brief and technical specification alongside our initial proposal. This document defines every single page template, UX requirement, and piece of functionality down to the last detail. We hold a final sign-off call on this specification before any design work begins, ensuring the project scope is completely measurable and understood by everyone involved.

What decision framework do you use to choose between WordPress and headless WordPress for a build?

Our decision framework strictly comes down to how the frontend data needs to be distributed. For the vast majority of our projects, a highly optimized, standard WordPress setup is the best choice. Because we hand-code our themes from scratch and keep plugin dependency incredibly low, a traditional architecture delivers exceptional speed and performance without introducing unnecessary technical overhead.

We only recommend a headless WordPress architecture when the project requires a decoupled system. If the client needs the WordPress CMS strictly as a backend to feed an API, such as pushing content to a separate web app or multiple distinct frontends simultaneously, headless makes perfect sense. For everything else, a unified, bespoke WordPress build is far more efficient for both the budget and the project timeline.

As a Creative Director, how do you coach designers and developers to treat the site as a business tool from day one?

I ensure my designers and developers understand that their technical and creative choices have a direct impact on the client’s bottom line. We move away from the idea of just building a website and focus on building a solution. If a developer knows a site is primarily a lead generation tool, they will naturally prioritize page speed and core web vitals over bloated features that might slow down the conversion process.

By keeping the team focused on the project’s KPIs, we avoid the common issue of over-engineering the backend or overcomplicating the UI. Every element of the build is treated as a functional component of a larger business strategy. This approach ensures that when we hand over the final product, it is a high-performance tool ready to drive the results the client actually paid for, rather than just a digital replica of a design file.

For WooCommerce or WordPress-based e-commerce, what is one practical way you’ve used native behavioral data to personalize the experience without heavy martech?

We avoid heavy marketing technology by leveraging the native data WooCommerce already collects within its own database. One practical method involves using custom PHP functions to monitor a user’s cart or browsing history in real time to trigger features like “frequently bought together” sections or tailored shipping messages.

By using simple conditional logic within the theme rather than external apps, we personalize the journey for returning customers or first-time visitors based on their actual intent. This strategy is a key element of our WooCommerce development service, as it creates a high-end shopping experience while keeping the technical architecture lean and the site performance high.

On innovation, what small, low-risk experiment do you run on most builds to push the work forward while protecting timelines and budgets?

One low-risk experiment we run on most builds is the granular optimization of the critical CSS path and script loading order. Instead of introducing heavy new technologies that could stall a project, we test how specific asset-loading sequences impact page speed on a per-template basis. This allows us to shave milliseconds off the initial load time and improve Core Web Vitals without risking the project timeline or overcomplicating the codebase.

This approach works because it is focused on performance refinement rather than broad architectural changes. We measure the impact of these small adjustments in a staging environment and only implement the most effective versions. It ensures we are constantly pushing the boundaries of what a fast WordPress site can do while maintaining the stability and budget security our clients expect.

After launch, what metrics and weekly rituals do you track in the first 90 days to connect the custom build to real business outcomes?

During the first 90 days, we focus heavily on real-world performance through Core Web Vitals and Google Search Console. We need to confirm that the site maintains its speed benchmarks under actual traffic and that the new architecture is being indexed properly. This weekly ritual allows us to catch any technical anomalies early and ensures the lean codebase is providing the SEO advantage we promised.

We also track the specific conversion KPIs defined in the original brief, such as lead generation or sales volume. By reviewing user behavior through heatmaps and session recordings, we can verify if the navigation logic is working as intended. If we spot a drop-off point, we make iterative UX refinements to keep the conversion rate high. This process connects the technical build directly to the client’s bottom line, proving the site’s value as a commercial tool.

Thanks for sharing your knowledge and expertise. Is there anything else you’d like to add?