Choose by the problem that must be solved and the evidence the provider can show—not by the title on a profile. A designer should lead when the central risk is whether people can understand, trust, and use the website. A developer or other implementation specialist is essential when the central risk is custom behavior, data, integrations, reliability, performance, or an application that has to work beyond ordinary page publishing. Many projects need accountable coverage of both.

The labels are loose in the market. One person may do both kinds of work; an agency may split them across several people; a “web designer” may write production code; a “developer” may be excellent at interface decisions. The U.S. Bureau of Labor Statistics makes a useful high-level distinction: web developers create and maintain websites and handle technical aspects, while digital designers develop and test layout, functions, and navigation for usability. Treat that as a vocabulary aid, not a hiring rule.

The buyer decision is simpler: what could make this project fail, and who has the demonstrated responsibility to prevent that failure?

The role-to-problem decision matrix

Use the matrix to name the primary coverage a project needs. “Primary” does not mean the other role is irrelevant; it means the risk that should not be left implicit in a proposal.

Named project problem Primary coverage to require What a designer should be able to own What implementation or development capability should be able to own Evidence to request before hiring
Visitors cannot tell what the business does, whether it fits, or what to do next. Design leadership Message hierarchy, page structure, proof placement, navigation, readable calls to action, and mobile states. Build the approved structure faithfully on the chosen platform. A before-and-after explanation of the buyer problem, representative page work, and the reason for the chosen path.
Existing copy is accurate but hard to scan or use on a phone. Design leadership Content hierarchy, responsive layouts, interaction states, labels, and navigation that support the task. The responsive behavior and semantic structure needed to make those choices work. Live examples at more than one screen size; a walk-through of a form, menu, or other real task.
A form, booking tool, payment flow, or third-party service must connect reliably. Shared, with implementation accountable Make the path intelligible: what the visitor provides, what happens next, and how errors are explained. Integration scope, data handoff, failure states, testing, and the boundary of third-party responsibility. A written owner-by-owner path from visitor action to the required handoff; test evidence appropriate to the scope.
The business needs a portal, accounts, permissions, custom workflow, or a system that stores and processes business data. Implementation or engineering leadership Interfaces, workflows, clear states, and understandable error/recovery language. Architecture, security, data handling, authorization, reliability, maintenance, and specialized integration work. Relevant delivered work, technical approach, ownership model, security and support responsibilities, and limits.
The site is slow, unstable, or fails under a known condition. Implementation diagnosis Clarify the affected user task and avoid hiding the symptom in a new visual layer. Reproduce the failure, identify the mechanism, repair or scope a proportionate change, and retest. The named symptom, test conditions, evidence, unknowns, and the smallest repair considered.
An established site is changing platforms or structure. Shared, with a named migration owner Preserve content hierarchy and help define the destination pages that users need. URL mapping, redirects, account access, platform limits, data/export handling, test plan, and launch monitoring. A written inventory of what is kept, rebuilt, redirected, exported, or retired—and who owns each outcome.
The project needs a marketing site with ordinary pages and no unusual application behavior. Design and web implementation, explicitly scoped The buyer path, page patterns, content presentation, and usable interface. The chosen platform, page build, normal site behavior, accessibility and launch checks included in the written scope. A scope that names what is included, excluded, tested, and handed over.

If the proposal cannot fill the evidence column, the title does not solve the problem. “Full-stack,” “conversion-focused,” “custom,” and “turnkey” are descriptions of ambition until the provider can identify what they will own, how it will be tested, and what they will not do.

Start with the failure you cannot afford

Titles become clearer when you name the project’s unacceptable failure.

  • If the unacceptable failure is the right buyer cannot understand the offer or find a usable next step, begin with design leadership.
  • If the unacceptable failure is a required system does not behave correctly, preserve data, or connect to another system, begin with implementation capability.
  • If the unacceptable failure is the business loses important content, paths, access, or control during change, require both design and implementation coverage, plus an explicit migration owner.
  • If the unacceptable failure is nobody knows who owns the contact path after the button is clicked, do not hire on title alone. Name the chain from visitor action to the destination record or recipient and who tests it.

This is not a hierarchy in which one role is more serious than the other. A visually polished page can fail because its path is unclear; a technically capable system can fail because nobody understands what it is asking them to do. The job is to make the primary risk visible before it becomes a handoff dispute.

What a designer is usually being hired to decide

For a service-business website, design is not only color, type, and imagery. The important design decisions are often structural:

  • What does a first-time visitor need to understand before choosing a route?
  • Which proof belongs near which claim?
  • What should be easy to compare, and what should be separated into distinct pages?
  • What is the proportionate next action for a ready buyer versus a cautious one?
  • Can a person use the navigation, form, and primary action on a phone and with a keyboard?
  • Do the page and interaction states still make sense when real content is longer, more qualified, or less photogenic than a mockup?

A person can be a strong visual designer and still be the wrong fit if they cannot answer those questions. Conversely, a designer who can explain the buyer problem, the hierarchy, and the interaction choices may be a better lead for a straightforward marketing site than a developer chosen only because they write code.

Ask to see reasoning, not just a gallery. A portfolio screenshot can show taste. It cannot show what happened when the form errored, when the service copy grew, when a mobile visitor used the menu, or when the business had to update a claim later.

What a developer or implementation specialist is usually being hired to decide

Implementation work becomes central when the project must make technical guarantees of behavior within a written scope. That may include building components, integrating a known system, handling data or permissions, fixing a diagnosed defect, preserving or moving an existing site, or running a custom application.

The key questions are practical rather than glamorous: What systems are involved? What data crosses the boundary? Who controls the accounts? What happens when the dependency fails? How will the path be tested? Who maintains the result? Can the business take its content, data, and access with it if the relationship ends?

For ordinary marketing sites, those questions may be modest. They are still questions. Do not turn a simple platform build into an imaginary software project, and do not wave away a real integration or data responsibility because the visible pages look simple.

When one person can cover both roles

One accountable person can be a good fit when the project is genuinely bounded, the person can show relevant work across both areas, and the scope makes their responsibility testable. This is common for a straightforward small-business site: the same person may shape the page hierarchy, create the design system, build the pages, and test the standard paths.

Do not assume “one person does both” means the buyer gets a complete system automatically. Ask which parts are personal expertise, which are platform defaults, which depend on a third party, and which are outside the provider’s offer. A generalist who says “I do everything” may be the right partner; the statement becomes meaningful only when it is translated into included work, exclusions, acceptance evidence, and handoff.

When the project needs more than one accountable role

Add distinct coverage when the project crosses into a risk one person cannot credibly carry alone: a custom application, sensitive or regulated data, specialized integrations, a complex migration, a significant performance or reliability problem, a broad content program, or accessibility work that needs qualified evaluation. The answer is not automatically a larger agency. It may be a small team with a clear lead, a specialist subcontractor, or a provider who says the project is outside their scope.

The useful proposal names the handoff. It says who makes the interface decision, who implements it, who supplies and verifies facts, who owns the accounts and data, who tests which path, and who accepts the result. A project with two roles and no handoff plan can be worse than a project with one well-scoped generalist.

Five role-coverage checks before you choose

Use these five questions only to expose the coverage behind the role choice:

  1. Which parts of this project will you personally handle? Name the decisions and work the person in front of you is accountable for, not just the title they use.
  2. Which parts need a specialist or subcontractor, and who owns that person’s result? A referral is not a handoff plan unless someone remains accountable for the seam.
  3. Which parts are the platform’s or vendor’s responsibility? Separate a provider’s implementation work from the behavior, limits, support, and uptime of a form tool, host, scheduler, payment service, or other dependency.
  4. Which parts are explicitly outside this role’s scope? A direct exclusion is safer than a vague promise to “make it work.”
  5. Who owns the handoff between roles? Name who turns the design decision into implementation instructions, who verifies the finished path against that decision, and who resolves a gap between the two.

These questions do not replace the broader provider interview. For the full hiring conversation about diagnosis, scope, proof, ownership, price, support, and exit, use the web-designer hiring questions. For a line-by-line comparison of what a small-business web-design service includes, use the scope-and-evidence worksheet.

Make the handoff visible before you choose the title

Use this comparison to name coverage, not to certify a particular provider or turn a website partner into a general application-development shop. The written scope, demonstrated work, dependency owners, and test evidence remain the real answer.

For RP adjacency, the boundary is plain: website planning and launch foundations can fit a service-business marketing site, while unrelated engineering, application, integration, or operational work must be explicitly scoped and shown to be within the provider’s actual offer. A role label does not expand that offer.

Sources