Who Is Actually Building Your Website?

Here's a detail that's easy to miss when you hire a web designer: the person who impresses you on the sales call and the person who writes your site's code are, in many shops, different people. Sometimes wildly different — different buildings, different time zones, occasionally different companies that your designer has never met in person.

Outsourcing is not inherently a problem. The problem is finding out about it after something goes wrong. One of the most-cited first-person accounts of a failed web project describes exactly this discovery: a client who paid for a fully custom build, hit problems in development, and only then learned the development had been subcontracted to an outside party who lacked the experience the project needed. The author's own conclusion is the fair one — outsourcing is common and sometimes fine; the failure was never being told.

This piece is about the questions that make sure you're never that client.

Why the question matters more than people think

The web design industry has a sales layer and a build layer, and the distance between them varies enormously:

All four can produce a good website. But they fail differently, and the support you get after launch differs enormously. When the site has a problem in year two, do you call the person who understands your build, or a ticket queue belonging to a company that has since changed developers?

We've written before that quotes under roughly $1,200 in this market are almost certainly template work or outsourced to someone who may not be there in six months. But price only tells you the floor. The disclosure question applies at every price point.

The questions to ask — and the answers that should satisfy

"Who does the design, who writes the code, and are they your employees?"

A straight answer sounds like: "I do the design and build; I subcontract the copywriting to a writer I've worked with for years." That's disclosure. A deflecting answer sounds like: "We have a network of talented professionals." That's not disclosure — that's a fog machine.

"Who answers when something breaks after launch?"

This is the question that matters most over the long run. Your site will need changes, and something will eventually misbehave. Is the person who knows the code reachable, or does support route through an account manager who forwards tickets? The pricing page you're quoted from should tell you the support structure — who responds, on what channel, in what window. If it doesn't, the answer is a ticket queue.

"Have you built for my industry before — you, or your subcontractor?"

Industry experience matters in web design more than most trades, because the difference between a generic site and a good one is almost always domain knowledge — knowing that contractors need photo-heavy galleries and service-area pages, that restaurants need commission-free ordering options, that lodgers need calendar sync. If the experience lives with a subcontractor who's on to their next project by the time you need a change, the experience isn't really yours.

"What work stays in-house, and what goes out?"

Copywriting, photography, illustration, and specialized integrations are commonly subcontracted — legitimately, and often to people better at those things than any generalist. The pattern you're looking for is honesty about the seams. "I write the code; the logo is a specialist I bring in" is a normal, healthy answer. What you don't want to discover is that the core of the work — the design and development you're paying for — is the part being resold.

What full disclosure looks like

A shop that's upfront about its structure will tell you, without being asked twice:

That last one sounds paranoid until you've been the client whose project is hostage to a single subcontractor's availability. One-person shops should have an honest answer ready — a network of peers, a documented codebase, a plan. We're a single-operator studio ourselves, and we consider that question entirely fair; the maximum-three-concurrent-builds limit and the "you talk to the person writing the code" arrangement exist precisely because we think clients should be able to see the hands on their project.

The red flags

The discovery after the fact. If you learn that development was outsourced from a third party — a comment in a meeting, a developer's name you've never heard in an email — the problem isn't the outsourcing. It's that your contract priced a service you weren't actually buying. See contract red flags for the terms that make this discovery survivable.

The portfolio of other people's work. Some sales-layer shops display work their subcontractors did for other clients, or template demos. If a portfolio piece interests you, ask who built it and whether that person will touch your project.

Support that can't name a person. "Our team will handle it" with no names, ever, in six months of working together, means nobody in particular is accountable. The single-operator alternative has its own risks, but you always know exactly whose reputation is on your site.

The vanishing subcontractor. The classic outsourcing failure: the work is fine, the relationship ends, and the designer can no longer help because the developer who understood it moved on. The protection is the same as always — own your domain, hosting, and code, and get the launch handoff that makes you independent of any individual.

Before you sign

Add one line to your vetting conversation: "Walk me through exactly who touches this project from today to launch." Ninety seconds of answer. The designers worth hiring answer it easily, because they've organized their business around the answer. The ones who can't are hoping you won't ask.

Questions about how we structure builds? You'll talk to the person who writes the code — that's the design of the business. We answer every enquiry personally, within one business day.