Build on a CMS the team can keep running.

Most hosted builders and page-builder setups are useful until the template, theme, or block library starts deciding what the site can become. The team can edit, but the brand, conversion path, and technical structure are boxed into the platform’s defaults.

• The template is doing too much of the design.

  Hero shape, section rhythm, footer pattern, spacing, and component behavior all come from the template. The site may be editable, but it does not feel specific to the business.

• The block library stops at the basics.

  Booking flows with conditional logic, intake forms with file uploads, calculators, configurators, member areas, and custom content models often need more than the default blocks provide.

• Performance gets stuck under the template’s ceiling.

  Image compression, caching, and plug-ins can help, but some templates and page builders stay heavy because of how they are built. At that point, the issue is structural, not just a setting.

• AI search has little structure to extract.

  Many template pages are visually clear but thinly structured. Visible FAQ content, clear headings, answer-ready sections, and internal links need to be planned into the page, not assumed because the CMS has an SEO panel.

• The business paid for a custom-looking site but got a template-bound one.

  The issue is not the subscription fee itself. The issue is paying for a site that still cannot support the brand, editing workflow, conversion path, or next stage of the business.

The real cost is the brand that cannot show through, the conversion path the template constrains, the custom request that becomes fragile, and the migration waiting when the business outgrows the platform.

• A brand compressed into what the template allows.

  The brand becomes mostly logo, color, and copy because the layout, components, and interaction patterns are already decided. The site looks acceptable, but not specific.

• A conversion path constrained by template assumptions.

  Forms, buttons, hero sections, galleries, service cards, and page layouts all come with defaults. The business starts shaping the offer around the template instead of shaping the site around the buyer.

• The first real custom request exposes the limits.

  A booking flow, calculator, member area, quote form, or custom integration may be possible, but only through workarounds that make the site harder to maintain.

• A migration ahead when the business outgrows the CMS.

  Many platform escapes start with a site that was fine for the first stage but wrong for the next one. Choosing the CMS carefully upfront can prevent the business from rebuilding sooner than it should.

The studio does not start with a favorite platform and force the project into it. The CMS is chosen based on editing workflow, content structure, integrations, ownership, maintenance, and the next few years of use. If the project includes a migration, SEO preservation is planned before the build begins.

• Simple hosted CMS when the business needs an all-in-one editor.

  For owner-operated businesses with a clear offer, simple content needs, and a non-technical owner editing day to day, an all-in-one hosted CMS can be the right fit. The work is to keep the site clear, branded, editable, and structured well enough for search without pretending the platform is more flexible than it is.

  Read the full page →

• Editorial CMS when the site has a real publishing workflow.

  For content-heavy sites, resource libraries, articles, location pages, or teams that publish often, the CMS needs to support clear editing roles, reusable content types, and maintainable page structures. That may mean WordPress with a custom theme, a headless CMS, or another structured editing layer. The choice follows the workflow, not the platform habit.

• Visual CMS when design control is the priority.

  A visual CMS can be a strong fit when the brand needs precise design control and the team wants to edit structured content without managing a custom codebase. It is the wrong fit when the business needs functionality the platform cannot support cleanly, such as complex gated content, unusual integrations, or workflows that require too many workarounds.

• Lightweight site builders when the owner needs direct control.

  A lightweight builder can work for a solo owner or very simple site when direct editing matters more than long-term flexibility. The tradeoff is portability and room to grow, which should be clear before the build starts.

• Design-led builders when the site is small and highly visual.

  Some hosted builders are useful for compact brand sites where motion, interaction, and visual polish matter more than complex content operations. They are less useful when the site needs many pages, advanced workflows, or long-term content growth.

• Commerce CMS when checkout is the core of the business.

  Product catalogs, checkout, inventory, and merchant tools need a commerce-first platform. For marketing sites with a small shop attached, the CMS decision should separate the brand site from the commerce layer instead of forcing one platform to do everything.

• Custom build when the CMS should not lead the project.

  Some sites need performance, design control, ownership, or custom workflows that hosted CMS platforms do not handle cleanly. In those cases, the site can be built custom and paired with the right editing layer only where the business actually needs it.

  Read the full page →

The CMS may change from project to project, but the same promises should hold: the site should look like the business, the team should be able to edit the right things, and the technical foundation should support search, speed, and future changes.

• A site that looks like the business, not the CMS.

  Custom design, reusable sections, and custom code are used where the platform’s defaults fall short. The brand should lead the site, not the template.

• An editor handoff the team can actually use.

  After launch, the team should be able to edit the content that changes often: pages, photos, prices, hours, posts, services, or reusable sections. The handoff explains what is editable, what is custom, and which changes need developer support.

• Search and answer structure built into the page.

  Metadata, schema, headings, internal links, and answer-ready sections are planned into the build where they make sense. The goal is a page that is easier for search engines and AI search systems to understand, not just a page that looks finished in the editor.

• Proof the build holds up.

  Live work anchors the approach: Black Salt Room shows what a custom build can do for performance and local structure, Palisades Lodge shows how CMS and booking decisions can connect with hospitality operations, and Bodie Foundation shows how commerce can move without interrupting the merchant workflow.