Vye Growth OS · working thesis

From acquiring patients to building a learning growth system.

A first-pass blueprint for how Vye Growth could prove patient acquisition practice-by-practice, encode what works into software + AI, and eventually turn demand intelligence into a network advantage.

This is intentionally not a “final plan.” It is how I am organizing the problem before I have Vye’s internal data, architecture, legal decisions, economics and the lived truth of the first practice cohort.
01 · What I heard in the Vye thesis

Patient acquisition is not an agency layer. It is part of the Provider OS.

Vye’s promise is to let providers practice medicine while Vye handles launch, operations and growth. That makes the growth job less interesting if it becomes “manage a lot of ad accounts”—and much more interesting if the manual work becomes the training data for Vye Growth itself.

Prove acquisition one practice at a time → structure the learnings → encode repeatable work → route humans only to judgment and exceptions.
02 · Design principles

The automation target is operating leverage, not an AI percentage.

01

Prove before automating

Start hands-on with real practices. Instrument the work. Automate only after the operating truth is understood.

02

Software for repetition

Every deterministic, repeatable action should become software—not another recurring task for a marketer.

03

Agents for ambiguity

Use AI where judgment is useful: research, synthesis, creative hypotheses, anomaly diagnosis, and learning across practices.

04

Humans own consequences

Clinical claims, novel strategies, large capital moves, privacy decisions, and provider identity remain accountable human decisions.

05

Every action creates memory

Campaigns should not just produce patients. They should produce structured learnings that make the next practice easier to launch.

03 · The system map

Eight systems. One closed loop.

I would avoid a pile of disconnected “agents.” The system should have a small number of durable domains with clear inputs, outputs, owners, permissions and memory.

1

Provider Intelligence

Discover, enrich and understand providers before and after application.

Provider Twin · public footprint · interview brief · network fit
2

Market Intelligence

Map patient demand, competition, geography, language and unmet need.

Market Twin · keyword universe · competitor map · demand gaps
3

Practice Underwriting

Turn provider + market + economics + capacity into a launch thesis.

Positioning · budget ceiling · panel model · overlap score
4

Growth Production

Convert the thesis into assets and infrastructure.

Landing pages · search builds · social creative · SEO/AEO · provider content
5

Acquisition Execution

Deploy and optimize within explicit guardrails.

Google · Meta · local · budget pacing · creative rotation
6

Patient Lifecycle

Improve what happens after the click and after the booking.

Booking recovery · onboarding · no-show recovery · reviews · referrals
7

Network Optimization

Allocate demand and capital across the provider network.

Capacity routing · market expansion · provider recruiting signals
8

Governance + Learning

Keep the system safe, traceable and increasingly intelligent.

Claims registry · evals · approvals · experiments · reusable playbooks
04 · Provider Launch Twin

The application can become the first version of the practice.

Instead of a provider application creating another CRM row, it can trigger a structured launch twin: provider footprint, market opportunity, Vye overlap, initial practice thesis, content plan and capacity-aware acquisition model.

0–15m

Resolve

Identity, CV, specialty, license candidates, current footprint.

15–45m

Research

Market demand, competitors, keywords, patient language, Vye overlap.

45–75m

Underwrite

Capacity, economics, panel-fill scenarios, initial spend ceiling.

75–120m

Design

Positioning hypotheses, channel plan, LP brief, creative concepts.

Provider interview

Capture

Provider POV, stories, FAQs, voice, trust assets and differentiation.

+1–4h

Build

Draft landing page, Google/Meta campaigns, tracking, provider-led creative.

QA + approvals

Gate

Claims, rights, capacity, privacy, economics, tracking, budget.

≤24h

Launch

Go live—or hold with the exact blocker clearly surfaced.

The 24-hour promise should mean “launch-ready within 24 hours of hard dependencies being ready”—not “skip the hard dependencies.”
05 · Agent architecture

AI reasons. Deterministic software executes. Humans stay accountable.

A reasoning model should not directly improvise high-impact actions in an ad account. It proposes. A permissioned executor validates policy, capacity, budget and authority before acting.

Provider Intelligence

Who is this provider—and what makes them distinct?

Market Intelligence

Where is demand, how is it expressed, and how crowded is the market?

Growth Strategy

What is the strongest initial practice and acquisition thesis?

Content + Creative

What should this provider say, show and teach?

Acquisition Operator

How should campaigns be built, paced and optimized?

Lifecycle

How do we improve booking, attendance, retention and advocacy?

Network Intelligence

What does this practice teach us about where Vye should grow next?

Governance

Is the proposed action accurate, safe, permitted and within authority?

Growth Control Plane · illustrative daily view
Systems healthy

Needs a human

  • Approve a new provider positioning
  • Review a novel clinical claim
  • Resolve Texas capacity conflict
  • Approve a material budget expansion

Handled automatically

  • Negative keyword maintenance
  • Approved creative rotations
  • Broken UTM repair
  • Reporting + anomaly detection

Network signal

↓ human minutes
per activated patient while economics + quality hold
  • Demand exceeding available PCOS capacity
  • “Longer visits” emerging across markets
06 · Build vs buy

Buy commodities. Build Vye-specific intelligence.

Use / buy / integrate

Google Ads APIMeta Marketing APISearch + Maps dataNPPES + licensing sourcesLLM APIsTranscriptionCreative renderingCall/SMS infrastructureCloud PostgresWorkflow + observability primitives

Build as Vye IP

Provider TwinMarket TwinPractice UnderwritingCapacity-aware Growth EngineNetwork Overlap + MatchingClaims / Evidence RegistryCreative Ingredient GraphExperiment MemoryGrowth Decision EngineNetwork Expansion Model
07 · The first 90 days

Learn manually → productize the truth → close the loop.

0–30 days

Learn + instrument

Operate the first practices hands-on. Establish the canonical event ledger, capacity model, claims/privacy boundaries, experiment memory and provider enrichment.

31–60 days

Build the launch factory

Automate research, competitive mapping, reporting, creative briefs, campaign drafts, LP generation and QA. Introduce the first human approval cockpit.

61–90 days

Close the loop

Connect capacity to media, encode creative learnings, introduce bounded autonomous actions and prove one operator can support 10+ practices without quality loss.

6–12 months

Become a network system

Use cross-practice priors to improve launches, route demand to available supply, and let patient-demand intelligence inform provider recruiting and market expansion.

08 · North star

Optimize for the relationship—not the lead.

CAC matters, but the system eventually needs to understand capacity, attendance, activation, retention and practice economics. Cheap demand that cannot become a healthy provider-patient relationship is not success.

Contribution-positive retained patient relationships
÷
available provider capacity

With a second axis: human minutes required to create and maintain those relationships.

09 · What I still need to learn from Vye

The next questions matter more than another week of outside theorizing.

01 · What is already canonical inside VyeOS: booking, patient events, provider capacity, payer and collections data?
02 · How are practice brands, domains and ad accounts intended to be structured at 10, 100 and 1,000 practices?
03 · What does Vye define as the durable patient-acquisition success event: booked, attended, activated, retained or contribution-positive?
04 · How much cross-practice learning and centralized demand routing does the product vision ultimately want?
05 · Where should Growth workflows become product—and how should Growth + Engineering divide ownership?
06 · What data may safely flow from clinical systems into growth analytics, and what must remain strictly separated?
The goal is not to automate a Growth Lead. The goal is to make Vye’s growth intelligence accumulate faster than Vye’s operating complexity.