<context timezone="America/Chicago" />
<message id="2" from="slack-mg-17835-4" sender="James Lopez" time="Jul 8, 2026, 9:59 AM">@U0BFL0HCL20 earlier you'd provided a summary and questions for next steps on RoadSense. Pasting here for context. Will try to respond inline on each preceeded with "JL:" so you can find my responses.RoadSense: Public Launch Scope + GTM Plan⎯⎯⎯What we know: Functional personal pilot (Cedar Park / Austin), GIS-based road scoring + ridden-road tracking, product tour video just added. Decision to go public is made.⎯⎯⎯Technical prerequisites (rough order)Generalization test — The scoring is tuned for Texas hill country. Before launch, validate it on one other city (San Jose Bay Area or Denver, North Carolina are the candidates). A failed out-of-area test caught before launch is better than a "doesn't work in my city" complaint on day one.JL: Yes, and I think we can get that data from public sources and use our existing scoring and pipeline algorithm to see if they generalize, for MVP we may want to limit that only to the Austin area, so that may impact how we restrict things or implement them.Auth model decision — This is the biggest fork:
• No accounts (v1): Launch read-only, showing your Austin data. Simple, fast. Users can't track their own rides yet.
• OAuth login: Google/Apple sign-in, per-user ridden-road tracking. Full product but 2–4 weeks of work.
• URL sessions: No server auth; each user gets a URL that stores their state. Privacy-friendly, medium effort.
The ridden-roads feature is a key differentiator — launching without per-user tracking downgrades it to a demo.JL: Agreed accounts is really important and SSO would be great, we've already done SSO implementation on Qip-Qien so maybe it's a lighter lift than expected?GIS data licensing — Confirm the road data source is licensed for public use. OSM (ODbL) is fine with attribution; paid tile services often restrict public deployment.JL: Can you research and confirm this for us?Hosting at public scale — GIS tile serving can spike in cost. Worth estimating traffic ceiling before launch day.JL: Great question. Are we actually hosting those tiles or is that a mapbox thing, could we perhaps limit access when we approach the max for that period? 15k tiles per month, if memory serves, double check that.Fix ridden-roads display bug — Quick win, should happen before any public URLs go out.JL: this got fixed and verified yesterday
⎯⎯⎯GTM options (ranked by effort × signal)OptionEffortWho you reachWhenReddit (r/motorcycles, ADVRider)LowHigh-intent ridersDay 1Austin riding groups (local FB/Telegram)LowKnown audience, real feedbackDay 1Instagram Reels — "roads the algorithm found"MediumBroader rider audienceWeek 2Product HuntMediumBuilder/tech crossoverAfter polishHacker News Show HNLowDeveloper-riders, algo angleOptionalRecommended sequence: Fix bug → generalization test → decide auth model → soft-launch Reddit/ADVRider with product tour video → iterate → Product Hunt when v1 is stable.⎯⎯⎯Red-team critique• GIS licensing is a latent risk. Worth a 10-minute check before any public URLs go out. One ODbL violation at scale is a real problem.
• No-accounts launch limits the core loop. If users can't track their own rides, the product's stickiness drops significantly — they can discover roads but can't mark them done. That may be acceptable for v1, but it's a deliberate tradeoff, not a default.
• Generalization may not be trivial. Texas hill country is a specific topology. Mountain switchbacks (Denver) and coastal curves (Bay Area) score differently. The algorithm may need tuning per region — which is scope creep if you don't plan for it.
• No success metric defined. Without a 30-day number to target, "going public" is hard to declare done. What would make this a win?
• Creator posture isn't decided. Product-led GTM (Reddit, HN) and creator-led GTM (Instagram Reels, TikTok) require different prep. Committing to one focuses the effort.⎯⎯⎯Questions for you (pick any to answer):Auth model: No accounts for v1 (fast), URL sessions (medium), or full OAuth (full product)?JL: unclear on what this means in user terms and implementation terms, i want Google SSO as part of MVPGeneralization city: San Jose Bay Area or Denver, NC — which should I target for the first out-of-area test?JL: San Jose Bay AreaGIS data source: OpenStreetMap, a paid tile service, or something else? Needs a licensing check.JL: Can you please checkCreator posture: Open to being the face of RoadSense on Reels/Shorts ("here's what the algorithm found"), or prefer anonymous tool launch?JL: Good question, maybe we test each to see what works better?30-day success metric: What number would make you say it's working? (e.g., 50 unique users, 3 cities validated, first unsolicited positive comment)JL: No clue, sure maybe that makes sense.</message>


- update-config: Use this skill to configure the Claude Code harness via settings.json. Automated behaviors ("from now on when X", "each time X", "whenever X", "before/after X") require hooks configured in settings.json - the harness executes these, not Claude, so memory/preferences cannot fulfill them. Also use for: permissions ("allow X", "add permission", "move permission to"), env vars ("set X=Y"), hook troubleshooting, or any changes to settings.json/settings.local.json files. Examples: "allow npm commands", "add bq permission to global settings", "move permission to user settings", "set DEBUG=true", "when claude stops show X". For simple settings like theme/model, suggest the /config command.
- keybindings-help: Use when the user wants to customize keyboard shortcuts, rebind keys, add chord bindings, or modify ~/.claude/keybindings.json. Examples: "rebind ctrl+s", "add a chord shortcut", "change the submit key", "customize keybindings".
- simplify: Review changed code for reuse, quality, and efficiency, then fix any issues found.
- fewer-permission-prompts: Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts.
- loop: Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo, defaults to 10m) - When the user wants to set up a recurring task, poll for status, or run something repeatedly on an interval (e.g. "check the deploy every 5 minutes", "keep running /babysit-prs"). Do NOT invoke for one-off tasks.
- schedule: Create, update, list, or run scheduled remote agents (routines) that execute on a cron schedule. - When the user wants to schedule a recurring remote agent, set up automated tasks, create a cron job for Claude Code, or manage their scheduled agents/routines. Also use when the user wants a one-time scheduled run ("run this once at 3pm", "remind me to check X tomorrow").
- claude-api: Build, debug, and optimize Claude API / Anthropic SDK apps. Apps built with this skill should include prompt caching. Also handles migrating existing Claude API code between Claude model versions (4.5 → 4.6, 4.6 → 4.7, retired-model replacements).
TRIGGER when: code imports `anthropic`/`@anthropic-ai/sdk`; user asks for the Claude API, Anthropic SDK, or Managed Agents; user adds/modifies/tunes a Claude feature (caching, thinking, compaction, tool use, batch, files, citations, memory) or model (Opus/Sonnet/Haiku) in a file; questions about prompt caching / cache hit rate in an Anthropic SDK project.
SKIP: file imports `openai`/other-provider SDK, filename like `*-openai.py`/`*-generic.py`, provider-neutral code, general programming/ML.
- agent-browser: Browse the web for any task — research topics, read articles, interact with web apps, fill forms, take screenshots, extract data, and test web pages. Use whenever a browser would be useful, not just when the user explicitly asks.
- frontend-engineer: Pro frontend engineering discipline. Enforces build-test-verify workflow for every web project. Never declare done until the site is built, tested, responsive, accessible, and visually verified in a real browser. Use alongside vercel-cli for production-quality deployments.
- whatsapp-formatting: Format messages for WhatsApp, including mentions that render as real WhatsApp tags. Use when responding in a WhatsApp conversation (platform_id / chatJid ends with @s.whatsapp.net or @g.us).
- vercel-cli: Deploy apps to Vercel. Use when asked to deploy, ship, or publish a web application, or manage Vercel projects, domains, and environment variables.
- slack-formatting: Format messages for Slack using mrkdwn syntax. Use when responding to Slack channels (folder starts with "slack_" or JID contains slack identifiers).
- welcome: Introduce yourself to a newly connected channel. Triggered automatically when a channel is first wired. Send a friendly greeting and brief overview of what you can do.
- self-customize: Customize your own agent — add capabilities, install packages, add MCP servers, edit code or CLAUDE.md. Use when the user asks you to add a feature, install a tool, or modify how you work. For non-trivial code changes, delegate to a builder agent via create_agent.
- onecli-gateway: OneCLI Gateway: transparent HTTPS proxy that injects stored credentials into outbound calls. You MUST use this skill when the user asks you to read emails, check calendar, access GitHub repos, create issues, check Stripe payments, or interact with ANY external service or API. Do NOT use browser extensions or OAuth CLI tools. Make HTTP requests directly; the gateway injects credentials automatically.
- consult-codex: Get a second opinion from OpenAI Codex on a plan, a problem you're stuck on, or any task that benefits from a fresh perspective or higher reasoning effort. Use when the user says "ask Codex", "red-team this with Codex", "get Codex's take", "I'm stuck - try Codex", "what would Codex say about this", or "run this by Codex".
- widget-install: Install widget build, bust caches, verify in gallery
- skill-review: Analyze the current session transcript to surface friction points — corrections made, clarifications added, questions Claude asked that a good skill or CLAUDE.md entry would have pre-answered. Use at the end of any working session when you say "skill review", "review this session", "what should I add to my skills", "what did the skill miss", "what kept needing prompting", "session debrief", "improve my setup from this session", or "what friction was there today".
- deploy-to-mini: Deploy a project's local git changes to the always-on Mac Mini (jamess-mac-mini, where long-running services like nanoclaw, the pool monitor, and the congressional trading monitor run) over the LAN via SSH, then rebuild and restart that project's launchd service. Use when the user says "deploy to the mini", "push this to the mac mini", "get these changes running on the mini", "restart <service> on the mini", or after committing a change that needs to go live on the Mini.
- consult-agy: Get a second opinion from Google's Antigravity (agy/Gemini) on a plan, a problem you're stuck on, or any task that benefits from a fresh perspective, large context, or higher-capability model pass. Use when the user says "ask agy", "ask Gemini", "red-team this with agy", "get Gemini's take", "I'm stuck - try agy", "what would Gemini say about this", or "run this by agy".
- escalate: Escalate a stuck problem to an external agent (Codex, Claude, or agy/Gemini) and surface a structured summary of what was tried, what was observed, and alternative strategies. Invoked automatically when 3 approaches have failed without measurable progress, or manually when the user says "escalate this", "ask an outside agent", "try a higher effort model", or "I'm stuck, get help".
- consult-claude: Get a second opinion from Anthropic Claude Code on a plan, a stuck problem, or any task that benefits from a fresh perspective or higher reasoning effort. Use when the user says "ask Claude", "red-team this with Claude", "get Claude's take", "try Claude", "what would Claude say about this", or "run this by Claude".
- smell-fix: Read the current project's observations.md and propose (or apply) fixes for open code smell items. Use when the user says "/smell-fix", "fix smell observations", "address observations backlog", "work through observations", or when pace is low and there's idle time.
- init: Initialize a new CLAUDE.md file with codebase documentation
- review: Review a pull request
- security-review: Complete a security review of the pending changes on the current branch


RoadSense public launch planning and GTM strategy


James has provided inline responses to the RoadSense planning document. Let me process each response and figure out what I need to do:

1. **Generalization test** - JL: Austin-area MVP is fine, limit to Austin for now. May need geo-restrictions.

2. **Auth model** - JL: Wants Google SSO as part of MVP. References qip-qien implementation as potentially lighter lift.

3. **GIS data licensing** - JL: Needs me to research and confirm.

4. **Hosting/tile limits** - JL: Asking if we host tiles or if that's Mapbox. Wants to know the limit (he thinks 15k/month).

5. **Ridden-roads display bug** - Already fixed and verified.

6. **GTM** - Various responses.

7. **Creator posture** - Test both approaches.

8. **30-day metric** - James is uncertain about this one, so I should propose a specific number rather than leaving it open-ended.

I need to research a few things: GIS data licensing options like OSM's ODbL and Mapbox's terms, what Mapbox's free tier actually allows for tile loads, and how Google SSO would work both from a user experience and implementation perspective. I'm pretty sure Mapbox offers a free tier with around 50,000 map loads included.

Before diving into research, I should send James a quick acknowledgment of his responses, then look into the RoadSense codebase to see what data sources they're currently using so I can give informed recommendations on licensing and tile limits.


Let me send a quick acknowledgment and then do the research in parallel.


Got it James — reading through all your inline responses now. Going to check the RoadSense repo for what data sources it actually uses, then look up OSM licensing and Mapbox tile limits. Back shortly.


Message sent to slack-mg-17835-4 (id: 3)


Agent

RoadSense codebase data source check

Prompt:
Look at the RoadSense project in /workspace/extra/projects/RoadSense/ (or wherever it lives under /workspace/extra/projects/). I need to know:
1. What map tile service is being used? (Mapbox, Leaflet+OSM, Google Maps, etc.) — find API keys, tile URLs, or SDK imports that reveal this.
2. What is the source of the road/GIS data being scored? (OpenStreetMap, a paid GIS provider, something else?)
3. Is there any auth/login system already in place? (Any OAuth, session, or auth middleware code?)
4. What is the tech stack (Next.js, plain HTML, Python backend, etc.)?

Search thoroughly — look at package.json, .env.example, config files, main JS/TS files, and any map-related components. Report concisely what you find for each of the 4 questions.


OSM licensing and Mapbox free tier research

Prompt:
Please research two things and report back concisely:

1. **OpenStreetMap (OSM) ODbL licensing for public web apps**: Is it legal to use OSM road data in a publicly launched web app? What are the attribution requirements? Are there any restrictions on commercial use or public deployment?

2. **Mapbox free tier limits**: What are the current (2025/2026) Mapbox free tier limits? Specifically:
   - How many map loads or tile requests per month are free?
   - What happens when you exceed the free tier?
   - Is there a way to cap/limit usage to stay within free tier?

Search the web for current accurate info on both. Report in plain prose, under 200 words total.


**OSM / ODbL**

Commercial use is fully permitted under ODbL — no restrictions on public deployment or revenue. The two requirements: (1) attribute with "© OpenStreetMap contributors" visibly on or near the map, and (2) make it clear the data is under ODbL, typically by making "OpenStreetMap" a link to openstreetmap.org/copyright. For an interactive web map, a small corner attribution satisfies this. One important caveat: OSM's own tile servers (tile.openstreetmap.org) are not meant for production/commercial traffic — you must use your own tiles or a commercial tile provider (Mapbox, Maptiler, etc.).

**Mapbox free tier**

As of 2025/2026: 50,000 web map loads/month free. Each page load that initializes a Map object counts as one load; interactions within a session are free. Overages are charged at $5/1,000 loads (dropping to $3/1,000 above 200,000). There is no built-in hard cap — Mapbox will charge you if you exceed the free tier. You get email alerts when you go over, but no automatic kill switch. To stay within the free tier, you'd need to monitor usage manually and/or implement server-side rate limiting on your own.

Sources:
- [OpenStreetMap Copyright and License](https://www.openstreetmap.org/copyright)
- [OSM Attribution Guidelines](https://osmfoundation.org/wiki/Licence/Attribution_Guidelines)
- [Mapbox Pricing (official docs)](https://docs.mapbox.com/accounts/guides/pricing/)
- [Mapbox GL JS Pricing](https://docs.mapbox.com/mapbox-gl-js/guides/pricing/)
- [Mapbox Free Tier overview (Oreate AI)](https://www.oreateai.com/blog/navigating-mapboxs-free-tier-what-to-expect-for-map-loads-in-2025/e1f59d9f5b9d23fca4bb3c7934882365)

agentId: ad44ccaff8cdccd20 (use SendMessage with to: 'ad44ccaff8cdccd20' to continue this agent)
<usage>total_tokens: 29743
tool_uses: 3
duration_ms: 27814</usage>

Prompt:
Please research two things and report back concisely:

1. **OpenStreetMap (OSM) ODbL licensing for public web apps**: Is it legal to use OSM road data in a publicly launched web app? What are the attribution requirements? Are there any restrictions on commercial use or public deployment?

2. **Mapbox free tier limits**: What are the current (2025/2026) Mapbox free tier limits? Specifically:
   - How many map loads or tile requests per month are free?
   - What happens when you exceed the free tier?
   - Is there a way to cap/limit usage to stay within free tier?

Search the web for current accurate info on both. Report in plain prose, under 200 words total.


Perfect! I now have all the information I need. Let me compile my findings:

---

## RoadSense Project Analysis

Based on my thorough search of the codebase, here are the answers to your four questions:

### 1. **Map Tile Service: Mapbox GL JS**
- **Technology**: Mapbox GL JS v3.24.0 with the Mapbox outdoors style (`mapbox://styles/mapbox/outdoors-v12`)
- **API Key**: Present in `.env.local` as `NEXT_PUBLIC_MAPBOX_TOKEN` (stored as a public token starting with `pk.eyJ...`)
- **Implementation**: Used in `/src/components/Map.tsx` as the primary mapping library
- **Integration**: Vector tiles from Mapbox; supports custom road layer styling with Mapbox expressions (filtering, coloring by score, styling based on "ridden" state)
- **Secondary Navigation**: Also integrates Google Maps, Apple Maps, and Waze for directions/navigation (not as the primary map)

### 2. **Road/GIS Data Source: OpenStreetMap (Overpass API)**
- **Primary source**: Overpass API (`https://overpass-api.de/api/interpreter`) for fetching OSM ways in the Cedar Park, TX bounding box
- **Highway types queried**: Secondary, tertiary, and unclassified roads from OSM
- **Natural features**: Pulled from OSM for scenery scoring (water, forest, parks via PostGIS ST_DWithin proximity queries)
- **Elevation data**: SRTM tiles (NASA EarthData, 1-arc-second resolution) — downloaded locally once, no runtime API calls
- **Calibration data**: BDR (Big Dirt Routes) and Rever GPX files used as ground truth for tuning scoring weights
- **Scale path**: Currently via Overpass API; can scale to Geofabrik state PBF extracts (mentioned in SPEC)
- **No API key required** for Overpass; OSM data is free and open

### 3. **Auth/Login System: None Currently (Single-User)**
- **Current state**: Zero authentication implemented. This is a personal single-user application
- **Database schema**: No `users` or `accounts` table; `user_roads`, `user_ratings`, and `user_weights` tables assume a single user
- **SPEC guidance**: Explicitly states `"Auth | None initially (single-user) | Add NextAuth if/when multi-user"`
- **API routes**: All endpoints in `/src/app/api/` are public with no auth middleware or guards
- **Future plan**: NextAuth considered if multi-user support is added

### 4. **Tech Stack**
- **Framework**: Next.js 16.2.7 (App Router, server and client components)
- **Language**: TypeScript 5
- **Frontend**: React 19.2.4, Tailwind CSS 4, Mapbox GL JS 3.24.0
- **Backend**: Next.js API routes (Route handlers)
- **Database**: PostgreSQL 16 with PostGIS 3.4 (PostGIS for spatial indexing and proximity queries)
- **ORM**: Drizzle ORM 0.45.2 with Drizzle Kit for migrations
- **Data Pipeline**: Node.js/tsx scripts (CLI tools for fetching, ingesting, scoring — run locally or via cron, not in Next.js)
- **Styling**: Tailwind CSS, custom glass-morphism UI components
- **Dev tools**: ESLint, Vitest for testing, Docker for local PostGIS

**Key files** establishing this stack:
- `/workspace/extra/projects/RoadSense/package.json` (dependencies)
- `/workspace/extra/projects/RoadSense/.env.local` (Mapbox token, DB URL, Anthropic API key)
- `/workspace/extra/projects/RoadSense/src/components/Map.tsx` (Mapbox implementation)
- `/workspace/extra/projects/RoadSense/pipeline/fetch.ts` (Overpass API integration)
- `/workspace/extra/projects/RoadSense/src/db/schema.ts` (Drizzle schema—no auth tables)

Prompt:
Look at the RoadSense project in /workspace/extra/projects/RoadSense/ (or wherever it lives under /workspace/extra/projects/). I need to know:
1. What map tile service is being used? (Mapbox, Leaflet+OSM, Google Maps, etc.) — find API keys, tile URLs, or SDK imports that reveal this.
2. What is the source of the road/GIS data being scored? (OpenStreetMap, a paid GIS provider, something else?)
3. Is there any auth/login system already in place? (Any OAuth, session, or auth middleware code?)
4. What is the tech stack (Next.js, plain HTML, Python backend, etc.)?

Search thoroughly — look at package.json, .env.example, config files, main JS/TS files, and any map-related components. Report concisely what you find for each of the 4 questions.


Now I have everything I need to give James a comprehensive response. Let me synthesize:

**Stack**: Next.js 16.2.7, TypeScript 5, React 19, Tailwind CSS 4, Mapbox GL JS 3.24.0, PostgreSQL 16 + PostGIS, Drizzle ORM

**GIS Data**: Overpass API (OSM) for road data — fully licensed under ODbL, commercial use is fine, just needs attribution. The Mapbox tile service is separate from the data source.

**Tile Service**: Mapbox GL JS with Mapbox outdoors style.

The free tier gives us 50,000 web map loads per month, and overages run $5 per 1,000 loads with no hard cap on Mapbox's side. Currently there's no auth layer — the schema is single-user, though the spec mentions NextAuth for multi-user support, which should be straightforward since qip-qien already has Google SSO implemented. For the MVP, James wants to keep it Austin-only with geo-restrictions rather than testing generalization across other areas, and he's looking to add auth.

On the GIS side, OpenStreetMap's ODbL license is fine for public use as long as we attribute it properly. The Mapbox tiles situation is clearer now — James was thinking 15,000 loads per month, but the actual free tier is 50,000, so we'd need custom server-side rate limiting to prevent overages. The ridden-roads bug is fixed and verified. We're testing both product-led and creator-led approaches, and for the 30-day metric James was noncommittal, so I'll need to propose something concrete.

For the auth model, I should explain it plainly: users click "Sign in with Google," get redirected to Google to approve, then come back signed in with their ridden roads saved to their account. Unsigned visitors can still browse the map but can't track their own rides. NextAuth.js with a Google provider handles this — probably 2-3 days of work, and since qip-qien already has NextAuth set up, the pattern is known. On the Mapbox side, the 50,000 monthly loads is actually quite generous for a new launch, so we're in good shape there.

For licensing, OpenStreetMap's ODbL allows public and commercial use as long as we attribute it properly. The Overpass API for fetching data is fine to use. I just need to make sure "© OpenStreetMap contributors" is visible on the map — Mapbox's outdoors style likely already includes this.

The updated next steps are: fix the ridden-roads bug, add Google SSO through NextAuth, restrict the initial launch to just the Austin and Cedar Park bounding box, verify the OSM attribution shows up on the map, and set up a usage alert for Mapbox monitoring.

For the 30-day metric, I'm targeting 50 unique signed-in users. The go-to-market strategy is a soft launch on Reddit and ADVRider with a product tour video. I'm also planning to test two different creator approaches — first posting it as an anonymous tool, then as a personal story about what the algorithm discovered.


Good, I have everything. Let me write up the full response now.

<message to="slack-mg-17835-4">
James — here's the full synthesis with answers to the research questions and updated next steps based on your inline replies.

---

**GIS licensing — clean ✅**

RoadSense uses OpenStreetMap via the Overpass API for road data. OSM's ODbL license allows public and commercial deployment with no restrictions. Only two requirements: (1) show "© OpenStreetMap contributors" visibly near the map, (2) link "OpenStreetMap" to openstreetmap.org/copyright. Mapbox's outdoors style already includes OSM attribution in its default control — worth a quick visual check at launch to confirm it's showing.

---

**Mapbox tile limit — 50k map loads/month free (not 15k)**

The actual free tier is 50,000 web map loads/month. Each time someone loads the page and the map initializes = 1 load. Overages are $5/1,000 loads, charged automatically — there's no hard kill switch on Mapbox's end. You can set usage alerts in the Mapbox dashboard (email at thresholds), but there's no built-in cap. For context: 200 daily users visiting 5x each day = ~30k loads/month — still under the free tier. If traffic spikes past that, you'd need to implement your own server-side rate limiting or upgrade. For an early launch, the free tier is comfortable headroom.

---

**Auth model — what it means in plain terms**

"No accounts" = any visitor can browse the map but nobody can save their own ridden roads. Your ridden roads data is visible but belongs to no one.

"Google SSO" = a "Sign in with Google" button. First-time users approve access, get a session. Their ridden roads are now tied to their account. Unauth'd visitors can still browse the public map but can't mark roads. This is the right call — ridden-road tracking is the core loop.

**Implementation**: NextAuth.js with the Google provider. RoadSense's SPEC already calls this out. Since qip-qien has NextAuth wired, the pattern exists — it's not a new discovery. Main work: add NextAuth, add a `users` table to the Drizzle schema, gate the road-marking endpoints, update the UI to show auth state. Rough estimate: 2–3 days of focused work.

---

**Generalization / geo-restriction**

Austin-only for MVP is the right call. This means adding a bounding box check on the API side so new-user sign-ups or road queries outside Austin/Cedar Park return a clean "not available in your area yet" message rather than returning bad scores or empty data. Simple to implement and avoids the "doesn't work in my city" complaint.

---

**Creator posture**

Testing both is smart and low-risk. Suggested split:
- Post 1 (anonymous tool frame): "I built an algorithm that scores roads for motorcycle riding. Here's what it found in Austin." Link to product tour.
- Post 2 (personal frame): "I rode this road because an algorithm told me to — here's what it looked like." Face on camera.
See which format gets more saves/shares, then commit to that lane.

---

**30-day success metric**

Given the niche (motorcycle riders who also want algorithmic road discovery), I'd suggest: **50 signed-in accounts in 30 days**. Not page views — accounts, because that signals someone found it compelling enough to sign in and use the ridden-road tracking feature. That's the behavior that validates the product, not a drive-by visit.

---

**Updated launch checklist (ordered)**

1. ✅ Ridden-roads bug — fixed and verified
2. Add Google SSO via NextAuth — gate road-marking endpoints, add users table, auth UI
3. Add Austin bounding box restriction — clean "not your area yet" for out-of-area requests
4. Verify OSM attribution is visible on the map
5. Set a Mapbox usage alert (50k threshold, email)
6. Soft-launch: r/motorcycles + ADVRider with the product tour video
7. Creator test: anonymous tool post → personal story post → evaluate

OAuth is the only item with real scope. Everything else is a day or less. Want me to scope out the NextAuth + users table implementation in more detail, or pull in what qip-qien already has as a reference?
</message>