The problem
Pet owners search across a fragmented landscape, Yelp for vets, Google for groomers, Rover for sitters, Facebook for trainers. None are pet-first; none reliably surface attributes what pet owners actually care about. On the other hand, small pet-services businesses lose first contact with platforms that take 15–40% of every transaction. Three problems run together: discovery (Google Places doesn’t tag pet-friendly), trust (incumbents have eroded after public incidents and high fees), and lead conversion (no system exists to auto-route low-digital-presence businesses to outreach).
The AI approach
AI is applied only where the alternatives are “do it manually” or “don’t do it at all.”
- Pet-friendly attribute extraction. Apify retrieves business websites at request time; a keyword-driven NLP pass identifies pet-friendly signals (“dogs welcome,” “pet-friendly patio”) that Google Places APIs miss. Manual curation was rejected as unscalable.
- Lead scoring and triage. Every business is scored on six signals (missing website, low review count, weak rating, stale data, category density, contact gaps). Hot leads auto-route to localvalue.co’s outreach queue; medium and cold leads land in admin review. This keeps human attention on the highest-conversion opportunities.
- Provider risk scoring (gig-services). Pet aggression flags, owner reliability signals, and provider trust-tier promotion run on a composite risk score recalculated nightly, calibratable as data accumulates.
The PM principle: never use AI where rules are enough. Never use rules where lookup is enough. AI sits in the seams where structured data falls short.
The architecture
| Layer | Choice |
|---|---|
| Framework | Next.js 14 + TypeScript |
| Database | PostgreSQL via Prisma |
| Hosting | Single Vercel deployment, four domains via middleware.ts |
| Geo data | Google Places API (New), 30-day TTL per ToS, 0.1° grid-cell caching |
| Enrichment | Apify (webhook-async); /api/enrich submits, results return out-of-band |
| Email / SMS | Resend, Twilio |
| Marketplace stack (scaffolded, gated) | Stripe Connect Express, Checkr, FairClaims arbitration |
Three properties: local.pet, local.dog, vetsnear.me. share one backend, one deployment, one database, with frontends differentiated by middleware-injected site config. v1 launch surface (listings + contact form) ships first; the full Rover-style booking, escrow, reviews, and dispute layer is built and feature-flagged until activated.
The outcome
- Live in production. Core data engine, map UI, multi-domain routing, server-rendered SEO-grade detail pages all shipping.
- API cost discipline. Daily Google Places spend cap with alerting; grid-cell caching prevents duplicate calls; 30-day TTL on protected fields per Google’s terms.
- Disciplined buildout. Every architectural decision lives in a dated decision log. Every feature gets a per-feature PRD before implementation. v1 scope was deliberately narrowed to validate the directory + lead model before the marketplace layer.
- Built solo by a PM with thirty years of product leadership, single codebase, proper auth, role-based access, schema-first data modeling, documented stub-to-production gating for features that exist in code but aren’t yet user-facing.
What’s next
Phase 4 (Data Integrity) shipping now: Apify crawler expansion, multi-signal dedupe, monthly rescrape cron. Phase 5 activates the scaffolded marketplace, provider onboarding wizard, real Stripe Connect, real Checkr, real FairClaims. Phase 6+: lead pipeline integration with localvalue.co, payments live, geographic expansion beyond the pilot ZIPs.
Want help applying this approach to your business? · roblewis@localvalue.com · localvalue.com