Web Platform Strategy / Deep Dive

Picking a multi-tenant web platform for 260 dental practices

A senior front-end designer's read on Duda, WordPress Multisite + Bricks, Builder.io, custom headless, and Pages for Pros. Filtered through the real constraint that matters: the team that has to build and run it.
Prepared for Dakota Milner, SGA Growth
Date 2026-05-19
Scope 260 practices, 5 AI-literate coders, 1.5 to 3 designers (WP / Webflow background)
Status Pre-decision strategic analysis
Verdict

Pick Duda. Run a 60-day pilot on 6 practices, then commit. The team you have (visual-builder designers plus AI-literate coders without platform-engineering scars) will ship sooner, with fewer regrets, on Duda than on any other option. WordPress Multisite + Bricks is the only credible runner-up, and only if monthly platform cost is a binding constraint. Builder.io and custom headless are tempting but ask your coders to architect a multi-tenant system they have not built before. Pages for Pros caps your design ceiling and pays for capability you already have in-house.

1 The team is the architecture

Every platform pitch on the market assumes a team that doesn't exist at SGA. They assume either (a) a senior platform engineering org, or (b) a marketing team with no in-house design or dev. SGA has neither. SGA has a hybrid: five AI-literate coders and a small visual-builder design team. That hybrid only fits two or three of the platforms in this category cleanly. The rest force you to hire, outsource, or accept slow velocity.

What this team can do well

CapabilityStrengthImplication
Visual page building Strong Designers are fluent in Webflow / WordPress block editors. Any drag-and-drop tool ramps in 2 to 4 weeks.
Component customization Strong AI-literate coders can extend any platform's component model with Claude or Cursor support. JS, CSS, and PHP customization is in range.
Integration glue Strong API integrations, webhooks, CallRail, Calendly, analytics. AI is at its best here.
Migration scripts Strong Going from Webflow / WordPress / HTML to a new platform: scraping, transforming, importing. AI accelerates this dramatically.
Greenfield platform architecture Weak This is the gap. A from-scratch multi-tenant CMS has architecture decisions AI will not catch. Decisions made in week 2 become irreversible by month 6.
Production DevOps at network scale Partial Deploying 260 production sites, monitoring uptime, rolling back bad publishes, security patching across a network. This is a discipline, not a skill.
Design system authoring (Figma) Partial 3-to-4-year designers from WP / Webflow backgrounds often have not built a multi-brand design system in Figma. Worth verifying.

How AI changes (and doesn't change) the math

AI gives this team roughly a 1.5x to 2x velocity multiplier on familiar territory. It does not turn coders into senior platform engineers. The decisions AI helps with (boilerplate, integrations, components, migrations) are not the decisions that determine whether a multi-tenant build succeeds at 260 sites. The decisions that matter (tenancy model, content schema, publishing workflow, brand governance) require seeing how this kind of system fails at scale. Your team has not seen those failures yet.

Design principle: Pick a platform where the architecture is already decided by someone who has run the same scale before. Spend your team's leverage on the surface area where dental practices actually compete: conversion patterns, local SEO, and brand storytelling.

2 The decision framework

Five dimensions decide this. Score each platform against these, weighted for the SGA team profile.

DimensionWhy it matters at 260 practicesWeight
Team fit Can the team you have actually ship and maintain it without burning out or hiring out? 30%
Multi-tenant publishing One change pushed to N sites without manual touch. The whole reason for consolidating off 4 stacks. 25%
Design ceiling How premium can the output look before the platform fights you? 15%
SEO and conversion control Schema, page speed, redirect handling, A/B testing surface. The growth lever. 15%
Total cost at 260 Platform + hosting + people, over 24 months. Not just the sticker price. 15%

3 Option deep dives

Duda
Visual builder built for multi-location publishing. The closest fit to this team.
Team fit9.0
Multi-tenant9.5
Design ceiling7.0
SEO control7.0
Cost at scale6.0

Tenancy model

One Duda account, one workspace, one master template, 260 child sites. The master-to-child template lock is the core feature: edit the master, push selectively or globally. Per-practice brand kits (logo, palette, fonts) sit on top of locked components. Local managers get scoped permissions and can only edit the elements you unlock. This is the cleanest out-of-box multi-tenant model on the market.

What the team does day-to-day

Designer Maria (WP / Webflow background)
Opens the Duda dashboard, picks Innovative Dental, edits the homepage hero visually, hits publish. Push takes 10 seconds. For a network-wide change (new "implant consult" CTA), she edits the master template, selects "push to all sites," reviews the diff, and publishes to 260 sites in one operation.
Coder Alex (AI-literate, mid-level)
Built the master template and dental component library in weeks 1 through 6. Today he is integrating CallRail dynamic number insertion as a custom widget, then wiring a Webhook from SGA's intranet to push new "doctor bio" content into the right practice site via Duda's API. Steady-state, 1 to 2 coders is enough.

Strengths for SGA specifically

  • Designers stay in their comfort zone. Duda's editor is closer to Webflow than to WordPress. Designers ramp in 2 to 3 weeks.
  • Real multi-tenant. Bulk operations, template inheritance, per-practice overrides, and permission scoping are first-class.
  • Local manager access. When a practice manager wants to update office hours or a doctor bio, you can give them scoped editing instead of routing it through your team.
  • Performance is handled. CDN, image optimization, AMP, automatic responsive. CWV scores are consistently good without intervention.
  • White label. The editor can be branded as "SGA Sites" or similar for practice-side access.

Weaknesses to know going in

  • Design ceiling. Duda's output is "professional and clean," not "stunning." If your design vision is editorial-grade or distinctive in the dental space, Duda will fight you. For the average dental practice this is fine. For flagship cosmetic / full-arch practices like Innovative Dental, you may want a custom build above Duda.
  • SEO is decent, not best-in-class. Schema requires custom widgets. 301 redirect management is workable but not great. URL structure controls are limited compared to WordPress.
  • Lock-in. Migrating off Duda means rebuilding. Plan for a 5-year horizon at minimum.
  • Custom code is sandboxed. Anything beyond simple JS widgets requires creative workarounds.
  • Per-site pricing. Real cost at 260 sites lands at $4K to $8K per month depending on plan and negotiation.

Realistic ramp

Wks 1 to 2
Procurement, Duda Enterprise contract, team onboarding to the platform.
Wks 3 to 6
Master template build. One designer plus one coder build the parent template with SGA design tokens and dental component library (call bar, scheduling, insurance widget, financing module, service line templates, doctor bio, before/after gallery, testimonial carousel).
Wks 7 to 8
6-site pilot. Migrate 6 practices off legacy stacks. Measure conversion lift vs control sites.
Wks 9 to 16
Iterate on the master template based on pilot data. Build content migration scripts for the bulk move.
Months 5 to 9
Bulk migration in waves of 30 to 40 practices. Two coders, two designers handling QA and per-practice customization.
Month 10+
Steady state: 1 coder, 1 to 2 designers for ongoing content, CRO testing, new service line launches.
WordPress Multisite + Bricks Builder
The modern WordPress play. Familiar substrate, owned asset, real cost control.
Team fit8.5
Multi-tenant8.5
Design ceiling8.5
SEO control9.5
Cost at scale9.0

Forget the 2018 WordPress you remember. The 2026 stack with Bricks Builder (or Breakdance, or the newer Etch) is a legitimate modern visual builder running on the most mature CMS substrate in the world. Heartland Dental, 42 North Dental, and Smile Brands all run versions of this. It is the most common DSO platform at SGA's scale, and it is the cheapest option per site over a 24-month horizon.

Tenancy model

One WordPress install with Multisite enabled. Each practice is a subsite with its own admin URL. Shared parent theme, shared plugin set, shared media library (optional). Network admin controls themes and plugins network-wide. Per-site overrides are allowed where you want them. WP-CLI scripts handle bulk operations.

What the team does day-to-day

Designer Maria (WP / Webflow background)
Already fluent in WordPress admin. Ramp to Bricks Builder from Webflow is 1 to 2 weeks because the mental model is similar (boxes, flex, grid, classes). Edits a service page on the Innovative Dental subsite visually. For a network-wide change she edits the template part in the parent theme and it propagates to all 260 subsites.
Coder Alex (AI-literate, mid-level)
Owns the parent theme, the Bricks component library, ACF field configurations, and the plugin governance discipline. Writes WP-CLI scripts for bulk content updates. Applies WordPress core, plugin, and PHP updates across the network on a monthly cadence. AI is highly effective here: Claude knows WordPress and PHP deeply, can generate ACF configs, custom Gutenberg blocks, and WP-CLI scripts with high accuracy.

Strengths for SGA specifically

  • You own the asset. Code, content, database, SEO equity. Move to any host, fork the theme, build custom anything.
  • Best-in-class SEO. RankMath or Yoast give you the most mature SEO toolset in the industry. Schema, redirects, sitemaps, internal linking all first-class.
  • Design ceiling is high. Bricks Builder is genuinely competitive with Webflow on output quality. Custom CSS, custom queries, dynamic data all supported.
  • Cost. Roughly $2K to $3.5K per month total at 260 sites (managed hosting + plugin licenses), versus $4K to $8K for Duda.
  • Designers already know WordPress. Onboarding is the fastest of any option.
  • Ecosystem. Every integration you might want has a battle-tested WordPress plugin. CallRail, Calendly, NexHealth, Weave, Care Credit, all already exist.

Weaknesses to know going in

  • Plugin sprawl is real. The biggest risk. Without discipline, you end up with 40 plugins per network, conflicts, slowdowns, and security holes. Plugin governance has to be a written policy, not vibes.
  • Performance is your problem. Default WordPress is slow. You have to invest in Cloudflare APO, Redis object cache, proper image optimization, and aggressive plugin minimalism. CWV is achievable but not automatic.
  • Security patching is ongoing. Monthly cadence at minimum. A skipped patch can compromise the entire network. This is a real operational discipline.
  • Bulk publishing is harder than Duda. Possible but requires WP-CLI scripting. Not a one-click operation by default.
  • Manager-facing editing is uglier. WordPress admin is functional but not as polished as Duda's manager-facing UI.

Hosting note

Do not self-host. Use Kinsta, WP Engine, or Rocket.net at the enterprise tier. They handle the security, scaling, and infrastructure layers that your team should not be in the business of running.

Builder.io
Visual builder on a headless backend. The most modern option, with real engineering cost up front.
Team fit6.5
Multi-tenant8.0
Design ceiling9.5
SEO control9.5
Cost at scale8.0

Builder.io is what you would build if you wanted Duda's marketer-friendly editor on top of a Next.js frontend you fully control. Marketers edit visually inside Builder's UI, but they edit components your engineering team has built and registered. The frontend is your code, hosted on Vercel or Cloudflare Pages. Whoop, Vimeo, Everlane, and other multi-brand orgs run on it.

Tenancy model

Builder organizes content via "Spaces" and "Models." For SGA, the cleanest model is one Space with a "Practice" tenant field on every content entry, paired with a Next.js shell that resolves the right tenant from the subdomain or path. The component library is shared across all 260 practices. Bulk publishing happens via Builder's API.

What the team does day-to-day

Designer Maria (WP / Webflow background)
Opens Builder.io, picks Innovative Dental, drags pre-built components (hero, service grid, insurance bar, testimonial carousel) into a page. Edits copy and images inline. Publishes to staging, then production. Ramp from Webflow is 3 to 4 weeks. The mental model is similar but the toolbox is different.
Coder Alex (AI-literate, mid-level)
Builds the Next.js shell in weeks 1 through 3 (auth, routing, tenant resolution, deploy pipeline). Builds the dental component library in weeks 2 through 6 in React + Tailwind, registered to Builder. AI is at its most effective here. Steady state is 1 to 2 coders maintaining the component library and integrations.

Strengths for SGA specifically

  • Highest design ceiling. Whatever you can build in React, you can ship as a Builder component. Best in this category on output quality.
  • Best performance. Next.js + static generation + CDN. CWV will be excellent.
  • Full SEO control. Schema, redirects, sitemap, structured data all coded by you.
  • AI leverage is highest. Next.js + React + Tailwind is the AI sweet spot. Claude can ship most of the component library with minimal human guidance.
  • Long-term ownership. The frontend is your code. If Builder.io ever stops working for you, you swap the CMS underneath without rebuilding the frontend.

Weaknesses for this team specifically

  • Initial engineering investment is real. 4 to 8 weeks before site 1 launches, vs. 6 weeks on Duda or WordPress. AI shortens this, but architectural decisions still need careful design.
  • You become the platform team. Auth, deploy pipeline, monitoring, tenant routing, multi-environment management all become your problem.
  • Designers depend on engineering. Any new component pattern requires a coder to build and register it. Designers cannot freely innovate the way they can in Duda or Bricks.
  • Builder.io is younger. Well funded, real production traction, but less proven than Duda or WordPress. Vendor risk is non-zero.
  • No experienced senior on the team. An architectural mistake in the tenant resolution layer or component model could cost 6 months to fix. This is the specific risk AI does not solve.
The honest read: Builder.io is the right answer for this team in 18 months, after you have run Duda or WP Multisite for a year, learned where its limits are, and built design system muscle. Starting here today asks your coders to make architectural decisions they have not earned the right to make.
Custom headless (Next.js + Payload, or Astro + Sanity)
Maximum ownership, maximum design ceiling, maximum risk for this team.
Team fit3.5
Multi-tenant6.5
Design ceiling10
SEO control10
Cost at scale5.0

Build the CMS, the frontend, the multi-tenant model, the editor experience, and the integrations yourself. Highest ceiling on every dimension that matters technically. But the time-to-site-1 is 4 to 8 months for this team, and the maintenance burden is permanent.

Why I am ruling it out for SGA today

  • The decisions that matter (tenancy isolation, content schema, editor UX, publishing workflow, deploy pipeline, rollback strategy) require experience this team has not had. AI does not catch these mistakes.
  • Designers will be blocked on engineering cycles for every change. The "marketer publishes a new page" flow that takes 5 minutes in Duda becomes a 3-day ticket here.
  • The 90 percent case (260 practices each running a similar dental playbook) does not need custom architecture. The 10 percent case (flagship cosmetic practices needing distinctive design) is better solved by building those 5 to 10 sites custom and putting the other 250 on a platform.
  • Maintenance burden is permanent: framework upgrades, dependency security, infra monitoring, on-call. None of which advance the dental growth thesis.

Custom headless is the right answer once SGA has either (a) hired a senior platform engineer with multi-tenant scars, or (b) outgrown the design ceiling of the chosen platform. Neither is true today.

Pages for Pros
Dental-specialist platform. Excellent product, wrong fit for SGA's org shape.
Team fit3.0
Multi-tenant5.0
Design ceiling6.0
SEO control8.5
Cost at scale5.0

Pages for Pros is the best-in-class dental-specialist platform for groups that do not have in-house design or engineering. Conversion patterns are tested, dental schema is built in, the playbook works. For a 5-practice or 20-practice group with no internal team, this is the right answer. For SGA, you would be paying for capability you already have.

Why it is not the right fit for SGA

  • Caps below 260 in practice. Their largest deployments are in the 50-to-100-practice range. Operationally, your scale will stress their model.
  • No in-house design lever. The whole pitch is "we author the templates." SGA has designers who should be authoring SGA's templates.
  • Permanent ceiling on brand differentiation. Every Pages for Pros site looks like a Pages for Pros site. Adequate for the average practice; inadequate for the flagship.
  • Asset ownership question. Their model leans toward "we host and run it." Migration off later is painful.
  • Designer and coder underutilization. The team you have built would atrophy.
Where Pages for Pros still earns a look: as a transitional layer for the 30 to 50 practices you cannot prioritize for in-house migration in the first 12 months. Park them on Pages for Pros now, migrate them to the chosen primary platform in year 2.

4 Side-by-side comparison

Dimension Duda WP + Bricks Builder.io Custom Headless Pages for Pros
Team fit for SGA 9.0 8.5 6.5 3.5 3.0
Designer ramp time 2 to 3 wks 1 to 2 wks 3 to 4 wks N/A (blocked on dev) 1 wk (training)
Time to first site live 6 to 8 wks 6 to 10 wks 8 to 12 wks 16 to 32 wks 3 to 4 wks
Bulk publish capability Native WP-CLI scripted API + tooling You build it Limited
SEO ceiling Decent Best in class Best in class Best in class Strong (dental-tuned)
Design ceiling Pro / clean High Very high Unlimited Pro / generic
Local manager editing Excellent Good Good (with config) You build it Limited
Monthly cost at 260 $4K to $8K $2K to $3.5K $1.5K to $3.5K $1K to $3K + people $8K to $15K+
Asset ownership Vendor Full Frontend yours, CMS vendor Full Vendor-heavy
Migration off later Hard Easy (WP is portable) Frontend easy, content scriptable N/A (you own it) Hard
AI leverage value Low (platform handles most) High (Claude is fluent in WP) Highest (Next.js sweet spot) Highest, but risky None

5 The senior designer's read

Stepping back from the platform comparison: the question you actually need to answer first is what your design system looks like. The platform is the delivery mechanism. The design system is the asset. Treat them in that order.

What SGA needs to author before the platform decision

  1. SGA parent brand tokens. You already have these from the PCCD GTM deck (blue, lime, orange, Fraunces, Inter, JetBrains Mono). Codify them as a documented design system, not just a style guide PDF.
  2. Per-practice brand layer. A predictable schema for how each practice expresses itself within the SGA system: primary color, secondary, doctor headshots, practice photography, locality voice. You already have this for the 68 Gen4 brands. Extend the schema to all 260.
  3. Dental component library. The 20 to 30 components every dental practice page needs: hero with primary CTA, sticky call bar, online scheduling embed, insurance accepted grid, financing widget, service line grid, doctor bio, before / after gallery, review carousel, locations map, FAQ accordion, sticky form, emergency banner. These are platform-agnostic specs.
  4. Page templates. Home, service line landing pages (implants, ortho, general, emergency, ped, cosmetic), about, locations, contact, financing, insurance, new patient form, blog. Roughly 15 to 20 page types.
  5. Conversion patterns playbook. The dental-specific patterns Pages for Pros has tested. SGA needs to author this in-house using your audit data, attribution flow, and paid media reporting. This is your real moat.

Author all of the above in Figma in the first 4 to 6 weeks. Then implement on whichever platform you choose. If you flip the order (pick the platform first, design inside it), you end up with a design system that is shaped by the platform's limits rather than by what dental practices actually need to convert.

The platform is rented infrastructure. The design system, the component library, and the conversion playbook are your assets. Make sure those are portable.

6 Recommended path

  1. Author the SGA design system in Figma. (Weeks 1 to 4)
    2 designers full-time, 1 senior consultant for review. Tokens, components, page templates, conversion patterns playbook. Output is platform-agnostic and survives any future migration.
    Owner: Lead designer Output: Figma library + component spec doc
  2. Run paid pilots on Duda and WordPress + Bricks. (Weeks 3 to 8, in parallel)
    3 practices on each platform. Same component spec, same content, same paid traffic. Measure form fills and tracked calls per 1,000 sessions over 30 days. Decide on data, not vendor pitch decks.
    Owner: Dakota + 1 coder per platform Output: head-to-head conversion data
  3. Commit to one platform by week 9. (Week 9)
    Single decision, written memo, sign-off from Dakota and Scott. From this point forward, everything ships on the chosen platform. No optionality.
    Owner: Dakota Output: decision memo
  4. Build the production master template and component library. (Weeks 9 to 16)
    2 coders + 2 designers, full-time. Output is a master template, 12 to 18 dental components, and migration scripts for the legacy stacks.
    Owner: Lead coder Output: production master + migration tooling
  5. Migrate in waves of 30 to 40 practices. (Months 5 to 9)
    Wave 1: 30 lowest-traffic practices (lowest risk). Wave 2: 30 mid-traffic. Subsequent waves scale up. Two coders, two designers in steady-state migration mode. QA gate before each wave.
    Owner: PM + lead designer Output: 260 practices migrated by month 9
  6. Transition to growth mode. (Month 10+)
    1 coder, 1 to 2 designers maintain the platform. The freed-up team capacity flows into the CRO program, new service line launches, paid media landing pages, and brand storytelling work.
    Owner: Dakota Output: ongoing growth program

7 Gaps to address before kickoff

GapRisk if unaddressedFix
No senior designer who has built an enterprise design system Component library will under-perform; CRO program will be capped by inconsistent patterns Hire one senior design system lead, or engage a fractional senior for the first 12 weeks
No platform engineer with multi-tenant scars Architectural mistakes in months 1 to 3 become 6-month rewrites in month 12 Pick Duda or WordPress + Bricks (architecture is decided). If picking Builder.io, hire one senior platform engineer.
No documented conversion playbook You buy Pages for Pros' playbook by accident instead of authoring SGA's Spend 2 weeks documenting the patterns: what converts on a dental homepage, a service page, an insurance page, a financing page. Use audit data + attribution flow data + paid media reporting.
No QA process for 260-site publishing One bad template push breaks the network Define a staging-to-production gate. Bulk pushes go to staging first, smoke-tested via a checklist, then promoted in waves.
No plan for the flagship practices that need distinctive design Innovative Dental, Ressler, and other cosmetic-led practices outgrow the template Reserve 5 to 10 practice slots for custom builds outside the platform. Build them on Next.js with the same design system tokens.

8 One-line summary per stakeholder

AudienceThe pitch
Dakota (you) Duda lets us consolidate 260 sites onto one operating system in 9 months with the team we have, and frees the growth team to focus on CRO instead of platform engineering.
Scott (IT / leadership) One vendor relationship, one billing line, one security surface, one publishing system. $4K to $8K per month at full scale. Replaces four stacks.
The design team Your skills transfer directly. Designers publish without engineering cycles. The design system you build in Figma drives the platform, not the other way around.
The coders You build the SGA dental component library, the integrations, and the migration tooling. You are not on the hook for platform architecture or 260-site infrastructure.
Practice managers You get scoped editing for office hours, doctor bios, and announcements. Major changes still route through SGA growth.