How to Get Started with Trellis:
The Designer's Workflow

Every piece of content on a Webflow site is either a static component or a CMS collection item. The choice between them is the single most important structural decision you make — and most people get it wrong because they use the wrong criteria.

This guide covers the decision framework, the workflow I actually use when building with Trellis, and a pattern called "promote to collection" that lets you start simple and scale up without rework.

The fundamental question: component or collection?

The conventional advice is "if it needs a URL, make it a collection." That is incomplete. Plenty of content that never gets its own page still belongs in a collection. The real question has three parts:

1. Does it repeat? If the same content appears in more than one place — even two — it should be a collection. One source of truth, multiple display locations.
2. Does it grow? If the list of items will get longer over time (blog posts, team members, events), it needs a collection. Static components cannot grow without developer intervention.
3. Does a non-developer need to edit it? If a marketing manager, client, or content editor will update this content, it belongs in the CMS. Static components require Designer access to change.

If the answer to all three is no — it appears in one place, the content is fixed, and only a developer edits it — keep it as a static component. Everything else is a candidate for a collection.

Examples that clarify the gray area

The obvious cases are easy. Blog posts are always collections. Hero sections are always static. But most content lives in the middle, and that is where people make expensive mistakes.

• Impact stats ("12M oysters restored", "400 volunteers") shown on the homepage, about page, and impact page. Same data, three places. That is a collection — even though each stat never gets its own URL.
• Company values on the about page only. Nobody else edits them. They change maybe once a year. Keep it static.
• Company values on the about page, careers page, and footer. Now the same content appears in three places. If you update a value, you need to update it three times — or make it a collection and update once.
• A progress tracker widget that appears on five pages with dynamic numbers. Collection. The data changes regularly, it appears in multiple locations, and someone non-technical updates the numbers.
• Hero section with a headline, subhead, and background image. Always static. It appears on one page, the design is unique to that page, and changing it is a design decision, not a content update.
• Testimonials displayed on the homepage and the pricing page. Collection. Even if you only have four testimonials today, they appear in two places, and you will want to add more without opening the Designer.

The decision is not permanent. You can always promote a static component to a collection later. Starting static and promoting when the need is clear is almost always safer than over-engineering from day one. Read the full decision framework in the Component vs. Collection wiki reference.

Not sure? Try the decision tool.

Answer four quick questions about your content and we'll tell you whether it should be a static component or a CMS collection.

The designer's workflow

Here is how I actually use Trellis when building a Webflow site. This is not the only workflow — it is the one that produces the cleanest results with the least rework.

Step 1: Design the component first

Start in Webflow Designer (or Figma, if you prototype there). Build the component visually — the team member card, the testimonial block, the service feature row. Do not think about the CMS yet. Focus on the design.

This feels backwards if you are used to starting with the data model. But designing first means your CMS structure serves the design, not the other way around. You will never end up with fields you do not use or missing fields you need.

Step 2: Ask "is this a pattern?"

Once the component looks right, step back and ask the three questions: will it repeat, grow, or need non-dev editing? If yes to any of them, this component needs a collection behind it.

Step 3: Screenshot the component

Take a screenshot of the component in its designed state — with real or realistic content in it. This screenshot is what you will upload to Trellis.

Step 4: Upload to Trellis AI

Drop the screenshot into Trellis. The AI analyzes the visual design and generates a complete field structure: field names, types, help text, and display context. A team member card with a photo, name, role, and bio becomes an Image field, two PlainText fields, and a RichText field — automatically.

Step 5: Review and refine the fields

Trellis gets you 80-90% of the way there. Review the generated fields and adjust: rename fields to match your naming conventions, change a PlainText to RichText if the body needs formatting, add SEO fields (meta title, meta description, OG image) if items will have their own pages, and remove anything unnecessary.

This review step takes two minutes and prevents the kind of field-type mistakes that cost hours to fix later in Webflow (where you cannot retype a field — you have to delete it and lose the data).

Step 6: Deploy to Webflow CMS

One click. Trellis creates the collection in your Webflow site with all the fields, types, and help text configured. Go back to Webflow Designer, bind the component elements to the new collection fields, and you are live.

Step 7: Connect a data source (optional)

If your content lives in Airtable, Notion, Google Sheets, or another source, connect it now. Trellis maps the source fields to your Webflow collection fields and keeps them in sync. If you are managing content directly in Webflow, skip this step — your collection is ready to use as-is.

When to start with Trellis vs. when to start in Webflow

The workflow above assumes you are designing as you go — the most common scenario. But there are four starting points, and each one has a different entry into Trellis.

You know your content types upfront

Maybe you have a site map. Maybe you have done this kind of site before. If you already know you need Blog Posts, Team Members, Services, and Case Studies, start in Trellis. Generate the entire CMS structure, deploy it to Webflow, and then design with the collections already in place. This is the fastest path for experienced builders.

You are designing as you go

You have a rough concept but the content types will emerge as you design. Use the workflow above: design the component, screenshot it when you know it is a pattern, let Trellis generate the collection. This is the safest path — you never build collections you do not use.

You are migrating existing content

You have a CSV, a WordPress export, or an existing Airtable base full of content. Start in Trellis with your source data. Trellis analyzes the structure and generates matching Webflow collections. Design the site around the content you already have.

You are building for a client

Start in Trellis with an industry template. Trellis has templates for nonprofits, real estate, restaurants, e-commerce, SaaS, and more — each one a pre-built set of collections with the fields that industry actually needs. Customize the template, deploy, and design. This cuts CMS setup from hours to minutes.

The "promote to collection" pattern

This is the single most useful workflow pattern in Trellis, and it solves the most common mistake in CMS architecture: over-engineering.

Here is the scenario. You built a set of company values as static text on the about page. Three months later, the client wants the same values on the careers page and in the footer. Now you need them in three places, which means you need a collection.

Without Trellis, this means: create a new collection in Webflow, manually add each field, manually enter every value, go back to the about page and rebind everything to the new collection, then bind the careers page and footer. Forty-five minutes of tedious, error-prone work.

With Trellis: screenshot the existing component on the about page. Trellis generates the collection structure from the screenshot. Review the fields, deploy to Webflow, enter the content, and rebind. Fifteen minutes, most of it spent entering content.

The "promote to collection" pattern means you never have to predict what will need a collection. You start static, and when the need becomes real, you promote. No over-engineering, no wasted collections, no hitting the 40-collection limit because you made everything a collection "just in case."

Practical tips

• Do not make everything a collection. Webflow has a hard limit of 40 collections on the Business plan and 20 on the CMS plan. Every collection you create is a slot you cannot get back. Reserve collections for content that genuinely repeats, grows, or needs non-dev editing.
• Rich text page sections should usually stay static. A one-off content block on a single page — an "Our Story" section, a founder letter, a mission statement — does not need the overhead of a collection. If it lives on one page and changes once a year, leave it in the Designer.
• When in doubt, start static. It is always easier to promote a static component to a collection than to demote a collection back to static. The promote path is clean. The demote path means deleting a collection and hardcoding the content — wasteful in both directions.
• Use Trellis's site analyzer on existing sites. If you have an existing Webflow site and are not sure what should be a collection, run the analyzer. It audits your site structure and identifies content that would benefit from being in the CMS — repeated patterns, manually duplicated content, and content that changes frequently.
• Name collections for what they contain, not where they appear. "Homepage Stats" is a bad collection name because you will eventually show those stats elsewhere. "Impact Metrics" is better — it describes the content, not the location. Read more in naming conventions.

Frequently Asked Questions

What if I am not sure whether something should be a collection?

Start static. The three-question test (does it repeat, grow, or need non-dev editing?) covers 90% of cases. For the remaining 10%, default to static and promote later if the need becomes clear. The cost of promoting is low. The cost of an unnecessary collection is a permanent slot consumed.

Can I use Trellis without connecting a data source?

Yes. Trellis is a CMS architecture tool first and a sync tool second. You can use it to design and deploy collections to Webflow without ever connecting Airtable, Notion, or any other source. Many people use Trellis purely for the screenshot-to-schema workflow and manage content directly in Webflow.

How does the screenshot analysis work?

You upload a screenshot of a designed component. Trellis uses AI to identify the visual elements — text blocks, images, icons, buttons, dates, numbers — and maps each one to the appropriate CMS field type. A headshot becomes an Image field. A name becomes PlainText. A paragraph becomes RichText. The output is a complete collection structure you can review and edit before deploying.

Does promoting a component to a collection break anything?

Promoting requires rebinding. Your static elements are currently hardcoded text and images. After deploying the new collection, you need to replace those hardcoded elements with CMS-bound elements in Webflow Designer. Trellis handles the collection creation and field setup — the Designer rebinding is manual but straightforward.

How many collections should a typical site have?

Most sites need 5 to 15 collections. A simple portfolio site might have 4 (Projects, Categories, Testimonials, Team). A complex agency site might have 12 to 18. If you are approaching 25+, audit whether some collections could be consolidated using option fields or whether some content should go back to being static. See the CMS architecture planning guide for more.

What is the best order: design first or CMS first?

Design first for most projects. Building the visual component before the data model means your CMS serves the design rather than constraining it. The exception is content-heavy sites with known data structures (e-commerce catalogs, property listings, large blogs) — for those, starting with the CMS structure and designing around it saves time.