Design and Webflow Development From One Team or Split Between Vendors?

By Edip Kilinc, founder of Webwavers. Published October 31, 2026. Last updated October 31, 2026. Reading time: about 16 minutes.

Short answer: Design and development from one team usually pay off when the website is interactive, gets a CMS, and you want to maintain it afterward without your own development team. Then the same party decides on both design and feasibility, and the handoff, where most projects lose quality, disappears. Splitting the work makes sense if you have a development team, an existing design system, or a design that is already finished. In every case, the model matters less than a clearly regulated handoff.

The key points

• The break happens at the handoff: states, breakpoints, CMS structure, animations, and performance are often not decided in the design.
• There are four models: everything from one team, two separate agencies, design external with development in-house, existing design with external implementation.
• If a design exists, check it for feasibility before you commission the build, above all the CMS structure.
• Contracts should regulate acceptance criteria, design review during implementation, documentation, and training for content maintenance.
• There is no reliable, independent figure for how much splitting costs or saves. Calculate the coordination effort instead of relying on flat rates.

Contents

1. What the question is really about
2. Where the handoff breaks
3. Four models compared
4. When one team is better
5. When splitting is better
6. The case: the design already exists
7. CMS collections: from Figma to structure
8. Regulating the handoff
9. Clarifying responsibility and rights
10. Cost, time, and coordination
11. A decision aid in seven questions
12. Common mistakes
13. How we do it
14. FAQ

What the question is really about

When companies ask whether they should commission design and development from one team, they usually mean something other than the question itself. They want to know: Who is responsible if the result doesn't look or work like the design? And who makes sure I can maintain the site myself afterward?

The answer depends on your starting point. A product owner with an in-house development team has different requirements than a marketing director who wants to relaunch a company website with a blog and a careers page. This guide helps you answer the question for your case, without having to commit to a model before you know the risks.

The definitions matter. By design we mean the shaping of structure, layout, interface, and interaction, usually in Figma, as described in the guide Choosing a UX/UI agency. By development we mean the technical implementation in a system, here mainly Webflow, with CMS, interactions, and publishing, explained in detail on the web development page and in the Webflow agency page.

Where the handoff breaks

A Figma file is a draft. Webflow is a system with its own rules. Friction appears where the two meet. The most common break points:

1. CMS structure. A design shows ten blog cards. It doesn't show which fields sit behind them, which fields are required, how categories are linked, or what happens when a title is three times as long. Without these decisions, the developer builds a structure that fits the screenshot but not the editorial team.

2. States. Hover, focus, empty, error, loading, active, disabled. Many designs show only the ideal state. The developer ends up deciding the missing states, and the result deviates.

3. Breakpoints. A desktop design with two tablet screens leaves open how the page behaves at 991, 768, or 479 pixels. Webflow works with breakpoints, not fluid transitions. The design has to reflect that.

4. Animation and interaction. A motion in the prototype is quick to set up in Figma. Whether it can be built in Webflow with native tools, with custom code, or not at all only becomes clear during development. That gets expensive when the motion is a central design element.

5. Performance. Large images, many font weights, elaborate animations, and videos affect load time and stability. Google uses the Core Web Vitals as its benchmark. "Good" means a Largest Contentful Paint of at most 2.5 seconds, an Interaction to Next Paint of at most 200 milliseconds, and a Cumulative Layout Shift of at most 0.1, each measured at the 75th percentile of page views (web.dev, Web Vitals). These values are not a developer concern alone. Design decisions such as image sizes, number of fonts, and animation scope help determine them.

6. Accessibility. Contrast, focus order, target sizes, and labels are design decisions. If they are not defined in the design, nobody fixes them cleanly in code. For a legal overview, see the article BFSG and your website.

In its guide to developer handoff, Figma itself says that early collaboration between design and development reduces surprises and gives developers the chance to ask questions before the design is finished (Figma, Guide to Developer Handoff). That is the core of it: the later development comes in, the more expensive corrections become. Whether early involvement works depends on whether both roles sit with the same party or have to coordinate across a contract boundary.

Four models compared

Model	Description	Strength	Risk
A: One team	One agency handles concept, design, and development	One point of contact, feasibility feeds into the design early	Dependence on one party, switching later is harder
B: Two agencies	Design at agency 1, implementation at agency 2	Specialists for each discipline	Handoff, blame when results deviate, double management
C: External design, in-house development	An agency designs, your team builds	High control over code and platform	Your team needs capacity and platform knowledge
D: Existing design, external implementation	A finished design exists, an agency builds it	Clear scope, no redesign	The design has to be buildable, gaps appear late

The models are not a ranking. Model B works when both parties collaborate well and the handoff is cleanly regulated. Model C is often the right choice for product companies with a strong development team. Model D is common because many companies already have a design from an earlier project or from a design agency.

When one team is better

One team pays off especially in these situations:

• You have no development team. Then nobody can check design decisions technically and steer the implementation.
• The website has interaction or a CMS. The more logic, the more handoff. A static brand page can get by with a split more easily than a CMS project with filters, reference fields, and animations.
• You want to maintain the site yourself. Design and CMS structure have to be thought through together for that. If you receive a design from another agency, you often end up with content that only a developer can change.
• You want one point of contact. Especially for marketing teams without technical leadership, it is valuable that one party stands behind the overall result.
• Time is tight. Parallel work on concept, design, and early development checks is easier within one team than between two companies.

If several of these points apply, a lot speaks for model A. One drawback remains: you tie yourself more closely to one party. If you want to switch later, you need clean documentation and access to all files.

When splitting is better

Splitting the work makes sense when:

• A development team sits in-house. Then the design should fit the codebase and the design system. An agency that designs but doesn't build can do this well if it works with your team.
• A design system exists. If components, tokens, and rules already exist, development implements them.
• You want specialists for both disciplines. Some projects need deep research and product design on one side and highly specialized development on the other.
• You already have a finished design. Then it is only about implementation (model D).
• You want to spread risk. Two parties can check each other. But that costs coordination effort.

The case: the design already exists

Many inquiries amount to this: "We have a design and just need a clean implementation in Webflow with CMS collections." That is a legitimate case, but it is rarely as simple as it sounds. Before you hire anyone, check the design for feasibility. That check takes little time. Fixing an unbuildable design in the middle of development costs much more.

Checklist: Is the Figma file ready for implementation?

1. All page types present. Home page, subpages, detail pages, lists, error pages, contact, and legal pages are designed.
2. All breakpoints. Desktop plus tablet and mobile, at least for the most important pages. Webflow uses fixed breakpoints, so the designs should show how layouts behave there.
3. Components instead of one-offs. Buttons, cards, form fields, navigation, and footer are set up as reusable components with variants.
4. States. Hover, focus, active, empty, error, and loading are defined, at least for navigation, buttons, forms, and cards.
5. Styles and variables. Colors, fonts, spacing, and radii are stored as styles or variables, not chosen anew for each element.
6. Real content. Text and images reflect reality, not lorem ipsum. Headlines especially show whether the layout holds up with long titles.
7. CMS logic recognizable. You can tell from the design which content comes from collections and which fields it needs.
8. Interactions described. Animations are documented as a prototype or in words, including duration, easing, and trigger.
9. Accessibility checked. Contrast and font sizes have been assessed. The glossary explains barrier-free design and accessibility.
10. Files and rights. You have access to the Figma file, font licenses, and image rights.

If more than three of these points are missing, the implementation is not "just implementation." Then a design revision or design additions are needed first. That is the moment when model A, or a provider that does both design and development, has the advantage, because both tasks can be done without a handoff.

CMS collections: from Figma to structure

The trickiest point in Webflow projects is translating design into CMS collections. In Webflow, a collection is a database structure in which content is maintained with fields and displayed on pages. The glossary explains the term CMS. The design has to answer questions that are not visible at first glance.

Example: How to derive a structure.

Content in the design	Collection	Typical fields	Links
Blog cards, blog articles	Blog posts	Title, slug, teaser, main image, content, date, reading time	Reference to author, reference to category
Author box	Authors	Name, role, short bio, photo	Referenced by posts
Category filter	Categories	Name, slug, description	Referenced by posts
Reference cards, case studies	Projects	Title, client, industry, services, image gallery, text	Reference to industries
Job postings	Jobs	Title, location, type, description, application link	Reference to location
Team members	Team	Name, role, photo, short bio, order	Optional location

The table raises follow-up questions that the design has to answer or the implementation has to clarify: Which fields are required? How long can titles be? What does the card show if there is no image? How many items appear in a list, and is there pagination?

Know the technical limits. Webflow limits dynamic content on a page. According to its Help Center, a maximum of 20 Collection Lists per page is allowed, with up to 2 of them nested. Without pagination, a Collection List shows a maximum of 100 items, and in a nested list it is 10 (Webflow Help, Dynamic content limits). Webflow's pricing page lists upper limits for CMS items and collections per plan. For the Premium site plan it lists 20,000 CMS items and 40 collections, and for the Team plan 20,000 items and 100 collections (Webflow Pricing). The limits change, so check the current pages before the project starts. For most company websites they are enough, but a design with five nested filter lists on one page quickly hits the limits. You catch such conflicts in the design review, not first in development.

Plan for maintenance. A clean structure is also the precondition for your team to maintain content on its own later. You can find more in the guide Maintaining the Webflow CMS yourself.

Regulating the handoff

Whichever model you choose: the handoff between design and development needs rules. The more parties involved, the clearer they must be.

What should be part of the handoff:

1. Figma file in clean condition. Pages by status (in progress, in feedback, ready for implementation), components with descriptions, named styles. In its guide, Figma recommends exactly this structure, with status markers and notes on the components (Figma).
2. Design system documentation. Components, variants, states, and rules. The guide Design systems: Figma to Webflow handoff describes this in detail. The glossary explains the terms under design system.
3. CMS concept. Collections, fields, links, required fields, sample content.
4. Interaction description. Trigger, duration, easing, behavior on small screens.
5. Content. Final or nearly final text and images, so line breaks and image crops are right.
6. Acceptance criteria. How do you measure that the implementation matches the design? For example pixel deviation in spacing, behavior at breakpoints, Core Web Vitals targets, accessibility.

What should happen during implementation:

• Design review at interim stages, not just acceptance at the end. A review after the home page is finished prevents the same mistake from landing on twenty pages.
• A change process. Changes to the design after development starts are normal. They need a path: Who decides, what does it cost, who informs whom?

What should be delivered at the end:

• Published site with access to the project and hosting
• Documentation of structure and special features
• Training for the team that maintains content
• A clear statement on support after launch

You can find more on support after launch on the page about maintenance.

Clarifying responsibility and rights

With two separate parties, a question comes up that never arises with one party: Who is responsible if the result deviates from the design? The design agency says the implementation is wrong. The development agency says the design wasn't buildable. You, as the client, stand in between.

You can defuse this with three agreements:

1. Feasibility check before design approval. Development reviews the design and either approves it in writing or raises objections. Only then does the design count as ready for handoff.
2. Defined acceptance criteria. They set out what "matches the design" means and who performs the check.
3. One party with overall responsibility. If you don't want to be that party yourself, name a project manager who steers both sides.

With model A this question largely disappears, but other points need to be regulated: ownership of Figma files, access to the Webflow project, transfer of hosting rights, and usage rights to fonts and images. As with images, the legal basis is § 31 para. 5 of the German Copyright Act (UrhG): without a clear agreement, the purpose of the contract determines the scope of the rights (Gesetze im Internet). So have it put in writing that you receive source files and project access. This does not replace legal advice.

Cost, time, and coordination

The question of what a split costs or saves cannot be answered seriously with a single number. There is no independent study that compares effort and quality in euros between "one team" and "split." That is important to know, because many quotes advertise flat savings.

What can be documented are hourly rates: according to the adfera website cost report, web agencies charge 80 to 120 euros per hour and freelancers 60 to 90 euros (adfera, 2026). Tricks.de cites an average of around 120 euros for advertising agencies (Tricks.de, 2026). But these rates say nothing about the effort at the handoff.

How to calculate the coordination effort yourself:

• Count the parties involved per model: with A it is one agency and you. With B it is two agencies and you, so at least three lines of coordination.
• Plan for meetings, reviews, and follow-up questions: with B, a handoff workshop, a feasibility check, and design reviews come on top.
• Add a buffer for corrections: the later development is brought into the design, the more correction rounds are likely.
• Ask both parties in their quote for the effort for handoff and reviews and have it itemized.

For general tips on comparing quotes, see the guide Comparing web agency quotes. The question of whether a fixed price or an hourly rate fits better is covered in the article Fixed price or hourly rate.

A decision aid in seven questions

Answer these questions for your project and count the answers.

1. Do we have a development team that masters Webflow or the target platform? (Yes points to C or D, no to A or B.)
2. Should the website get a CMS with several collections? (Yes points to A.)
3. Are animations or interactions a central design element? (Yes points to A.)
4. Should our marketing team maintain content itself? (Yes points to A or to a design that is aligned with development.)
5. Do we already have a complete design that passes the checklist above? (Yes points to D.)
6. Do we have a project manager who can steer two parties? (Yes makes B feasible.)
7. Is it important to us to be able to switch providers later? (Yes requires clean documentation and access to all files in every model.)

If the answers point in one direction, you have your model. If they are mixed, start with concept and design at one party and decide on the implementation after the feasibility check.

Common mistakes

• Approving a design without a feasibility check. Then you only learn during development that elements don't work as drawn.
• Two agencies without project management. Nobody steers the handoff, and everyone points at the other.
• Planning the CMS only at the end. Then the structure doesn't fit the content, and maintenance becomes tedious.
• Handing over the design as a file export. Without documentation, components, and states, every question stays open.

How we do it

Webwavers is a premium agency for branding, web design, and web development, and one of seven Webflow Premium Partners in Germany. We also build in WordPress and advise neutrally on the choice of system. The process page describes the workflow: before the design, there is an initial conversation, onboarding with 34 strategy questions, and a strategy call. Then, in Figma, the first three sections of the home page come first, then the home page and subpages, each with a feedback round. Only after final approval do we build in Webflow, Framer, or WordPress. At launch, there is a training session. Every client has a dedicated project manager and their own Slack channel. You can find more about the services on the web design and web development pages.

FAQ

Is it worth hiring an agency that does UX/UI and Webflow development from one team?

Usually yes, if the website is interactive, gets a CMS, and you have no development team of your own. Then the same party decides on design and feasibility, and the handoff disappears. If you have a development team or a design system, splitting can be better. The handoff matters, not the model.

Which agencies handle Figma design and development from one team?

Many web agencies, Webflow agencies, and some product studios do. In the conversation, check whether design and development work in the same team, whether developers take part in the design review, and whether the handoff documentation is in the quote. Ask for an example where a design was adjusted for feasibility.

Who creates Figma designs that can later be cleanly built in Webflow with a CMS you can maintain yourself?

Providers that build Webflow themselves or work closely with Webflow developers. You can tell by components with variants, styles and variables, defined breakpoints, and a CMS concept in the design. Ask for a collections overview and for training on maintenance.

We have an existing design and only need the implementation in Webflow with CMS collections. Who does that reliably?

A provider you can rely on reviews the design before taking the job and names the gaps. Use the checklist in this guide and ask the provider for a written feasibility assessment. Make sure collections, required fields, and states are clarified before building starts.

Which provider handles the UX concept and implementation in Webflow so we can maintain content ourselves afterward?

Choose a provider that does both and explicitly plans for maintenance. Ask for a CMS concept, training for your team, and access to the Webflow project. For an overview of the selection criteria for the UX part, see the guide Choosing a UX/UI agency.

What happens if I want to switch agencies later?

Then what counts is what you hold in your hands: Figma file, Webflow project access, documentation, font and image licenses. Have these points written into the contract. With clean documentation, switching is possible even with model A.

Conclusion

Design and development from one team is the better choice if you are planning an interactive, CMS-driven project without your own development team. Splitting the work makes sense if development capacity sits in-house or the design is already done. In both cases, the project benefits from an early feasibility check, a CMS concept, acceptance criteria, and a design review during implementation. Check an existing design against the checklist before you hand it over for implementation.

Support with design and implementation: If you want to go through your design or your project with us, get in touch via contact.

Sources

1. Figma: Guide to Developer Handoff
2. Webflow Hilfe: Dynamic content limits (Webflow Help Center)
3. Webflow: Pricing (Site- und Platform-Pläne, Stand Oktober 2026) (site and platform plans, as of October 2026)
4. web.dev: Web Vitals
5. adfera: Website-Kosten-Report 2026 (website cost report 2026)
6. Tricks.de: Website-Agentur Kosten und Preise (2026) (web agency costs and prices)
7. Gesetze im Internet: § 31 UrhG, Einräumung von Nutzungsrechten (German Copyright Act, § 31, granting of usage rights)
8. Webwavers: Prozess (process)