10 Questions to Ask Your Web Designer Before You Hire

Before you sign anything, ask a web designer how they will use WordPress’s core architecture, not just how the homepage will look. The prettiest launch in the world can still be a scalability prison in 12 to 18 months, and right now the most common way that happens is an AI-assisted, template-per-page WordPress build that ships fast and locks you out of ever changing it cheaply.

Every design and development firm is using AI now. That part is settled. We use it too, for mapping out custom features, planning integrations into an existing architecture, checking security and compliance edge cases, and a dozen smaller tasks. The tool is fine. The problem is how it is being pointed at WordPress.

I have been building websites in Charlotte since 1998, and as a development firm that also integrates and maintains sites other people built, we get a front-row seat to the aftermath. Lately the aftermath has a signature. We are rebuilding a site right now that was crafted end to end by AI. The client is asking for basic features. Those basic features cannot be added in the simple way because the templating never accounted for how WordPress actually works. Something that should take 30 minutes to an hour is now days, because we have to rebuild the underlying systems first.

This article is the vetting conversation I wish that client had before they hired anyone.

Why an AI-built WordPress site can look perfect and still trap you

An AI-built WordPress site traps you because AI is very good at producing something that looks finished and very bad, on its own, at producing something that is structured to grow. Those are different jobs.

Here is the pattern we keep finding. A designer opens Claude, Figma, or whatever they favor, and generates a full theme with a bespoke template tied to each individual page. Home has its own template. About has its own template. Services has its own template. Every page is its own snowflake. On launch day it demos beautifully. The client is happy. The designer is happy. Everyone moves on.

Then the client wants to add a new service page that behaves like the existing ones. Or a filterable list of case studies. Or a team directory. Or a second location. In a properly built WordPress site, those are routine. In the AI-templated build, each one is a custom rebuild, because there is no shared system underneath. There are only individual templates that happen to look related.

Worse, the sections tend to be strongly interdependent. AI-generated layouts frequently wire sections to each other in ways that seem efficient and are actually brittle. You try to remove one section and something three sections away breaks. You try to add a block and the spacing logic collapses. The site does not welcome change. It resists it.

Practical rule: If adding a page that resembles an existing page requires a developer to rebuild anything, the site was not built to scale. It was built to launch.

The real difference: a design system versus a stack of locked templates

The difference between a firm that scales your site and a firm that boxes you in is whether they build a design system or a pile of templates. This is the single most important thing to understand before you hire anyone, so name it out loud in the meeting.

A basic designer uses AI to template the entire website, confirms the design looks good, and stops there. That is the whole job to them. A good development firm uses AI differently. They use it to generate mockups and rough layouts, then transpose those into a real WordPress content management system: custom post types for the things you have many of, custom fields for the structured content inside them, and reusable templates driven by the WordPress template hierarchy. The mockup is the starting point. Not the deliverable.

WordPress powers a large share of the web precisely because that architecture is flexible. Custom post types and custom fields let you model your actual business, then edit content without a developer and add new items forever. Bypass those systems and you throw away the exact reason to use WordPress at all. You are left with a static-looking site running on a dynamic platform, getting the downsides of both.

Design system vs template-per-page: how the two builds behave over time

Notice the through-line. Every good-firm answer starts from how WordPress is designed to work. Every bad-firm answer starts from what was fastest to generate. AI does not cause this. A shallow understanding of WordPress does, and AI just makes shallow understanding faster to ship.

The 10 questions to ask your web designer before you hire them

These are the 10 questions to ask your web designer or developer before the contract is signed. You do not need to be technical to ask them or to judge the answers. A firm that builds to scale will answer plainly and welcome the questions. A firm that builds to launch will get vague, defensive, or try to redirect you back to how nice the mockups look.

1. Will you use custom post types for repeatable content, or a separate page for each item? If you have services, locations, staff, products, events, or case studies, the correct answer names custom post types. “We’ll build a page for each” is the answer that costs you later.
2. How will I add a new page or item that matches the existing ones without a developer? A scalable build lets a non-developer add another team member or service from the WordPress dashboard. If the answer is “just call us,” you are renting access to your own content.
3. Are you building a reusable design system, or a template per page? Ask it in those words. You want reusable templates and shared components driven by the template hierarchy, not one locked template welded to each URL.
4. If I ask you to remove or reorder a section later, what breaks? The right answer is “nothing, sections are independent.” Hesitation here reveals the interdependency trap where one change cascades into three others.
5. How exactly are you using AI in this build? You want to hear “for mockups, layout ideas, and planning that we then implement properly in WordPress.” Be wary of “AI builds the theme and templates.” That is the difference between a tool and a shortcut.
6. Who owns the code, and can another firm maintain it? A healthy build follows WordPress conventions so any competent WordPress developer can pick it up. If only the original AI prompt author can maintain it, you are locked in by design.
7. What is your plan for updates, plugins, and security over time? WordPress needs ongoing care. Ask how core, theme, and plugin updates will be handled, and how custom code will survive them. Vague answers here become emergencies later.
8. Show me a site you built two or three years ago that the client has since expanded. Anyone can show a fresh launch. Longevity under change is the proof. Ask specifically what the client added after handoff and how hard it was.
9. If I want a new feature next year, what does that process look like? Listen for whether new features slot into an existing structure or require rebuilding. “It depends on what you want” is fine. “We’d have to redo the templates” is a red flag.
10. Are you writing custom plugins and code with a long-term maintenance plan, or bolting on quick fixes? AI makes it easy to generate a quick plugin or a JavaScript patch. Without deeper knowledge, those quick fixes become the problems you pay to remove later.

Practical rule: You are not hiring a firm to make one beautiful thing. You are hiring the structure every future change will run through. Vet the structure, not the screenshot.

What the answers should sound like

You will not always follow the technical detail, and that is fine. Judge the shape of the answer, not the vocabulary.

Good answers are concrete and unhurried. The firm explains that repeatable content becomes a custom post type, that you will be able to add items yourself, that sections are modular, and that AI helped them design faster but did not build the foundation. They are comfortable saying “here is what that would take” instead of dodging.

Bad answers keep steering back to aesthetics. Ask about scalability and you hear about how modern the design looks. Ask who can maintain it and you hear “don’t worry about that.” Ask what breaks when you change a section and you get a pause. That pause is the whole answer.

One more tell. A firm that respects WordPress will happily talk about the platform’s own capabilities. A firm that quietly bypassed them will talk about their process and their tools and almost never about how WordPress is structured. When our own WordPress development team scopes a build, the structure comes first and the visuals get layered onto it, because rearranging visuals is cheap and rearranging structure is not.

Is it ever fine to let AI build the whole site?

Yes, in a narrow case. If it is not a WordPress site and it is a small three or four page brochure site whose content rarely changes, let AI stand it up and get it live. With a little templating you can even run a tidy blog off Markdown or JSON files. For that scope, speed is the right priority and there is almost nothing to scale.

That is not most business websites. If you are building something meant to grow, add sections, gain features, and support the business for years, the calculus flips. AI should be a tool you build off of, not the thing you build from. Used with caution and a real understanding of WordPress, it accelerates good work. Used to skip the understanding, it just defers the cost. You launch faster and pay it all back with interest, in future time and future money, when the first real change request arrives.

My one solid opinion, said plainly. Most agencies are using AI on WordPress incorrectly. They generate entire themes with templates tied to pages instead of building a design system, and they hand clients a locked box with no flexibility. AI is a genuinely great tool. Without a sound foundation in how WordPress works, it just produces a faster headache.

The security angle nobody mentions in the sales meeting

Scalability is not the only risk in an AI-built site. Security is the quiet one. When someone generates code they do not fully understand and ships it, they cannot properly review it either. That gap is now a named industry concern. The practice of shipping AI-generated code without deep review has a name, “vibe coding,” and it is being flagged as a real software risk heading into 2026.

On WordPress specifically this shows up as custom plugins or snippets that sanitize input poorly, expose data, or conflict with the platform’s own update cycle. The features work in the demo. The vulnerabilities surface later. So add a security question to your list. Ask how AI-generated code gets reviewed before it goes live, and by whom. “Our senior developer reviews everything AI produces” is a good answer. Silence is not.

If you already own a site you suspect was built this way, the fix is not to panic and start deleting things. It is to get a structured assessment first. A second opinion audit or an ongoing maintenance relationship will tell you what is salvageable and what has to be rebuilt, before you spend money in the wrong order.

What a scalable WordPress build actually gives you

A scalable WordPress build gives you a site you can change without begging a developer for the small stuff and without a rebuild for the big stuff. That is the entire point, and it is the thing the AI-templated shortcut quietly takes away.

Concretely, a well-built site lets you add a new service, location, or team member from the dashboard in minutes. It lets a developer add a real feature, like a filterable directory or a members area, by extending the existing structure instead of tearing it apart. It survives platform updates. And when you eventually work with a different firm, they can read the code, because it follows WordPress conventions instead of one AI session’s improvisation.

The uncomfortable truth is that the scalable build is the harder one to sell. Its value does not show up on launch day. It shows up 18 months later when a competitor’s site is stuck and yours is not. That is exactly why the cheapest moment to protect it is now, in the vetting conversation, before anyone writes a line of code.

Short version

Ask the 10 questions before you hire. Listen for whether the firm builds a WordPress design system or a stack of locked templates. Reward concrete answers about custom post types, custom fields, modular sections, code ownership, and how AI-generated code gets reviewed. Walk away from anyone who keeps redirecting you to how the mockups look.