Ty_Tech/geolocal-io
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: rewrite canonical strategy in human voice, drop copilot attributions

Browse Source
This commit is contained in:
Ty
2026-07-18 04:38:05 +00:00
parent 1a13f14d70
commit 4be326ffda
1 changed files with 221 additions and 249 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/strategy/CANONICAL_STRATEGY.md
+221 -249
View File
@@ -1,372 +1,344 @@
# geolocal.io — Canonical Strategy
> **Status:** Refined GM strategy (2026-07-18)
> **Source of truth for vision:** `docs/geolocal-copilot-conversation.md`
> **This document:** Condenses, stress-tests, and operationalizes that vision with current market evidence.
> **Supersedes:** Fractured narratives in older GTM/investor/engineering docs where they conflict.
**Status:** Draft operating strategy (2026-07-18)
**Role:** The document the team plans, builds, and sells against. When other docs disagree with this one, update them — or update this one deliberately. Do not leave the conflict hanging.
---
## 1. One-line company definition
## 1. What we are
**geolocal.io is the business-owned MCP infrastructure that makes local service businesses discoverable, interpretable, bookable, and measurable inside every AI assistant — the Shopify Storefront MCP equivalent for the long tail of local services.**
geolocal.io is the infrastructure that lets local service businesses show up properly inside the AI era — discoverable, understandable, bookable, and measurable when someone asks ChatGPT, Claude, Gemini, or the next assistant for a plumber, a transmission shop, a fishing charter, or a place to rent bikes.
Not a destination site.
Not a chatbot sold to SMBs.
Not a Yelp/Google clone.
Infrastructure that AI agents use, that businesses own, that partners and tourism boards distribute.
We are not building another place for consumers to browse. We are not selling business owners a chatbot for their website. We are not trying to replace Yelp or Google as destinations people open on purpose.
We are the layer underneath. AI agents call us. Businesses own their presence. Tourism boards, chambers, and agencies help distribute it. In plain terms: we want to be for local services what Shopify’s Storefront MCP became for online stores — a simple, standard way for any AI to talk to a real business and complete the job.
---
## 2. The problem (evidence-checked)
## 2. Why this has to exist
### 2.1 Demand side: consumers already moved
### Consumers already changed behavior
- BrightLocal’s 2026 Local Consumer Review Survey: **~45% of consumers use AI tools for local business recommendations** (ChatGPT is the leader among tools cited).
- BrightLocal and secondary coverage also reference a much lower prior-year figure (~6%); treat the directional leap as real, but do **not** overclaim a perfect YoY methodology match in investor materials without footnoting survey differences.
- X / practitioner discourse (2026): local discovery is collapsing into **1–3 named recommendations**, not a page of links — “if you’re not named, you’re invisible.”
A large and growing share of people now ask AI tools for local recommendations. BrightLocal’s 2026 consumer research puts that figure around 45%, with ChatGPT as the most common tool people name. Earlier surveys used different wording and showed much smaller numbers (around 6% in some 2025 reporting), so we should treat the leap as real without pretending every percentage point is apples-to-apples in investor decks.
### 2.2 Supply side: AI is radically selective
What matters operationally is the shape of the answer. AI does not hand you a page of blue links. It names one, two, or three businesses. If you are not one of those names, you do not exist in that moment. Practitioners talking about this on the open web describe the same thing: local discovery is collapsing into a shortlist of recommendations, not a results page.
- SOCi 2026 Local Visibility Index (≈350k locations / 2,751 multi-location brands):
- **ChatGPT recommended ~1.2% of brand locations**
- Gemini ~11%, Perplexity ~7.4%
- vs ~36% appearance in Google local 3-pack
- Locations recommended by ChatGPT skew high-trust (**~4.3★ average**).
- BrightLocal research: **Yelp is a frequent source** in AI local answers (~1/3 of searches in one study); listings/citations regained importance under LLMs.
### AI is extremely selective about who it recommends
**Implication:** Traditional local SEO is necessary but insufficient. Structured, machine-actionable presence is becoming the bottleneck.
SOCi’s 2026 Local Visibility Index looked at roughly 350,000 locations across more than 2,700 multi-location brands. In that sample, ChatGPT recommended only about 1.2% of brand locations. Gemini and Perplexity were higher (around 11% and 7%) but still far below traditional Google local 3-pack visibility (around 36%). Locations that do get recommended tend to look trustworthy — ChatGPT’s picks averaged about 4.3 stars.
### 2.3 Structural gap incumbents will not fill for SMBs
Other local SEO research has also found that AI systems lean hard on listings and review sources. Yelp, for example, shows up frequently as a cited source in local answers. That is good news for platforms that already own data. It is bad news for the independent shop whose only online presence is a dusty website and a half-maintained Google listing.
| Player | What they are building | What they are NOT building |
|--------|------------------------|----------------------------|
| **Shopify** | Storefront MCP live on every store (`/api/mcp`); UCP with Google; Catalog MCP | MCP for non-Shopify local service businesses |
| **Yelp** | Official open-source **Yelp MCP** over Fusion AI — *their* data for agents | Business-owned endpoints businesses control |
| **Google** | Maps Grounding / Merchant MCP (alpha); AI in Maps/Search; UCP commerce | Neutral, multi-tenant “own your AI presence” for long-tail SMBs |
| **Cal.com** | Full **booking MCP** (create/reschedule/cancel/availability) | Discovery, story, genre primitives, tourism aggregation |
| **OpenAI / Anthropic / others** | Agent platforms + data licensing | Local service graph for the 98%+ long tail |
Traditional local SEO still matters. It is no longer enough. Businesses need a machine-readable, up-to-date, bookable expression of who they are.
**Thesis (validated):** Incumbents build MCP for *their* platforms and *their* data. The long-tail service economy (Bob’s Garage, local charters, salons, tourism boards) has no Shopify-equivalent on-ramp. That vacuum is geolocal.io.
### The big platforms are building for themselves
This is the structural opening.
Shopify has already shipped Storefront MCP on merchant domains so agents can search catalogs, manage carts, and move toward checkout without scraping a site. Yelp has published an official MCP path into its own Fusion AI data. Google is wiring MCP into Maps grounding and Merchant tooling and has partnered on open commerce protocols. Cal.com already exposes a serious booking MCP — create, reschedule, cancel, availability — so scheduling is not a greenfield problem.
What none of them are building is a neutral, business-owned on-ramp for the long tail of local services: Bob’s Garage, the surf shop, the charter captain, the salon, the tourism board that wants its members to be helpful to visitors’ AI assistants.
Incumbents protect their platforms and their datasets. We build the missing infrastructure for everyone else.
---
## 3. North Star (from the copilot conversation — preserved)
## 3. North Star
**Make AI give the most relevant and helpful local recommendation — and fulfill it — for local service businesses.**
Make AI give the most relevant and helpful recommendation for a local service need — and then fulfill it.
Helpfulness (not mere relevance) is the optimization target: clear services, specialization, pricing signals, availability, booking path, trust, and **repeatable success** so AI engines prefer the same path next time.
Relevance gets you on the shortlist. Helpfulness is why the assistant comes back next time. Helpfulness means clear services, real specialization, honest pricing signals, real availability, a clean booking path, trust cues, and a track record of successful outcomes. When an AI finds a path that works repeatedly, it prefers that path. Our job is to make geolocal-backed businesses the path of least resistance for helpfulness.
We stay focused on local service businesses. We are not trying to boil the ocean of all commerce.
---
## 4. Four business models (do not collapse these)
## 4. Four business models (keep them distinct)
The copilot conversation defines **four stacked models**. Earlier repo docs mostly documented Model 1. That fracture is fixed here.
This company is not one product with one customer. It is four stacked models that reinforce each other. Earlier planning materials mostly described the first one. That is part of why the project felt fractured. All four stay in view.
| # | Model | Who pays / who adopts | What geolocal provides | Horizon |
|---|--------|------------------------|------------------------|---------|
| **1** | **Endpoint enablement** | Individual SMBs (self-service) | Hosted multi-tenant MCP + `/.well-known` pointer + Self-Service Portal (SSP) + diagnostics + reports | Day 0 |
| **2** | **Intermediate enablement** | Tourism boards, chambers, visitor bureaus | Aggregating MCP for destinations/members; member onboarding; municipal ROI narratives | V1 GTM wedge |
| **3** | **Industry trust layer** | Standards / partnerships / platforms | Quality primitives, decommissioning, genre norms — become a preferred discovery surface AI engines learn to trust | 12–24 mo |
| **4** | **Service graph** | Data products / licensing | Network of related services, specialties, demand signals, competitive intelligence (“Citysearch 2.0, AI-native”) | After critical mass |
### Model 1 — Endpoint enablement
**Rule:** Product decisions must state which model they serve. Do not build Model 4 features before Model 1–2 work.
Individual small businesses attach to geolocal. They get a hosted multi-tenant MCP, a tiny pointer on their own website, a self-service portal, diagnostics, and ongoing reports. This is day-zero product.
### Model 2 — Intermediate enablement
Tourism boards, chambers of commerce, and visitor bureaus become discovery nodes. They get an aggregating MCP for a destination or membership set, tools to onboard members, and a story they can take to leadership about visitor experience and economic development. This is our primary go-to-market wedge for scale.
### Model 3 — Industry trust layer
Over time, quality norms, genre standards, and decommissioning of bad data make geolocal a surface AI systems learn to prefer. This is not a year-one revenue line so much as the strategic prize of doing Models 1 and 2 well.
### Model 4 — Service graph
Once enough endpoints and intermediates exist, the network itself becomes valuable: related businesses, specialties, demand patterns, competitive context. Think of an AI-native successor to the old local directory graphs — not a consumer portal, but infrastructure and data products built on real usage.
**Operating rule:** Every product decision should name which model it serves. We do not build Model 4 features before Models 1 and 2 are real.
---
## 5. Product definition (what we actually sell)
## 5. What we actually sell
### 5.1 What we sell
### The offer
**AI-readiness infrastructure for local services:**
We sell AI-readiness infrastructure for local services. In practice that means:
1. **Hosted multi-tenant MCP** — structured tools AI agents call (story, services, hours, booking path, related businesses, genre primitives).
2. **Dead-simple discovery pointer** — business drops a tiny well-known JSON / path on their site that points at geolocal (Shopify pattern: endpoint on *their* domain, logic hosted).
3. **Self-Service Portal (SSP)** — the real product surface for SMBs (see §5.2).
4. **Orchestration, not reinvention** — Cal.com (booking MCP already exists), Stripe (payments). We do not replace them.
5. **Telemetry + optimization reports** — “how often AI hit you, what they asked, what your site failed to answer, what local demand looks like.”
6. **Partner / intermediate surfaces** — agencies, SEO shops, tourism boards, chambers.
1. **A hosted multi-tenant MCP** that agents can call for structured business truth — story, services, hours, booking path, related businesses, and later genre-specific detail.
2. **A dead-simple discovery pointer** on the business’s own site (for example a well-known path or JSON file) that points at us. No servers for Bob’s daughter to manage. Pattern-wise, this is the same idea as Shopify putting MCP on the merchant domain while hosting the hard parts.
3. **A Self-Service Portal** — the real product experience for owners (described below).
4. **Orchestration, not reinvention.** Cal.com for booking. Stripe for payments. We integrate; we do not rebuild their categories.
5. **Telemetry and optimization reports** — how often agents hit you, what they asked for, where your site or data failed, and what demand looks like in your area.
6. **Surfaces for partners and intermediates** — agencies, SEO consultants, tourism boards, chambers.
### 5.2 Self-Service Portal (SSP) — primary product experience
### The Self-Service Portal
From the founder narrative (canonical UX):
For a typical small business, the portal is how the product clicks.
1. Business lands on geolocal.io, describes business → **genre-aware onboarding** (auto repair vs surf shop vs charter).
2. **Initial site scrape** → reflect back what the system already “sees.”
3. **Live “phone + chat” simulation** — show ChatGPT-style flow: recommend the business, list services, book a time (e.g. Thursday 3pm transmission filter). Instant aha: *pre-qualified, scoped, calendar-aligned demand*.
4. Install **tiny pointer** on site.
5. **Preflight / test run** in-browser against *their* MCP — if AI can’t see services, they fix content or portal data before going live.
6. **Upstream guidance** (discovery: GBP, NAP, FAQ, plain-text city+service) + **downstream guidance** (MCP content quality).
7. Optional **partner referral** for website help.
8. **Weekly/monthly reports** — interaction counts, intents, local demand signals.
They come to geolocal.io and describe the business. The experience adapts to the genre — automotive feels different from a surf shop or a charter. We scrape their existing site and show them what the system already sees. Then we put a phone-and-chat style simulation in front of them: an assistant recommending their shop, listing real services, and finding a Thursday-at-three slot for the job they actually do. That is the aha moment. They are not buying abstract “AI optimization.” They are watching pre-qualified, in-scope, calendar-aligned demand show up.
**Critical clarification (founder):** We are **not** selling them a chatbot for their customers. The portal’s HTML chat is a **test harness** wired to their MCP so owners can see how *external* AIs will interpret them.
To make that real, they install a tiny pointer on their site. We walk them through a preflight test in the browser against their live MCP. If the assistant cannot see services, hours, or specialty, they fix content or portal data before going live. We also give upstream guidance (how to get found in the first place — Google Business Profile, consistent NAP, plain-text city and service language, FAQs) and downstream guidance (how to keep the MCP helpful). If they need website help, we can introduce a partner. After launch, they get regular reports on interactions, intents, and local demand.
### 5.3 Genre-specific primitives
One line we will not blur: **we are not selling them a chatbot for their customers.** The chat UI inside the portal is a test harness so the owner can see how *external* assistants will interpret the business. That distinction matters for product, pricing, and sales language.
Generic `get_business_info` is MVP scaffolding only. Differentiator is **genre systems**:
### Genre-specific primitives
- Auto: makes/models, specialties (Korean transmissions), emergency flags
- Beauty: services, duration, stylist notes
- Home services: service radius, emergency, estimate vs fixed price
A generic “get business info” tool is fine for scaffolding. The durable product is genre systems — structured fields and tools that match how a category actually works.
- Auto: makes and models, specialties, emergency flags
- Beauty: services, duration, stylist context
- Home services: service radius, emergency vs scheduled, estimate vs fixed price
- Tourism activities: seasonality, capacity, weather sensitivity
- Intermediate (tourism board): member directory + category routing
- Intermediates: member directory and category routing for a destination or chamber
Roadmap must version **genre packs**, not only generic tools.
Roadmaps should ship **genre packs**, not only generic endpoints.
### 5.4 What we explicitly do NOT build (V1–V2)
### What we will not build in the near term
- Consumer destination app
- Competing with Calendly/Cal.com/Square booking engines
- Competing with Stripe/Square payments
- Replacing Google Business Profile
- Building a Yelp review network
- Boiling the ocean on travel (AirBNB/Kayak space) — stay complementary
We are not a consumer destination app. We are not competing with Calendly, Cal.com, or Square as booking engines. We are not competing with Stripe or Square as payment rails. We are not replacing Google Business Profile. We are not building a Yelp-style review network. We are not trying to out-Kayak Kayak or out-Airbnb Airbnb. Stay complementary to travel platforms; own the local service long tail they do not serve cleanly for AI agents.
---
## 6. Positioning
## 6. How we talk about ourselves
### 6.1 Category
### Category
**AI-readiness infrastructure / agentic local commerce infrastructure**
AI-readiness infrastructure for local services — or, when you need a shorter phrase, agentic local commerce infrastructure.
Analogies that work in sales:
### Analogies that help
| Analogy | Why it lands |
|---------|----------------|
| **Shopify Storefront MCP for local services** | Best single analogy; founders and partners get it immediately |
| **Stripe for AI discovery/booking presence** | Infrastructure, not UI |
| **Twilio for local service tools** | Agents call APIs; business doesn’t rebuild stack |
- **Shopify Storefront MCP for local services** — usually the clearest one-liner for technical and product people.
- **Stripe for AI discovery and booking presence** — useful when you need “infrastructure, not another app UI.”
- **Twilio for local service tools** — agents call a contract; the business does not rebuild a stack.
### 6.2 Messaging (use this)
### Messaging that works
- **Owner:** “Make every AI assistant understand and book your business.”
- **Tourism board:** “Turn lodging tax dollars into AI-discoverable local experiences your members own.”
- **Agency/partner:** “Add AI-readiness as a productized line — not another chatbot retainer.”
- **Investor:** “Neutral MCP layer for the 98%+ of local services AI currently skips, sold via self-serve + municipal distribution.”
- **Business owner:** Make every AI assistant understand and book your business.
- **Tourism board:** Turn lodging-tax dollars into AI-discoverable local experiences your members own.
- **Agency or partner:** Add AI-readiness as a productized line — not another chatbot retainer.
- **Investor:** A neutral MCP layer for the vast majority of local services AI currently skips, distributed through self-serve and municipal partners.
### 6.3 Anti-messaging (do not say)
### Language to avoid
- “AI chatbot for your website”
- “Replace Google / Yelp”
- “SEO tool with AI features” (we can *include* discovery guidance, but category is infrastructure)
Do not call this an AI chatbot for the website. Do not claim we replace Google or Yelp. Do not position primarily as “an SEO tool with AI features,” even though discovery guidance is part of the portal. Category is infrastructure.
---
## 7. Go-to-market (refined)
## 7. Go-to-market
### 7.1 Primary V1 wedge: tourism / destination intermediaries
### Primary wedge: tourism and destination intermediates
**Why (copilot + market logic):**
Hotel and lodging taxes create promotion budgets that destinations are often required to spend. Boards and visitor organizations frequently struggle to spend that money well, and many run open calls for ideas. One intermediate relationship can bring dozens or hundreds of member endpoints online at once. Travel is also an area where AI referral behavior has been growing quickly in industry reporting. The brochure rack in the hotel lobby is the analog world proving the job to be done; geolocal is the AI-native version of that job.
- Hotel/lodging taxes create **mandated promotion budgets**.
- Boards often **must spend** and openly solicit ideas — confused buyers with money.
- One intermediate win → **dozens/hundreds of endpoints** (members).
- Travel has high AI referral growth narrative (industry reporting of strong AI travel referral growth 2024–2025).
- Physical brochure racks prove the *intent* for local discovery; geolocal is the AI-native equivalent.
Motion:
**Motion:**
1. Choose one or two destination markets for a real pilot.
2. Sell a board-level pilot: destination MCP, member onboarding through the portal, and a simple dashboard of member hits and category demand.
3. Fund it with tourism marketing budgets, innovation RFPs, or “AI visitor experience” framing — whatever matches how that board already buys.
4. Give members free or discounted endpoints during the pilot, then convert to paid.
1. Pick **1–2 destination markets** (illustrative: coastal FL tourism board style markets already used in founder narrative).
2. Sell **board-level pilot**: destination MCP + member onboarding SSP + simple ROI dashboard (member AI hits, category demand).
3. Fund via tourism marketing budgets / innovation RFPs / “AI visitor experience” framing.
4. Members get free/discounted endpoint for pilot period → convert to paid.
### Parallel motion: self-service small businesses
### 7.2 Parallel motion: self-service SMB endpoint
While intermediates mature, we also sell direct. First genre packs should be high-intent local services — auto repair, beauty, home services — and tourism activities when a destination pilot needs them.
- Verticals for first genre packs: **auto repair, beauty, home services** (home services align with high-intent AI queries; tourism activities if destination wedge).
- Price band (direction from copilot pricing discussion, infrastructure framing):
- **Starter ~$49/mo**
- **Core ~$129/mo (anchor)**
- **Pro ~$249/mo**
- Position above DIY “chatbot” tools; below enterprise multi-location AI visibility platforms (SOCi class).
Pricing direction for self-serve (infrastructure framing, not chatbot usage):
### 7.3 Secondary motion: partners (agencies, SEO, web shops)
| Tier | Monthly | Intent |
|------|---------|--------|
| Starter | about $49 | Endpoint, portal test experience, monthly report, basic diagnostics |
| Core | about $129 (anchor) | Full MCP, live preflight, weekly reports, local demand insights, partner access |
| Pro | about $249 | Multi-site, deeper telemetry, competitor signals, priority support |
- Not the *product* owner narrative; they are **distribution** and **implementation**.
- Partner marketplace when SSP shows “your website needs work — self-serve or partner?”
- Commission / wholesale pricing TBD after first 50–100 endpoints.
Position above DIY chat widgets and below enterprise multi-location AI visibility platforms. Tourism board deals use separate pilot or enterprise pricing, not the SMB price list.
### 7.4 Explicit non-wedge
### Partners as distribution, not the product
- Do not lead with “compete in national multi-location brand AI visibility” (SOCi’s world).
- Do not lead with pure e-commerce (Shopify already owns that MCP).
- Do not lead with pure B2B / non-local.
Agencies, SEO shops, and local web people matter. They are how hard websites get fixed and how busy owners get onboarded. They are not the center of the product story. The portal offers self-serve or “talk to a partner.” Commission and wholesale terms come after we have real attach volume — roughly after the first fifty to a hundred endpoints.
### Where we will not lead
We do not lead with national multi-location brand AI visibility (that is a different buyer and a different set of competitors). We do not lead with pure e-commerce (Shopify already owns that MCP story). We do not lead with pure B2B or non-local use cases.
---
## 8. Competitive strategy
## 8. Competitive posture
### 8.1 Who fills the vacuum?
### How the vacuum gets filled — and our answer
| Actor | Likely path | Our response |
|-------|-------------|--------------|
| **Yelp** | Become default AI source of truth via MCP + licensing | Offer **business-owned** data + booking path Yelp doesn’t control; complementary where agents need owner truth |
| **Google** | Maps + Merchant + UCP | Stay complementary; deep GBP guidance; don’t fight Maps for UI |
| **Shopify** | Expand agentic commerce | Partner pattern, don’t compete; copy their **well-known endpoint on merchant domain** UX |
| **Cal.com / Square / Vagaro** | Booking MCPs | Integrate; own discovery + genre + intermediate + graph |
| **AI visibility SaaS (SOCi, BrightLocal AI tools)** | Measure/optimize multi-location | Different buyer (enterprise brands); we own long-tail endpoints + tourism |
| **Local agencies** | Manual AEO/GEO retainers | Make them partners; productize what they can’t scale |
| Yelp | Become a default AI source of local truth via MCP and data licensing | Offer business-owned truth and a booking path the business controls; stay complementary when agents need owner data Yelp cannot provide |
| Google | Maps, Merchant, and open commerce protocols | Stay complementary; help owners with Business Profile hygiene; do not fight Maps for consumer UI |
| Shopify | Keep expanding agentic commerce | Copy the good patterns (merchant-domain discovery, hosted complexity); do not compete for e-commerce |
| Cal.com, Square, Vagaro | Booking and ops MCPs | Integrate deeply; own discovery, genre, intermediates, and graph |
| AI visibility SaaS for big multi-location brands | Measure and optimize enterprise footprints | Different customer; we own long-tail endpoints and destination distribution |
| Local agencies | Manual “get recommended by AI” retainers | Make them partners; productize what they cannot scale alone |
### 8.2 Moats (in order of build)
### Moats, in the order we earn them
1. **Endpoint density** in target geos/genres (critical mass for Model 3–4)
2. **Genre primitive quality** AI engines prefer (helpfulness repeatability)
3. **Telemetry flywheel** (demand signals → better recommendations → more attach)
4. **Intermediate contracts** (tourism/chambers lock distribution)
5. **Trust/quality enforcement** (decommission bad actors; freshness)
1. Endpoint density in specific geos and genres
2. Genre primitive quality that AI systems prefer because it is more helpful
3. Telemetry flywheel — demand signals improve recommendations, which attract more attach
4. Intermediate contracts that lock distribution
5. Trust and quality enforcement — freshness, decommissioning, reliability
Freshness moat vs Foursquare: demand is continuous booking/intent from the service economy, not social check-ins.
Compared with older local graphs that depended on social check-ins, our freshness comes from the real service economy: availability, bookings, content updates, and agent interactions that do not dry up unless local commerce dries up.
---
## 9. Pricing principles (SMB self-serve)
## 9. What success looks like
| Tier | Monthly | Includes (V1 intent) |
|------|---------|----------------------|
| Starter | ~$49 | MCP endpoint, SSP test page, monthly report, basic diagnostics |
| Core | ~$129 | Full MCP, live SSP preflight, weekly reports, local demand insights, partner access |
| Pro | ~$249 | Multi-site, advanced telemetry, competitor signals, priority support |
### First 90 days
**Add-ons later:** partner install, advanced analytics, multi-location.
**Tourism board:** separate enterprise/pilot pricing (per-destination + per-member), not SMB list price.
- Public multi-tenant MCP over HTTP (stdio alone is not a product agents on the open internet can use)
- Self-Service Portal MVP: onboard, scrape reflection, simulation, pointer install, preflight
- About 100 live endpoints
- One tourism or destination pilot at LOI or live pilot stage
- One or two genre packs
- Booking path via Cal.com (link first is acceptable; deeper API or MCP orchestration next)
- First dollars of ARR, even if small — proof someone will pay
**Do not** price as chatbot usage; price as **infrastructure + BI**.
### By 180 days
- About 1,000 endpoints
- Three genres
- Related-businesses handshake in production
- Several intermediate dashboards active
- Telemetry good enough for real owner reports
### By 360 days
- About 10,000 endpoints
- Several major chamber or tourism partnerships
- Early anonymized demand or data product in beta or market
- Case studies showing that, in pilot geos, assistants prefer geolocal-backed paths
These are planning bars, not financial covenants. Adjust with evidence; do not quietly abandon them.
---
## 10. Success metrics (what GM tracks)
## 10. Product and technical priorities
### 10.1 90 days
User stories and distribution come before elegant architecture theater.
| Metric | Target (planning bar) |
|--------|------------------------|
| Public multi-tenant MCP (HTTP) live | Yes |
| SSP MVP (onboard + scrape reflection + preflight sim + pointer install) | Yes |
| Live endpoints | 100 |
| Tourism board / destination pilots | 1 signed LOI or pilot |
| Genre packs | 1–2 (e.g. auto + tourism activity) |
| Booking path | Cal.com link or Cal.com MCP orchestration (not rebuild) |
| Paying | First $ ARR even if small — proves willingness |
**Priority 0 — prove Model 1**
### 10.2 180 days
| Metric | Target |
|--------|--------|
| Endpoints | 1,000 |
| Genres | 3 |
| Related-businesses handshake in production | Yes |
| Intermediate dashboards | 3+ boards/chambers active |
| Agent telemetry usable for reports | Yes |
### 10.3 360 days
| Metric | Target |
|--------|--------|
| Endpoints | 10,000 |
| Major CoC / tourism partnerships | 3+ |
| Early DaaS / anonymized demand product | In market or beta |
| Evidence AI engines prefer geolocal paths in pilot geos | Case studies |
---
## 11. Product / technical priorities (strategy-level only)
Aligned to copilot “user stories before architecture”:
**P0 — Prove Model 1**
1. HTTP MCP transport (agents are remote; stdio is not the product)
2. Multi-tenant routing by business slug/domain
3. SSP: signup → scrape → simulation → pointer → preflight
1. HTTP MCP transport
2. Multi-tenant routing by business slug or domain
3. Portal spine: signup → scrape → simulation → pointer → preflight
4. Manifest / well-known generator
5. Seed genres + real pilot businesses
6. Cal.com path (redirect first; API/MCP next)
5. Seed genres and real pilot businesses
6. Cal.com path (redirect first, deeper integration next)
**P1 — Prove Model 2**
**Priority 1 — prove Model 2**
7. Intermediate (tourism) MCP + member aggregation
8. Board dashboard: members, hits, categories
9. Pilot paperwork + data agreements
7. Intermediate (tourism) MCP and member aggregation
8. Board dashboard for members, hits, and categories
9. Pilot paperwork and data agreements
**P2 — Feed Models 3–4**
**Priority 2 — feed Models 3 and 4**
10. Telemetry pipeline + owner reports
11. Related businesses tool + quality rules
12. Genre pack expansion
13. Partner marketplace
10. Telemetry pipeline and owner reports
11. Related businesses tool and quality rules
12. More genre packs
13. Partner marketplace
**Explicit defer:** white-label everything, OAuth complexity beyond need, public developer platform, full DaaS, WordPress plugins (until attach rate demands them).
**Explicitly later:** full white-label everywhere, heavy OAuth before we need it, a public developer platform, a full data-as-a-service product, and CMS plugins until attach volume demands them.
---
## 12. Risks (steelman)
## 11. Risks we take seriously
| Risk | Severity | Mitigation |
|------|----------|------------|
| Yelp/Google become “good enough” AI local sources | High | Own business truth + booking + genre depth; intermediates; owner control narrative |
| SMBs don’t care until bookings prove ROI | High | SSP aha demo; tourism funded pilot; reports show demand; partner installs |
| MCP / discovery standards shift | Medium | Follow Shopify/Yelp well-known patterns; multi-path discovery |
| Market stats overstated in pitch | Medium | Cite SOCi/BrightLocal carefully; separate “multi-location study” vs “all SMBs” |
| Scope creep into chatbot / marketplace | High | North Star discipline; weekly “are we infrastructure?” review |
| Technical overbuild before SSP | High | No new tools without SSP path to value |
| Tourism procurement slow | Medium | Parallel self-serve SMB + short pilot contracts |
**Yelp or Google become “good enough.”**
We counter with business-owned data, booking completion, genre depth, intermediate distribution, and a clear owner-control story.
**Small businesses will not care until bookings prove ROI.**
The portal’s live simulation, tourism-funded pilots, demand reports, and partner-assisted installs exist to close that gap.
**MCP and discovery conventions will keep moving.**
Follow patterns the industry already recognizes (merchant-domain discovery, well-known locations, multi-path fallbacks). Do not invent a private religion.
**Market statistics get oversold in the pitch.**
Cite sources carefully. Distinguish multi-location brand studies from the entire SMB universe. Prefer honesty over hype; the opportunity is large enough without exaggeration.
**Scope creeps into chatbots or consumer marketplaces.**
Weekly check: are we still infrastructure? If the answer is fuzzy, cut scope.
**Engineering builds tools nobody can activate.**
No new MCP tool without a portal path that shows an owner why it matters.
**Tourism procurement is slow.**
Run self-serve SMB in parallel. Prefer short pilot contracts over perfect enterprise RFPs for the first win.
---
## 13. Document governance (end the fracture)
## 12. How we keep the docs honest
| Document | Role |
|----------|------|
| `docs/geolocal-copilot-conversation.md` | Foundational founder narrative (historical truth) |
| **`docs/strategy/CANONICAL_STRATEGY.md` (this file)** | **Operating strategy — team rallies here** |
| `NORTH_STAR.md` | Short public/internal compass — must match this file |
| `docs/gtm/*` | Execution detail — must not invent a different company |
| `docs/investors/*` | External packaging of *this* strategy |
| `docs/engineering/*` | Build plan for P0–P2 above |
| `code/` | Implementation of P0 |
| Document | Job |
|----------|-----|
| `docs/geolocal-copilot-conversation.md` | Historical exploration archive — useful context, not the operating manual |
| **`docs/strategy/CANONICAL_STRATEGY.md` (this file)** | **Operating strategy the team rallies around** |
| `NORTH_STAR.md` | Short compass; must stay consistent with this file |
| `docs/gtm/*` | Execution detail for channels and sales; must describe this company, not a different one |
| `docs/investors/*` | External packaging of this strategy |
| `docs/engineering/*` | Build plan for the priorities above |
| `code/` | Implementation of Priority 0 |
**Rule:** If a doc conflicts with this file, this file wins until the GM revises it.
If two documents disagree, either this file changes on purpose or the other document changes. Silence is how the project fractures again.
---
## 14. Near-term decisions for the leadership team
## 13. Near-term leadership decisions
1. **Adopt this document** as the single operating strategy.
2. **Rewrite NORTH_STAR.md** to include four models + tourism wedge + SSP (not partner-dashboard-first only).
3. **Retire or mark “stale”** any GTM doc that makes partner dashboard the only product or collapses four models to one.
4. **Lock V1 markets:** choose destination pilot shortlist + 1 SMB vertical for genre pack.
5. **Lock pricing experiments:** Core $129 anchor A/B later; don’t block launch on pricing perfection.
6. **Engineering charter:** 30-day sprint = HTTP MCP + SSP spine + 10 real pilot endpoints (not more roadmap prose).
7. **Legal:** tourism pilot data agreement + business ToS + MCP telemetry privacy (lightweight now, not full DaaS).
1. Adopt this document as the single operating strategy (or mark specific sections for revision).
2. Rewrite `NORTH_STAR.md` so it reflects four models, the tourism wedge, and the Self-Service Portal — not a partner-dashboard-only story.
3. Mark stale any GTM material that collapses the company into one model or one channel.
4. Lock a short list of destination pilots and the first genre pack.
5. Treat Core ~$129 as the pricing anchor for experiments; do not block launch on perfect price discovery.
6. Charter engineering for a 30-day sprint: HTTP MCP, portal spine, and about ten real pilot endpoints — not more strategy prose.
7. Stand up lightweight legal: tourism pilot data terms, business terms of service, and basic telemetry privacy. Full data-product legal can wait.
---
## 15. GM summary
## 14. Closing
**The copilot version is the right company.** The repo version got flattened into “partner MCP for SMBs with Cal.com” and lost the multi-model ambition, the SSP product, the tourism wedge, and the service-graph endgame.
The version of this company that is worth building is the ambitious one: endpoint infrastructure, intermediate distribution, a trust layer AI systems learn to prefer, and eventually a service graph that compounds. The thin version — “a partner dashboard that spits out an MCP file” — is easier to write down and much easier for someone else to crush.
Market evidence in 2026 **supports** the urgency:
Market conditions in 2026 support urgency without requiring panic. Consumers are using AI for local discovery. Recommendation is highly selective. Shopify, Yelp, Google, and Cal.com all prove that MCP is real — and each protects its own layer. The long tail of local services still lacks a neutral on-ramp.
- Consumers are using AI for local discovery at scale.
- AI recommendation is extremely selective.
- Shopify proved the pattern for *commerce* MCP on merchant domains.
- Yelp/Google/Cal.com prove MCP is real — and each protects *their* layer.
- Nobody is Shopify for local services’ AI presence.
**Our job as a funded planning team:** freeze this strategy, realign all docs, and execute the SSP + tourism pilot path until the vacuum starts filling under *our* brand — not Yelp’s.
Our job as a funded planning team is to freeze a clear strategy, realign the docs, and execute the portal plus tourism pilot path until that vacuum starts filling under our name.
---
## Research sources (selected)
## Research notes
- BrightLocal LCRS AI trust / local consumer research (2026) — consumer AI usage for local recommendations
- SOCi 2026 Local Visibility Index / PR coverage — 1.2% ChatGPT recommendation rate, selectivity vs Google 3-pack
- Shopify Storefront MCP docs / industry writeups — merchant-domain MCP, agentic commerce
- Yelp Fusion AI MCP (github.com/Yelp/yelp-mcp) — official local data MCP
- Google Cloud / Merchant API MCP materials — Maps grounding, Merchant MCP
- Cal.com MCP docs — booking lifecycle tools for agents
- X discourse (2026) — agentic commerce, AI local discovery, SMB invisibility narrative
Key external reference points used while drafting this strategy:
*Stats should be re-verified at each external pitch; do not invent precision beyond sources.*
- BrightLocal local consumer research (2026) on AI use for business recommendations
- SOCi 2026 Local Visibility Index and related coverage on recommendation selectivity
- Shopify Storefront MCP and agentic commerce materials
- Yelp Fusion AI MCP (public repository and product pages)
- Google Maps grounding and Merchant MCP materials
- Cal.com MCP documentation for booking lifecycle tools
- Public discussion of AI local discovery and agentic commerce
Re-verify statistics before every external pitch. Prefer primary sources over secondary rewrites when the number matters.