Static pages go stale.
Service pages written once stop signaling freshness; Google rewards pages showing ongoing, real activity.
Local-SEO proof, automatically
Turn finished jobs into proof that ranks.
FieldPins captures real work from the field, routes it through human approval, and publishes privacy-safe, crawlable local-SEO proof to your website — service page and city page, automatically.
Piloting with RD Hydrojet Plumbing · powered by CoreShift multi-tenant infrastructure.
The problem
Three ways local-SEO proof breaks.
Black-box SaaS owns your content.
Competitors inject pins via a JS embed from their servers — not truly crawlable, and if they leave, your proof leaves with them.
Auto-publish ships mistakes.
Tools that publish the instant a tech taps submit put unreviewed captions and customer-identifying photos straight onto your public site.
How it works
From the field to a ranking page — with a human in the middle.
- 01
Capture
A tech submits a photo, a one-sentence caption, the service, and the city — from a phone. No app, no login: just a password-protected page.
- 02
Review
AI drafts the description and alt text; an image scrubber flags anything privacy-risky. Everything lands in a pending queue.
- 03
Approve
The owner edits and approves. Nothing goes public automatically.
- 04
Publish
Approved proof renders as server-side HTML + JSON-LD on the matching service page and city page.
- 05
Rank / convert
Real, geo-specific proof builds local relevance — and every card ends in a call to action.
Architecture · powered by CoreShift
One shared engine. Isolated data per customer. A human gate before anything goes live.
FieldPins runs on CoreShift, a multi-tenant bot platform. The four planes below are that platform — the real system that serves every customer, not a marketing illustration.
The CoreShift platform
-
Plane 01 · Client edge
Customer-owned delivery
Each customer's website carries a thin delivery adapter. On WordPress it's a small plugin that fetches approved pins server-side and caches the HTML into the page template — so the proof is in the server response, not injected by JavaScript, and is fully crawlable. Non-WordPress sites use a generic SSR fetch endpoint. Content lives in FieldPins, so the customer can always export it — no JS-embed lock-in.
-
Plane 02 · Control plane
Shared platform schema
A single platform-level schema holds the tenant registry, the bot registry (base prompts, model, token caps), authentication, and billing / metering. Shared infrastructure — not per customer.
-
Plane 03 · Bot pool
Shared, stateless workers
One pool of stateless workers serves every customer — never a bot per customer, only per-customer invocation context.
- Description Writer — caption → a 3–5 sentence service / city description in the customer's voice.
- Image Privacy Scrubber — vision scan for plates, faces, house numbers, paperwork → pass / auto-crop / flag-and-hold. A core differentiator.
- Alt-text Generator — accessible alt text for every published image.
- Content Variation / dedup — rewrites opening lines so many pins on one page never read like a template.
-
Plane 04 · Per-tenant data
Isolated Postgres schemas
Every customer is a separate Postgres schema holding pins, submissions, taxonomies, private fields, approvals, and audit. A bot never opens its own connection or chooses a schema — the orchestrator hands it a session already scoped to the right tenant. Isolation is enforced at the orchestrator, not trusted to the bot.
Rendering authority stays in FieldPins — and it's deterministic. Approval, card rendering, and JSON-LD generation are platform code, not AI. Output is byte-stable and crawlable, so a model change can never silently alter what Google indexes. That's what lets the edge adapter simply fetch and cache server HTML.
Scaling. Bots scale horizontally as a stateless pool; customers scale as cheap schema additions. Adding a customer is a row and a schema — never a deployment.
Built for your business
One engine. Every business sounds like itself.
How does one engine serve a plumber and an electrician without sounding generic for either? Everything customer-specific is data, injected at invocation time.
The tenant config
Control plane, per customer:
- Brand voice + tone
- Service vocabulary + banned-phrase list
- Service taxonomy + city / service-area taxonomy (seeded per customer)
- Privacy thresholds
- CTA copy + click-to-call number
- Locale / spelling
- Per-bot prompt overrides
- Billing plan
The BotContext
Built per submission, handed to the bots:
BotContext = merge( platform_defaults, // bot registry: base prompts, model, token caps tenant_config, // voice, vocab, privacy thresholds, CTA, taxonomies, locale submission_payload // this job's caption, service, city, photo )
Bots read context and return a result. They never read tenant config themselves and never pick a schema — that property is what keeps them stateless, testable without a tenant, and safe across customers.
Same engine · two tenants
Toggle a tenant. Watch the output change.
Submission + tenant config
Geotagged · Murrieta
"Cleared a fully blocked main line for a homeowner."
Hydro jettingMurrieta
- Voice
- plain, neighborly, reliability-focused
- Vocab
- hydro jettingdrain & sewerhose bibwater heater
- Area
- MurrietaTemeculaMenifeeWildomar
- Banned
- 24/7guaranteed
- Privacy
- faceslicense plateshouse numbers
- Schema
- tenant_rdh
Published proof + JSON-LD
RD Hydrojet · Plumbing
We cleared a fully blocked main line for a homeowner in Murrieta, using hydro jetting to cut through years of grease and root intrusion and restore full flow. It's the kind of drain & sewer work we handle for neighbors across the area — done right the first time.
Need the same service? Call RD Hydrojet.
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "Hydro jetting",
"provider": { "@type": "Plumber", "name": "RD Hydrojet" },
"areaServed": ["Murrieta", "Temecula", "Menifee", "Wildomar"],
"description": "Hydro jetting in Murrieta — cleared a fully blocked main line, cutting through grease and root intrusion to restore full flow."
}
For agencies
Because customers are schemas behind one engine, an agency can run many clients on FieldPins with per-client branding, taxonomies, and privacy rules — without separate installs. Metering is per AI action, so billing maps cleanly to usage.
Privacy-first
What goes public is a short list. What stays private is the rest.
Every published pin is built from a fixed set of public fields. Everything that could identify a customer or their home is held back by default — and kept out structurally, not by policy alone.
Always public
safe to crawl- Service type
- City / state
- Month completed
- Approved photo
- Public description
- Alt text
- Call to action
Never public
held back- Exact address
- Customer name, email, or phone
- Raw tech notes
- GPS coordinates
- Faces, license plates, paperwork — unless explicitly approved
Privacy is enforced in three places: the scrubber bot at intake, the human approval gate, and the schema generator — which is structurally incapable of emitting private fields.
Why not just use DataPins
A straight comparison — no inflated numbers.
DataPins is a capable local-SEO pin tool. The differences below are about approach — how proof gets published, who owns it, and how much you can see. We don't claim specific ranking gains; only structural differences you can verify.
| Capability | FieldPins | DataPins |
|---|---|---|
| Admin approval before publishA human gate keeps unreviewed captions and customer-identifying photos off your public site. | Required | Publishes on submit |
| You own your dataIf you ever leave, your proof and pages should stay with you — not disappear with the vendor. | Your schema, export anytime | Held in vendor platform |
| Crawlable proofProof in the server response is reliably crawlable; JavaScript-injected content isn't guaranteed to be read the same way. | Server-rendered HTML + JSON-LD | JavaScript embed |
| CTA on every cardEvery piece of proof should give a visitor a clear next step. | Built in | Not standard |
| Documented privacy controlsYou should be able to point to exactly which fields are published and which are held back. | Scrubber, approval, schema-level | Not documented |
| Transparent architectureYou can audit how it works before trusting it with customer photos. | Published on this page | Not published |
| Transparent pricingBilling should map to usage you can actually see. | Metered per AI action | Quote-based |
| WordPress-nativeNative server-side rendering keeps the proof inside your page, not inside a script or iframe. | Server-side plugin | Embed widget |
Comparison reflects differences in published approach, not benchmarked SEO results. Verify competitor specifics against their current product before relying on them.
Case study · RD Hydrojet
Evidence in progress · 90-day window running
Our first pilot, measured in the open.
RD Hydrojet is live on FieldPins. We won't show numbers we don't have yet — the 90-day measurement window is still running. Here's exactly what we set up and what we're tracking, so the before/after we publish later is verifiable rather than a highlight reel.
Setup
tenant_rdh — seeded and live
A dedicated tenant schema, seeded with RD Hydrojet's services and service-area cities. Approved pins render server-side onto the matching service and city pages of their WordPress site.
- Services
- Hydro jettingDrain & sewerHose bibWater heater
- Cities
- MurrietaTemeculaMenifeeWildomar
- Schema
- tenant_rdh
What we're measuring
-
Search ConsoleBaseline captured
Clicks & impressions on the service and city pages where pins publish.
— pending -
GBP activityMeasuring
Google Business Profile views and actions over the window.
— pending -
Inbound callsMeasuring
Calls from tracked numbers on the published pages.
— pending -
Approval rateMeasuring
Share of submissions the owner approves as-is vs. edits or rejects.
— pending -
Page-speed regressionWatching
Core Web Vitals before vs. after pins, to confirm SSR adds no slowdown.
— pending
The promise: when the window closes we'll publish the real before/after — the actual Search Console and call numbers, with the baseline shown alongside. If a metric doesn't move, we'll say so.
“ Quote pending approval ”
Pricing model
Two parts, both honest.
No per-seat games and no surprise overages. You pay for the platform and for the AI work you actually use — nothing more.
Part 1 · Subscription
Base FieldPins platform
Flat monthly base
Your tenant, the approval workflow, and crawlable server-side delivery to your site — the foundation that's always on.
- Tenant schema + data ownership
- Human approval gate
- Server-side delivery (WordPress plugin / SSR endpoint)
Part 2 · Usage
Metered AI actions
Per bot invocation
Each AI step is metered as you use it — description writing, privacy scrubbing, alt text, content variation. A quiet month is a smaller bill.
- Charged per bot invocation
- Scales with real activity, not seats
- Usage you can see and audit
You pay for the platform and for the AI work you actually use. Exact figures land with early access — join the waitlist and we'll share the numbers as the pilots wrap.
Early access
Get FieldPins on your site first.
Tell us about your business and we'll reach out as early-access seats open. Pilots first, broad access soon after.
Confirmed
You're on the list.
We'll be in touch as soon as your seat is ready.
Something went wrong on our end. Please try again or email us directly.