Hire a Webflow developer for CMS architecture and custom code

If you want to hire a Webflow developer who can build a structured CMS and custom code, look for a Webflow specialist with front-end engineering skills. That person plans your content model before any layout, keeps code in a place your team can version, and hands over documentation. A designer who works only in the Designer rarely covers all three.

The test that separates them takes an hour. Give the candidate your content types and ask them to sketch the collections, the references and the limits they plan around, on paper, before any design work. A specialist answers with trade-offs. Everyone else answers with page layouts.

This guide is for marketing leads and teams choosing between a freelancer, a developer and an agency. You get worked CMS examples to compare against, a map of where code belongs, a comparison table, red flags, questions and portfolio proof to request. For the mechanics of collections, read how Webflow's CMS works. Here we stay on the buying decision.

Who qualifies when you hire a Webflow developer#

You need one person, or one team, that covers two halves of the work: structuring your content and writing the code around it. Here is the profile, then the test that checks it.

The profile that fits a CMS and code project#

A Webflow designer builds layouts, styles and interactions in the Designer, and many do it beautifully. A Webflow developer does that and adds the engineering around it. The difference shows in four skills:

• Content modeling: turns how you publish into collections, fields and references that stay tidy as the site grows.
• Front-end engineering: writes JavaScript and CSS that is readable, scoped to the right pages and loaded without slowing them down.
• Integrations: connects forms, a CRM and analytics through webhooks and the Webflow Developers API.
• Operations: works on a staging copy, keeps a record of changes and documents the build for your team.

Why should a marketing team care? Because the model decides how quickly you can publish a year from now. A site that feels perfect at launch with 20 items can frustrate every editor at 400. A developer plans for the 400 from day one.

The one-hour test: model your CMS on paper#

Send the candidate a one-page list of your content types a day before the call: resources, authors, services, locations, case studies. On the call, ask them to draw the collections, the fields, the relationships and the limits they plan around. No design tool, no mockups.

Listen for four things. Collections are named by purpose, such as Resources and Authors. Repeated things (people, places, categories) get their own collection. The candidate asks who edits, how often and how many items you will have in two years. And they mention CMS limits and say they would check current values in the Webflow Help Center instead of quoting numbers from memory.

What a well-built Webflow CMS architecture looks like#

A well-built model looks plain from the outside. Editors know where to type, nothing is typed twice and a new page needs no developer. Here are two illustrative examples you can hold any proposal against.

Collections that mirror how you publish#

Start from the things your team lists, repeats or links to. Each becomes a collection. Each attribute that changes from one item to the next becomes a field.

Example one, illustrative: a B2B resource library for a company that publishes guides, webinars and reports.

• Resources: title, slug, summary, body, type, publish date, cover image, download file, one Author, several Topics, several Industries.
• Authors: name, role, photo, short bio.
• Topics: name, slug, short description.
• Industries: name, slug, intro text.

Example two, illustrative: a services business with 10 services and 8 locations. Writing 80 combined pages by hand invites copied text and broken links. Three collections avoid it: Services, Locations and a Service areas collection whose items each reference one service and one location. Pages exist only where you have something real to say, and shared details such as address and hours live once, in Locations.

Reference and multi-reference fields in practice#

A reference field points one item to one item in another collection, such as one Author per resource. A multi-reference field points one item to several, such as a resource tagged with three Topics. The payoff is editing once: change an author's photo and every resource page shows it.

Resource library model

• AuthorsOne author per resource
• TopicsMany topics per resource

ResourcesGuides, webinars and reports

• IndustriesMany industries per resource

Content model with a Resources collection linked to Authors, Topics and Industries, so one edit updates every linked page

References also drive navigation. A collection list can filter by a reference, so "all resources for Healthcare" becomes a live filter on the Industries field instead of a copied page that someone has to update. Ask a candidate to show you where each filter in your plan comes from.

Working around CMS limits in the model#

Every CMS has ceilings: items per collection, items shown in one collection list, references per field and fields per collection. They change with plans and releases, so check current numbers in the Webflow Help Center and Webflow University instead of trusting a figure in an article. What you are buying is the developer's plan for them:

• Split by purpose: separate collections for content that visitors browse differently, such as live events and an archive of past ones.
• Paginate and filter: show a manageable page of items and let visitors narrow by reference instead of loading everything.
• Replace repeated fields with references: one reference field costs less than five copied text fields.
• Keep heavy data elsewhere: for catalogs or price tables with very many rows, hold the data in a source built for it and bring in what each page needs.
• Sync through the API: the Webflow Developers documentation describes how code creates and updates CMS items, so a scheduled job can feed the CMS from your ERP or database.

Sometimes the straight answer is "this part belongs outside Webflow." That honesty is a good sign. Our guide to Webflow for SaaS companies shows how structure and limits play out on a site with docs, a changelog and integrations.

Where custom code belongs in a Webflow build#

Custom code in Webflow has three homes. The one a developer picks decides whether your team can update, test and roll back a change without opening the Designer. Ask any candidate for their plan for each.

Site-wide embeds for tracking and global behavior#

Site settings let a developer add code to the head and the footer of every page. This is the home for analytics tags, a consent banner, a chat widget and small global behaviors. Single-page code has its own field in page settings. Ask for a list of every script, what it does and who owns the account behind it.

CMS-bound embeds for per-item content#

An Embed element inside a collection template can include fields from the current item, using the Add field option in the embed editor. Typical uses are structured data (JSON-LD) with each article's own title and date, a video player that reads each item's video link, or a calculator configured per service. To check the work, view the page source of two different items and confirm the values differ. Embeds also have size limits, so longer scripts move to the next home.

External JavaScript served from a CDN#

Logic longer than a few lines belongs in a file in a code repository, versioned and served from a CDN (a network of servers that delivers files from a location near each visitor). One tag in the site settings loads it. You get review before changes go live, a version number to roll back to, and a repository in your organization's account, so you own the code. A minimal pattern looks like this:

<!-- Site settings > Custom code > Footer code -->
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js" defer></script>
<script>
  // Deferred scripts run before DOMContentLoaded, so gsap is ready here
  window.addEventListener("DOMContentLoaded", function () {
    gsap.from(".resource-card", { opacity: 0, y: 16, duration: 0.5, stagger: 0.08 });
  });
</script>

The version in the URL is pinned, so a library update never changes your site by surprise. The defer attribute lets the page render first and runs the script afterwards. Your team's own file follows the same rules, loaded from a tagged release. Test it on the staging domain before it reaches production.

Designer, developer or agency: who to hire#

A designer fits a mostly static brand site. A developer fits a CMS-driven site with code and integrations. An agency fits a launch that needs several disciplines at once. The table adds illustrative ranges.

Comparison by scope, cost range and timeline#

Treat the ranges as illustrative. Rates differ between the United States, Spain and Latin America, and scope moves the price more than geography does. Ask each candidate to price the same written scope so the proposals compare fairly.

Signs you have outgrown a single freelancer#

A good freelancer can deliver an excellent site. The pressure point is usually continuity and breadth. These signs suggest a team:

• Several editors publish every week and each needs a clear place to work.
• The site connects to a CRM, an ERP or a billing tool that must keep running.
• One launch needs design, copy, SEO and development together.
• Nobody can cover when your builder is away for a week.

If two or more fit, compare a developer-led team or an agency. The engagement options page shows how project work, a Retainer and a Care plan fit together.

Red flags to catch before you sign#

Most problems are visible in the proposal, the demo or the staging link. These are the ones worth catching early.

Duplicated collections and hardcoded content#

Duplicated collections look like "Blog EN", "Blog Healthcare" and "Blog Retail", each with the same fields. They also show up as one collection per service page. Every change then has to be repeated, filters cannot cross them and editors make quiet mistakes. Separate collections can be right when the fields truly differ, so ask the developer to explain each one.

Hardcoded content is text typed into pages that should come from the CMS: a phone number pasted in thirty places, a team bio copied between pages, a footer rebuilt on each template. Ask one simple question: how many places do I edit to change our phone number? The right answer is one.

No staging, no handover documentation#

A professional build is tested before it is published. That means a staging copy or the Webflow staging domain, a check of forms, redirects and tracking, and a clear route for a change to reach production. If the proposal does not mention it, ask.

Handover documentation is the second half. It should map your collections and fields, say where each piece of code lives, list who owns the Webflow workspace, hosting plan, repository and CDN account, and explain how to publish and roll back. If documentation is optional or unpriced, plan for the day your builder is unavailable.

Questions to ask before you hire a Webflow developer#

Good questions turn a sales call into evidence. Use the list below for Webflow specifics, and our questions to ask a web development agency for general vetting.

Ten questions for the first call#

Print this list and tick each one during the call.

• Ask them to sketch your collections, references and fields on paper before any design
• Ask which CMS limits they plan around and where they check the current values
• Ask how many places an editor changes a phone number or a team bio
• Ask where custom code will live: site settings, CMS embeds or an external repository
• Ask who owns the code repository and the CDN account after launch
• Ask how they work on staging and how a change reaches production
• Ask how they test forms, redirects and tracking before launch
• Ask what the handover document contains and whether it is in the price
• Ask how they migrate existing content and URLs, including redirects
• Ask what happens after launch: who fixes issues, how fast and at what monthly cost

Portfolio proof that shows real depth#

Screenshots show design. Depth shows in a live site you can click through and in the structure behind it. Review a portfolio in four moves.

1. Open a live CMS site

   Pick a project with a blog, resources or a directory. Try the filters, the list pages and two item pages for consistency.

2. Check the structure, with permission

   Ask the candidate to share a screen of the collections. Look for clear names, references instead of copies and few unused fields.

3. Inspect the code source

   View the page source and the loaded scripts. Look for versioned CDN URLs and deferred loading instead of large pasted blocks.

4. Ask for the handover doc

   Request a sample with client details removed. It should map collections, explain fields and list who owns what.

Also ask for one project with a content volume close to yours, and for one past client you can speak to. Then ask what the builder would change in that project today. A specific, honest answer tells you more than a polished case study.

How werun.dev builds and then runs Webflow sites#

The outcome you get from werun.dev is a Webflow site your team edits without us and a team that stays beside you after launch. We have looked after 200+ sites over 12+ years, and the method below is how the Webflow ones start.

Build: model first, design second, code last#

We begin with the paper session from this article: your content types, your editors and your two-year volume become collections, references and filters. Design comes next, using real content from the model, so layouts fit what you publish. Code comes last, in a repository you own, served from a versioned CDN file and reviewed on staging before it goes live.

During the build you use Client Feedback to click anything on the staging site and ask for a change, so feedback lands where the work happens. You receive a handover document with the collection map, the code locations and the ownership list. The Webflow service page shows the build in more detail. The same process runs in Spanish for companies in Spain, Argentina, Mexico, Colombia and Uruguay, including the desarrollo web Webflow that Spanish-speaking teams ask us for.

Run: Care plan and Retainer after launch#

After launch you choose how much support you want. The Care plan is a monthly plan that keeps the site healthy: monitoring, fixes and updates to your code and integrations. The Retainer is a monthly block of hours for improvements, such as new collections, new templates or A/B tests with werun.Experiments.

Either way you get a written monthly report, a client panel with your projects, requests and invoices, and a reply in under 2 hours on business days. Both sit beside one-off projects in the engagements overview. Because the model and the code are documented from day one, the support is cheaper to give and easier for you to audit.

Where to start this week#

Spend an hour writing a one-page list of your content types. For each, note who edits it, how often and how many items you expect in two years. That page is your brief, and it is also the material for the paper test.

Then book calls with two or three candidates and run the test. If you want to see how werun.dev would model your site, tell us your goal on the contact page. It can be more enquiries, faster publishing or fewer hours spent on updates. We reply in under 2 hours on business days, and you can read about our Webflow work while you wait.

Frequently asked questions#