Design and build sounds like two jobs, and on most web projects it is treated as two: a designer produces screens, and a developer interprets them weeks later. The website ends up decided twice, by two people working from different information. This piece covers where that handover fails, what the gap costs in time and rework, how a single design and build run works stage by stage, and what to ask any vendor who claims to do both, so you can check before you sign.
Key takeaways
- A handover is a translation, and translations lose meaning.
- The gap shows up as revision rounds, dropped details and nobody owning performance or search.
- In one run, the person deciding how a page feels also makes it load on a phone.
- Ask a vendor for live sites, not mockups, and for the name of whoever writes the code.
Where the handover fails
In a split project, the designer works in a tool with placeholder copy, ideal screen sizes and no performance limits. The output is a set of static frames.
The developer receives those frames, usually with some notes, and has to answer every question they do not: what happens between the two screen widths that were drawn, what the hover state is, how the menu behaves on a small phone, what a form looks like when it fails, what happens when a headline runs to three lines.
Each answer is a design decision, made by someone who was not in the design conversation. Some come out well. Many come out as the quickest thing that works. Neither person is doing a bad job. The structure guarantees the website is decided twice.
What gets lost first
Motion and interaction go first, because they are hardest to describe in a still frame. Then spacing drifts as components are rebuilt by eye. Then content: real copy is longer than the placeholder, so layouts get squeezed or sections get cut. Search and performance often belong to nobody, because the designer assumed the developer would handle them and the developer assumed they were out of scope.
What the gap costs
The cost is rarely one large failure. It is a long tail of small ones, each paid for separately.
- Time. Every question the frames do not answer becomes a message, a wait and a reply. Multiply that by every page type and the build stretches.
- Rework. When the built page does not match the approved design, someone decides whether to fix the build or accept the drift. Either way, one decision gets paid for twice.
- Reopened decisions. Feedback on the build often reopens design choices, because it is the first time anyone sees the work on a real phone with real content.
- Ownership. When something underperforms after launch, such as a slow page or a form that loses people, each side can reasonably point at the other.
None of this needs a statistic to recognise. If you have run a split project, you have probably lived some version of it.
A single design and build run, stage by stage
Here is how a project runs when one person or one small team owns both halves. The stages are the same as any web project. The difference is that nothing crosses a handover.
- Brief and goals. Agree what the site must do for the business and how you will know it worked. Because the same person will build it, technical constraints come up now instead of being discovered later.
- Structure and copy. A sitemap, page outlines and copy direction. Real content arrives before visual design, so layouts are drawn for the words they will carry.
- Design. Key pages on desktop and mobile, then a component set for the rest. Motion and interaction are designed with the build in mind, often prototyped straight in code.
- Build. The approved design becomes the site, built by the person who designed it. Gaps in the design are filled with the same reasoning that produced it. Performance is checked against Google's Core Web Vitals, and accessibility and search basics are built in rather than added at the end.
- Launch and handover. Go live, check everything in production, then hand over the code, logins and a short guide. One person can explain every decision, because one person made them.
The quiet benefit is the speed of correction. When something looks wrong on a real phone, the fix happens the same afternoon, in the same head, without a ticket.
Split team vs one run
| Area | Design and build split | One design and build run |
|---|---|---|
| Questions the design did not answer | Answered by the developer, often without the reasoning | Answered by the designer, who is also the builder |
| Motion and interaction | Described in notes, often simplified | Designed and built together |
| Real content | Arrives late; layouts get squeezed | Arrives before layout |
| Performance and search | Frequently unowned | Owned from the brief |
| Fixing drift | A new revision round | A same-day correction |
| Accountability after launch | Shared, which often means nobody's | One owner |
When a split team is the right call
One run is not always best. Very large sites with dedicated engineering teams, products with complex back ends, and organisations that already employ designers and developers will usually split the work by necessity.
The fix there is not one person. It is shared design tokens, shared components, and designers who review the build rather than just the mockup. The W3C Design Tokens Community Group maintains a format for exactly that handover, and the design system examples piece covers how large teams keep it honest.
For a business site, a product marketing site or a landing page, the handover is usually the most expensive part of the project, and the easiest to remove.
What to ask a vendor who says they do both
Plenty of studios say "design and build". Some mean one team. Some mean a designer and a subcontracted developer who never meet. These questions tell you which.
- Who writes the code? Ask for a name, not a department. If it is a subcontractor, ask whether they sit in the design reviews.
- Can I see live sites, not mockups? Open them on your phone. Check that the motion, spacing and forms match the portfolio images.
- What happens when the design does not specify something? A good answer describes a process. A vague answer means the developer guesses.
- Who owns performance and search setup? Ask what every site ships with: canonical URLs, a sitemap, structured data, optimised images.
- What do I own at the end? Code, domain, content and logins should all be yours.
- How are changes handled during the build? If every change after design approval triggers a new quote, the two halves are probably separate businesses.
If you are comparing quotes at the same time, web design cost breaks down the line items that move the price. And if you want design and build in one run, that is how web design services work here.
FAQ
Is it cheaper to hire a designer and a developer separately?
Sometimes on paper. The rates may be lower, but the cost of the gap (extra revision rounds, coordination and rework) appears on neither quote. Compare the total cost of a live site, not the cost per role.
Can one person really do both well?
For business sites, marketing sites and landing pages, yes. Ask to see live work and check it on your own phone. That tells you more than any claim.
What should I receive at handover?
The code, the domain, the content, every login and a short guide to updating the site. You should be able to hire someone else to maintain it without asking anyone's permission.
Useful sources
- Core Web Vitals, web.dev
- Design Tokens Community Group, W3C