Strategy Memo · Confidential
SGA Dental PartnersGrowth · 2026.05.19
The Website Operating System.
A technical platform decision for SGA's next wave of practice sites. Built for portfolio scale, designed for a non-engineering team, ready for engineer review.
Strategy Memo · Executive Summary
00Executive Summary
Duda is the operating system for new SGA practice sites. Not a re-platform of the 260 we already run.
SGA owns the brand and the design. Duda owns the multi-tenant CMS, schema, render, and host. We pilot on 3 to 5 brands, measure six numbers, and decide at Q4 with a clean exit path if the data does not move.
01
Scope
New builds, flagship rebuilds, and due-anyway sites. Not all 260.
Working sites stay where they are. The OS only runs the next wave: every new acquisition, every cosmetic or full-arch flagship rebuild, every site already due to be redone for performance or SEO reasons.
Why it matters. A common OS means one fix ships to every site on it. Today, every change is one of 260 one-offs.
02
Recommendation
Duda, because it does the parts we are not equipped to maintain.
Mature multi-tenant infrastructure (15+ years, used by Yelp, AT&T, Vistaprint for SMB platforms). Native multi-site management, REST API for programmatic creation, marketer-friendly editor. Vendor lock-in is the trade we accept.
Score. 91 / 100 (Grade A). Builder.io next at 75. PagesForPros at 55 due to early-stage infrastructure.
03
Path
90-day pilot. Six numbers. Decision gate at Q4.
3 to 5 pilot brands on Duda. Two parallel workstreams: Duda pilot (Growth) and SGA design layer formalization (Mike). If the metrics move, we scale. If they do not, we exit cleanly and stay with agency builds.
Reversible. Pilot exit at day 90 with no portfolio commitment beyond the 3 to 5 sites in scope.
Today's Asks
01Align on scope: not a 260-site re-platform.
02Greenlight the Duda pilot.
03Formalize Mike's design layer, do not build internal platform.
Executive Summary
02—18
Section 01 · Today's State
01Today's State · What We Are Actually Solving
260 sites today. Most stay where they are. The OS runs only what comes next.
Today's portfolio is fragmented by years of growth through acquisition. Most of it works and brings patients in. We pick an operating system for the next wave: new acquisitions, flagship rebuilds, and sites already due for replacement.
Today · The Portfolio
260
Relative mix shown for orientation. Specific counts unverified; bar is illustrative.
Stays
If a site converts patients and stays branded, it stays. We do not touch what works.
In Scope
The OS only runs what comes next.
1
Every new practice acquisition from here forward.
2
Every flagship brand-critical rebuild, when timing is right.
3
Every site we are already paying to redo anyway.
Excludes
Mass migration. Re-platforming for its own sake. Anything that already works.
Bucket 01
New practice acquisitions
Every practice SGA brings in from here. Gen4 acquisitions and the next wave. Built on the chosen OS from day one.
Bucket 02
Brand-critical flagship rebuilds
Cosmetic, full-arch, multi-location, and high-revenue practices that need premium presence. Rebuilt on the OS when the timing is right.
Bucket 03
Sites due for rebuild
Anything we are already paying to redo for performance, SEO, or design reasons. The OS catches that work as it comes through.
Today's State
03—18
Section 02 · The Real Decision
02The Real Decision · Choose The Right Question
The decision is not which website builder to use. It is which operating system runs the next wave.
Most teams approach this as a builder choice: Webflow, WordPress, or something else. That choice is downstream. The platform decision sits above it, and is what determines whether we can scale SEO, govern brand, and ship components across a growing portfolio.
Not This Question
Which website builder should we use?
Reframe
The Real Question
What operating system powers the next wave of practice sites SGA builds?
Decision Criteria
Scalable SEO
+
Central Governance
+
Team Fit
+
Marketer Velocity
+
Platform Maturity
The Real Decision
04—18
Section 03 · Anatomy
03Anatomy · How A Website Platform Actually Works
Every modern website platform is three layers: design intelligence, content schema, and rendering.
The fragmented stacks SGA runs today collapse all three layers into the same vendor, per site. Separating them is what makes a system scale, because each layer can be improved or replaced without redoing the others.
01
Design
How a page looks
Mike's tool lives here. Generates layouts, applies brand rules, picks fonts and logos, outputs structured HTML from recipes.
This layer owns
- Layout recipes & components
- Brand rules, logos, fonts
- Section & page generation
- HTML / CSS / template output
Templates +
Content
Content
02
Content
What the page says
The CMS is the database for editorial. Holds the words, structured data, and schema that make a page indexable and a section reusable.
This layer owns
- Page title, slug, meta
- H1, H2, FAQs, schema fields
- Service & location data
- Internal links & CTAs
Page Data +
Schema
Schema
03
Render
How the page ships
The publisher turns data into live pages. This is where the choice between Duda, Builder.io, Webflow, WordPress, or headless actually matters operationally.
This layer owns
- Live page render & build
- Sitemap & canonical rules
- GTM, GA4, pixels
- Hosting, CDN, redirects
The Move
Build the design layer once, in our voice. Let a vendor own the content and rendering layers. Each layer is replaceable independently.
Anatomy
05—18
Section 04 · Options Considered
04Seven Options Considered · Side By Side
Seven platforms evaluated. Duda leads on the dimensions that matter to a team like ours.
Scoring weights team fit, platform maturity, and central rollout heavily because a platform that demands engineering operations or is still pre-scale does not work for SGA. Duda's 15-year track record and native multi-site model carry the day.
Overall fit score, weighted by what matters to a team like ours
0 — 100 scale · Higher is better
Scoring WeightsSum to 100%
Programmatic SEO at scale15%
Central component rollout15%
Team fit (no engineers)15%
Marketer-friendly editing12%
Platform maturity10%
Fit for our scope10%
Tracking + schema control8%
Multi-brand individuality5%
Time to first pilot5%
Vendor lock-in risk5%
Reading the chart
★ Leader · Duda
91 / A. Wins on team fit, multi-site rollout, and maturity. Used by Yelp, AT&T, Vistaprint for SMB platforms.
Runner-Up · Builder.io
75 / B. Best fit if we ever need a headless visual editor with AI workflow. Needs a Next.js frontend to maintain.
Tail · PagesForPros & Internal Engine
55 and 54. Both lose on platform maturity. PagesForPros is pre-scale. Internal engine has no team to build it.
Seven Options
06—18
Section 05 · Option 01 · Duda
Recommended
05·01Option 01 · Duda (Multi-Tenant Platform)
Mature multi-tenant infrastructure built for portfolio operators. The best practical fit for SGA.
Duda is a 15-year-old white-label platform used by Yelp, AT&T, Vistaprint, and ~22,000 agencies to manage many sites from one dashboard. Native multi-site model, REST API for programmatic site creation, marketer-friendly editor, no engineering required to operate.
Data Flow · Duda Architecture
Multi-site is native. One dashboard, many sites, central rollout.
Inputs
Practice intake
Brand kit, services, locations, copy. Posted via API or CSV.
REST + CSV
POST
/sites
/sites
Duda Cloud
Multi-site manager
Site provisioning, template assignment, team roles, central template rollout.
Sites API
template
assign
assign
Duda Editor
Editor + templates
Visual editor (React), reusable site templates, dynamic page templates, AI assist.
Editor v2
publish
Surfaces
CDN + live sites
Auto SSL, edge cache, custom domains. Lead forms, tracking, schema all native.
Edge + SSL
Tech Stack
React Editor
REST API v2
OAuth 2.0
Webhooks
SSO / SAML
Multi-tenant native
White-label
91/ 100
A ★
Mature. Multi-tenant. Made for portfolio operators like SGA.
What works for SGA5 wins
- 01Native multi-site management. Manage 1 or 10,000 client sites from one dashboard. SGA's exact need.
- 02Mature infrastructure. 15+ years. Used by Yelp, AT&T, Vistaprint. Real scale, real uptime.
- 03Sites API. Programmatic site creation, content updates, webhook events. Engineer-friendly surface.
- 04Central template rollout. Update a template once, push to all sites that use it. First-class capability.
- 05Marketer-friendly editor. Practice teams edit pages without a ticket. Zero engineering burden.
What we accept2 risks
- 01Vendor lock-in. Exit cost is the trade. Validated as a pilot KPI (content export, redirect map).
- 02Lower design ceiling than Webflow. Editor is constrained vs. designer-grade canvas. Acceptable for portfolio scale.
Option 01 · Duda · Recommended
07—18
Section 05 · Option 02 · Builder.io
05·02Option 02 · Builder.io (Visual Headless + AI)
Visual headless CMS with AI design workflow. Strong runner-up if we go more technical.
Builder.io is a Series-B-funded visual editor sitting on top of a headless API. Used by Vimeo, Everlane, Atlassian. Multi-tenant via Organizations + Spaces. The trade: we maintain a Next.js frontend, which puts the editor experience on our side of the line.
Data Flow · Builder.io Architecture
Visual editor + headless API. Frontend code lives with us.
Inputs
Editor + AI gen
Visual editor with drag-drop. AI-powered design generation from prompts or Figma.
Visual + AI
save
content
content
Content Hub
Builder.io Spaces
Typed content models, Organizations + Spaces for multi-tenancy, versioning, A/B logic.
GraphQL + REST
fetch
via SDK
via SDK
Frontend
Next.js + Builder SDK
We host. React components, ISR, App Router. SDK handles visual editor binding.
SGA-Hosted
edge
cache
cache
Surfaces
CDN + live sites
Vercel/Cloudflare edge. Multi-site routing via Builder's tenant filter.
Edge + CDN
Tech Stack
Visual Editor (React)
REST + GraphQL
@builder.io/react
Next.js 14+
Multi-tenant via Spaces
OAuth + API key
75/ 100
B
Strong technical choice. But the Next.js frontend is on us.
What works4 wins
- 01AI-first workflow. Generate sections from prompts. Matches Mike's existing creative workflow.
- 02Visual editor on headless. Marketers edit. Engineers control the rendered output.
- 03Multi-tenant primitives. Orgs + Spaces give per-practice content isolation.
- 04Lower lock-in. Content is API-accessible. We could migrate off without a vendor escape.
What it asks of us3 risks
- 01Frontend is ours to maintain. Next.js codebase, deploy pipeline, performance tuning. Eng-heavy.
- 02Slower time-to-pilot. First site lands in weeks, but only after the frontend is built. 1-2 months from zero.
- 03Multi-site templating. Less first-class than Duda. We design the per-tenant theming pattern.
Option 02 · Builder.io
08—18
Section 05 · Option 03 · Webflow
05·03Option 03 · Webflow Standardization
Designer-grade canvas, marketer-friendly editing. Brittle at portfolio scale.
Webflow gives every practice a beautiful visual editor. The problem is governance: every site is its own Workspace, with no native cross-site rollout. Per-seat pricing scales linearly with site count. Workspaces v2 is in alpha but not production-ready.
Data Flow · Webflow Architecture
One Workspace per practice. Operated independently.
Inputs
Designer + marketer
One human per practice doing visual edits in the Webflow canvas.
Per Practice
edit
× 260
Webflow
Designer + CMS
A separate visual canvas per practice. Per-seat licensed. No shared component layer.
CMS API v2
render
× 260
Webflow Cloud
Render + host
Webflow's renderer and hosting. Custom code injection works. Runtime is theirs.
Vendor-Hosted
publish
Surfaces
Live sites
Each site managed and billed independently. Per-seat cost scales linearly.
Per-Site Plan
Tech Stack
Webflow Designer (proprietary)
CMS API v2 (REST)
OAuth 2.0
Custom Code Injection
Multi-tenant: ✗
Workspaces v2: alpha
64/ 100
C+
Pretty. Doesn't scale to a 260-site portfolio.
What works3 wins
- 01Best-in-class design control. Designer-grade canvas with strong responsive behavior.
- 02Marketer-friendly editing. Non-technical edits ship without engineering.
- 03Custom code injection. GTM, GA4, Meta Pixel, schema all natively supported.
What breaks at scale3 risks
- 01No native multi-site. 260 separate Workspaces to govern. Workspaces v2 still in alpha.
- 02Programmatic SEO limits. Mass city and service page generation gets clunky at thousands of pages.
- 03No global component sync. Update once, deploy everywhere is not a native workflow.
Option 03 · Webflow
09—18
Section 05 · Option 04 · WordPress
05·04Option 04 · WordPress (Multisite or Per-Site)
Deepest CMS ecosystem on the planet. Drift and plugin debt compound at scale.
WordPress has mature plugins for every SEO concern and a battle-tested REST API. Without strict template governance, 260 sites become 260 different stacks over time. WP Multisite reduces some of this but introduces its own constraints around themes, plugins, and database isolation.
Data Flow · WordPress Architecture
Plugin layer is where debt accumulates over years.
Inputs
Editor + marketing ops
Familiar admin interface. Almost zero onboarding cost for content teams.
Per Practice
REST
× 260
WordPress
WP admin + theme
Per-site PHP install. REST API for writes. Each install diverges over time.
PHP + MySQL
load
plugins
plugins
Where debt compounds
Plugin + theme soup
Per-site plugin stacks. Updates and conflicts compound across the portfolio.
YoastSchema ProWP RocketACF ProRedirectionGA4+ theme
serve
Surfaces
Live sites
Same logo. 260 different stacks under the hood. Variable performance per host.
Host-Specific
Tech Stack
PHP + MySQL
WP REST API
WP-CLI
Application Passwords
Multisite: built-in (limited)
Plugin marketplace
70/ 100
B-
Familiar. Drifts at scale.
What works3 wins
- 01Deepest SEO plugin ecosystem. Schema, sitemaps, redirects all mature.
- 02Mature REST API. External systems can author content programmatically.
- 03Zero editor onboarding. Practice teams already know the interface.
What breaks at scale3 risks
- 01Plugin debt over time. Performance and security degrade as plugins stack up.
- 02Governance drift. Without enforcement, 260 sites become 260 different stacks.
- 03No design enforcement. Component systems require ground-up discipline.
Option 04 · WordPress
10—18
Section 05 · Option 05 · Headless + Next.js
05·05Option 05 · Headless CMS + Next.js
Engineered for scale. Requires the engineering bench we don't have.
Content lives in one headless CMS (Sanity, Contentful, Hygraph). A React frontend renders the site. Best architectural fit for programmatic SEO at scale, but demands real engineering operations and an editor experience we have to build ourselves.
Data Flow · Headless Architecture
One content brain. One build pipeline. Fans out to many sites.
Inputs
Editor + API writers
Humans and machines author into one central content brain.
Centralized
save
Layer 02 · CMS
One headless CMS
Sanity, Contentful, or Hygraph. Single source of truth. Typed schema, versioning, webhooks.
GraphQL + REST
build
SSG / ISR
SSG / ISR
Layer 03 · Build
Next.js pipeline
Static or incremental render. Sitemap, schema, routing fully owned. CWV native.
Vercel / Edge
CDN
Surfaces
Live sites
Edge-cached. Multi-site via tenant fields in the CMS schema.
SGA-Hosted
Tech Stack
React + Next.js 14
Sanity / Contentful / Hygraph
GraphQL + Webhooks
Vercel / AWS
Multi-tenant via schema
NextAuth / SSO
68/ 100
B-
Strong architecture. Too eng-heavy for our team.
What works3 wins
- 01Enterprise SEO control. Schema, canonicals, sitemaps fully owned.
- 02Programmatic SEO native. Built for multi-location at scale.
- 03Core Web Vitals out of box. Static + incremental render = fast pages.
What it asks of us3 risks
- 01Real engineering required. Frontend, infra, pipelines, admin tools. Multi-engineer team.
- 02Months to first pilot. First site lands in months, not weeks.
- 03Editor UX is on us. Marketer experience is something we design and ship.
Option 05 · Headless + Next.js
11—18
Section 05 · Option 06 · PagesForPros
Early-Stage Risk
05·06Option 06 · PagesForPros (Early-Stage Multi-Tenant)
Shape of the problem is right. Infrastructure and scalability are unproven.
PagesForPros is conceptually close to what SGA needs: a multi-tenant platform built for local service businesses with many sites. The problem is timing. The platform is just getting off the ground, and we cannot validate infrastructure, scalability, or production maturity at the level a 260-site portfolio operator needs.
Data Flow · PagesForPros Architecture
Conceptually similar to Duda. Maturity gap is the issue.
Inputs
Practice intake
Brand kit, services, locations, copy. Sent into the platform.
Per Practice
create
site
site
Vendor · Pre-Scale
PagesForPros platform
AI templates + multi-tenant CMS + render + host, bundled. Just getting off the ground. Production infrastructure, SLA, and scale-tested architecture not yet validated.
Maturity TBD
publish
Surfaces
Live sites
Few sites in production today. Unverified at 100+ scale.
Early Adopter
Diligence Open
Production SLA?
Scale-tested at 1000+ sites?
Runway / funding stage?
API stability?
Exit path?
55/ 100
C-
Right concept. Wrong stage of maturity for our risk profile.
If it were mature2 wins
- 01Conceptual fit. Multi-tenant platform for local service portfolios is exactly our shape.
- 02Team fit (if it works). Would not require engineering operations on our side.
Why not now4 risks
- 01Pre-scale infrastructure. Production capacity unproven. Cannot validate at 100+ sites.
- 02Platform maturity. Just getting off the ground. Vendor stability is the bet we'd be taking.
- 03SLA + uptime unproven. No production track record for portfolio-grade availability.
- 04Concentration risk. Tying SGA's new builds to a pre-scale vendor is a meaningful bet.
Option 06 · PagesForPros
12—18
Section 05 · Option 07 · Internal Engine
High Team-Fit Risk
05·07Option 07 · Internal Design Engine + Multi-CMS Publishing
Highest theoretical ceiling. Riskiest for a team like ours to actually run.
Build our own design engine and publish to multiple back-ends. In theory: total ownership, zero lock-in, full SEO control. In practice: the schema layer becomes ours to maintain across years, with no dedicated engineering bench to keep it on the rails.
Data Flow · Internal Engine Architecture
Every box here is a system we build and maintain.
54/ 100
C-
High ceiling. Not for our team's operating reality.
If we could build it3 wins
- 01Total ownership. One system enforces structure, SEO, brand. Forever.
- 02Any renderer fits. Webflow, WP, headless, static. All swappable.
- 03Zero vendor lock-in. No outside dependency for the core platform.
Why we can't3 risks
- 01No dedicated engineers. 2 junior web devs, a creative director, Dakota. AI-assisted, not engineering-led.
- 02The schema is the trap. Maintaining a neutral page schema is a multi-year cost we cannot carry.
- 03Vibe-coded systems decay. No bench to keep an internal platform on the rails.
Option 07 · Internal Engine
13—18
Section 06 · Comparison
06Side-By-Side Comparison · Weighted Scoring
Duda leads on 8 of 10 dimensions that matter to a team like ours.
Scoring weights team fit, central rollout, and platform maturity heavily because a platform that demands engineering operations or is still pre-scale does not work for SGA. Internal engine and PagesForPros drop sharply on those axes.
Capability · Weight
01 ★
Duda
02
Builder.io
03
WordPress
04
Headless+Next
05
Webflow
06
PagesForPros
07
Internal Engine
Programmatic SEO at scale15%
Excellent
Excellent
Good
Excellent
Limited
Unproven
Excellent
Central component rollout15%
Excellent
Good
Limited
Excellent
Weak
Unproven
Excellent
Team fit · zero engineers15%
Excellent
Limited
Strong
Weak
Strong
Good
Critical
Marketer-friendly editing12%
Excellent
Good
Excellent
We Build
Excellent
Good
We Build
Platform maturity10%
Excellent
Good
Excellent
Good
Excellent
Pre-Scale
Greenfield
Fit for our scope10%
Strongest
Strong
Partial
Strong
Partial
Conceptual
Theoretical
Tracking + schema control8%
Good
Excellent
Good
Excellent
Good
Good
Excellent
Multi-brand individuality5%
Strong
Strong
Good
Good
Excellent
Good
Excellent
Time to first pilot5%
Weeks
1-2 Mo
Weeks
Months
Weeks
Weeks
Quarter+
Vendor lock-in risk5%
Medium-High
Low
Low
Low
Medium
High
None
Overall ScoreWeighted by our team
91
A ★
Mature, multi-tenant.
75
B
Strong runner-up.
70
B-
Drifts at scale.
68
B-
Too eng-heavy.
64
C+
Pretty. Per-site.
55
C-
Pre-scale risk.
54
C-
Team-fit risk.
Scale
Excellent
Good
Limited
Concern
Weak
Source: SGA Growth analysis · Scores assigned per dimension, weighted to 100% · Vendor pricing and API capability validated against public docs as of 2026.05
Side-By-Side Comparison
14—18
Section 07 · The Recommendation
07The Recommendation · Why Duda
Duda, because it does the hard parts we are not equipped to maintain ourselves.
Four reasons make this the right call. Three trades we accept. None are theoretical: they reflect the reality of running a 260-site portfolio with a creative team plus AI agents and no dedicated engineering bench.
Why DudaFour reasons, in order of weight
01
Team fit. Built for non-engineering operators.
We have 2 junior web devs, a creative director, Dakota, and an AI agent fleet. Duda handles multi-site infrastructure, CMS, schema, render, host, and SEO modules. No backend to maintain. No frontend to deploy. The platform is operated by marketers.
Evidence · +35 pts on team-fit dimension
02
Platform maturity. 15 years, real infrastructure.
Duda powers SMB platforms for Yelp, AT&T, Vistaprint, and ~22,000 agencies. SOC 2, 99.9% SLA, edge CDN, native multi-region. The infrastructure question is answered. PagesForPros loses 35 points here.
Evidence · SOC 2 Type II · 99.9% SLA
03
Multi-site is native. Not bolted on.
Sites are a first-class entity in the Duda model. POST /sites creates one. PATCH /templates/{id} pushes a component to every site that uses it. Webflow and WordPress at 260 instances do not give us this. Duda does, by design.
Evidence · Sites API + Template inheritance
04
Speed to value. Weeks, not quarters.
Multi-tenant means the platform is ready. First pilot site stands up in weeks. Mike's design layer feeds Duda templates. Headless takes months. Internal engine takes a quarter for the first adapter and years for maintenance.
Evidence · First site < 30 days
The Trades We Accept
Vendor lock-in, contained by scope
Duda owns the runtime. We contain the risk three ways.
01
Scope limit. Not all 260 sites. Only new builds, flagships, and due-anyway rebuilds.
02
Exit validated in pilot. Content export + redirect map are measured pilot KPIs, not assumptions.
03
Brand stays ours. Mike's design layer feeds Duda templates. SGA owns the brand input.
Two Other Trades
Design and SEO ceilings, accepted at this scale
A
Lower design ceiling than Webflow. Editor is more constrained. Acceptable for portfolio rollout.
B
Lower SEO ceiling than headless. Schema customization is configurable, not unlimited.
Bottom Line
A platform that does the hard parts so a small team can move at portfolio scale. The trades are intentional.
Recommendation · Duda
15—18
Section 08 · Architecture
08Architecture · How It Works End To End
SGA owns the brand and the design layer. Duda owns the schema, the render, and the plumbing.
Two clean boundaries. SGA work lives in the brand and design layer (mostly already in motion via Mike's tool). Duda owns the multi-tenant CMS, schema, render, and host. Surfaces are the sites that come out the bottom.
SGA-Owned
What we build and maintain ourselves
Brand, design intelligence, content. Within our team's range. Mike's tool already partly built.
SGA · 01
Brand standards
Logos, color, type, voice, photography. Per-practice overrides allowed. Lives in shared kit.
JSON tokens + Figma
SGA · 02
Design engine · Mike's tool
AI-assisted layout generation, component library, brand-enforced HTML templates. Already working.
Outputs Duda templates
SGA · 03
AI content generation
Service descriptions, FAQs, location pages drafted by AI, reviewed by creative, posted via Duda API.
POST /pages
Brand-Enforced Templates + Content
Duda Platform
What the platform handles for us
Multi-site manager, CMS, SEO modules, render, host, tracking. We configure. They keep it on the rails.
Duda · 01
Multi-site manager
Sites API. Provision a site, assign a template, set the domain. Central dashboard for all SGA sites.
Sites API v2
Duda · 02
CMS + schema
Page types, fields, schema.org markup. Dynamic page templates for service and location at scale.
Collections API
Duda · 03
Render + host
Auto SSL, edge cache, custom domains, redirects. We do not run infrastructure.
Edge CDN + SSL
Duda · 04
Tracking + SEO
GTM, GA4, pixel injection, lead forms, sitemap generation, conversion records.
GTM + Webhooks
Publish to Edge CDN
Surfaces
What patients see
In-scope sites. The portfolio grows on the OS over time, not all at once.
In-scope
Every new acquisition, every flagship rebuild, every site we were going to redo anyway. Live, branded, tracked, consistent. Working sites stay where they are.
Architecture
16—18
Section 09 · The 90-Day Plan
09The 90-Day Plan · Two Parallel Workstreams
Workstream 01 runs the Duda pilot. Workstream 02 sharpens the design layer. Both converge at Q4.
No parallel platform build. The design-layer work is in our team's range and feeds Duda cleanly. If the pilot lands, we have brand-enforced templates ready to scale. If it doesn't, we kept the brand work and lost nothing.
Two tracks, four checkpoints, one decision
Day 0 — 90 · Q3 2026 → Q4 2026
Workstream 01Duda PilotOwner · Growth
Day 0 · KickoffSelect 3-5 brandsMix of geographies. Baselines captured.
Day 30Pilot sites liveStood up via Sites API. Tracking verified.
Day 60 · CheckpointFirst data readIndexing, CWV, operator hours, conversion.
Day 90Final readoutSix KPIs scored. Recommendation packaged.
Day 0
Day 30
Day 60
Day 90
★ Decision Gate
Workstream 02Formalize SGA Design LayerOwner · Mike + Dakota
Day 0 · KickoffAudit Mike's toolWhat it outputs. What's reusable now.
Day 30Brand documentedTokens, components, voice rules. Duda handoff package.
Day 60Duda templates readyService, location, FAQ templates. Brand-enforced.
Day 90Layer feeds pilotDuda consumes SGA-generated templates. Loop closes.
Day 90
⬥
★ Decision
Go · Refine · Kill.
Data decides.
Data decides.
KPI 01 · Performance
CWV all green
LCP < 2.5s on field data within 60d
KPI 02 · SEO
Indexed coverage
100% of city + service pages in 30d
KPI 03 · Conversion
Lead conversion
At or above current baseline by day 60
KPI 04 · SEO
Organic lift
Up vs. 90d pre-launch baseline
KPI 05 · Velocity
Publishing velocity
Template update edit-to-live time
KPI 06 · Ops
Operator hours
Per practice per month vs. current
Six numbers that decide it. No others. Joint readout to leadership at Q4 gate.
The 90-Day Plan
17—18
Section 12 · Decisions
12Decisions To Leave With Today
Three decisions, three asks. Each one unlocks the next phase of work.
Concrete and answerable. Scope, the Duda pilot, and the SGA design layer. If we land all three today, the team has a green light through Q4.
01
Aligned on the scope: new builds and strategic rebuilds, not a 260-site re-platform?
We are picking the OS that runs new acquisitions, flagship rebuilds, and sites due for replacement anyway. Working sites stay. Are we aligned on that scope?
The Ask · Yes or no
02
Greenlight the Duda pilot with 3 to 5 brands?
Duda owns the multi-site infrastructure, CMS, schema, render, and host. SGA owns brand input via Mike's design layer. 90-day window, six measured KPIs, decision gate at Q4. Authorize?
The Ask · Authorize pilot
03
Commit to formalize Mike's design layer, not build a parallel platform?
No internal engine build. Just sharpen what we already have so Duda can consume brand-enforced templates and AI content cleanly. Inside the same 90-day window.
The Ask · Formalize, do not build
Prepared by SGA Dental Partners Growth Team · Confidential
Decisions
18—18