Build plan, architecture & economics for the $1,800/mo attorney tier. Sign in to continue.
Low-touch. Dashboard-as-product. Heavy front-loaded onboarding, near-zero recurring labor — and the recurring value carried by live competitive data they can watch move. Served per-client at {firm}.legalrankings.com.
We already run a full DataForSEO + GBP + GSC pipeline across the entire attorney market (~2,700 domains) every week. For a signed client, the dashboard is mostly a filtered view of data we already pay to collect — so the marginal cost of the "intelligence" half is near zero. The new engineering is the action plane (the things we do for them) and the premium per-client lookups (AI-citations, AI Overview, deep backlinks) that don't scale to 2,700 domains but are trivially affordable for ~10 signed clients. That asymmetry is the business model: front-loaded build, near-free recurring delivery, premium data as the moat.
Bought separately — web rebuild, rank tracker, local-grid tool, GBP & review management, backlink tool — this is $1,500–3,000+/mo and still wouldn't include AI-citation work or a competitor-relative dashboard. We bundle all of it.
Rebuilt on our edge with JSON-LD schema, clean meta, and auto-indexing. Front-loaded build.
Where they rank, on the map grid, vs. every competitor — review velocity, keyword movement, a leads north-star.
GBP posts published automatically; review replies drafted and sent (operator-approved); GBP/NAP health monitored.
AI-citation footprint (Knowledge Graph), AI Overview presence, deep backlink intelligence — affordable only because the roster is small.
Form on the site we host → instant Slack + SMS + email, every lead captured for the leads/month number.
Auto-generated from live dashboard data, lands in their inbox — proves the $1,800 without them logging in.
Every part of the system is one of three things. The separation lets the cheap, already-built read-side ship first and keeps the risky write-side isolated. Tenancy lives entirely in the app layer — we filter shared BigQuery tables by each account's CID list at query time, and never write org_id back into the pipeline.
GBP posting, review replies, GSC submission, and GA4 read all require the client to grant OAuth access to their Google properties. Google Business Profile API access approval is the single longest lead-time item — apply for it the day this is greenlit, not at build time.
Each is scored on one question: does it keep the dashboard worth opening between logins? The status dot on every surface shows whether the data already exists, needs wiring, or is net-new work.
The "100% automated" promise to the client is honest: the client does nothing. The only human is our operator approving review replies — a few clicks a week across the whole roster, which is what keeps it low-touch and safe.
| Worker | Mode | How it works | Human gate |
|---|---|---|---|
| GBP post publisher | Auto | LLM draft → guardrail filter (no guarantees, no fee claims, no confidential detail) → publish on cadence. | Guardrail; failures → queue |
| Review-reply queue | Approval | LLM draft tuned to star rating + content, de-escalation template for negatives → operator console. | Operator approves every one |
| Review sentiment | Auto | LLM over the review stream → theme tags + negative flags on dashboard and in alerts. | None |
| GSC submitter | Auto | We control deploys, so we know the page diff → sitemap + URL-inspection submit, status per page. | None (low risk) |
| Intake router | Auto | Form on the site we host → instant Slack + Twilio SMS + email; every lead persisted. | Spam filter |
| Alert engine | Auto | Rank drop / new review / competitor surge / SoLV drop / token failure → email + SMS, frequency-capped. | Frequency cap |
| Monthly report | Auto | Render dashboard headless (Playwright → PDF), branded, plain-English "what changed" → email. | Optional glance |
GBP posts auto-publish (guardrailed). Review replies go through the approval queue — a bad auto-reply to a 1-star review on a law firm is a real liability, so they're never auto-sent.
Month 1 is expensive (reskin-heavy). Months 2–12 are nearly free to deliver. That's an excellent margin profile and a dangerous shape: if the dashboard goes stale, the client cancels once the site is done. Every design decision is judged on whether the screen keeps earning $1,800.
The intelligence half rides the shared pipeline (sunk cost). The genuinely per-client incremental cost is tiny:
| AI Overview (008f) | cents/wk |
| Deep backlinks (009x) | ~$1.50/wk |
| KG population (011a) | cents |
| LLM drafting (posts + replies) | cents |
| GBP / GSC / GA4 APIs | $0 (free tiers) |
Base $1,800/mo — all seven modules, full dashboard, premium data, monthly report, alerts.
Add-ons (protect base margin):
GBP posts + review replies are the only true recurring labor. If they aren't genuinely automated (LLM + guardrails + queue), they silently eat the tier's margin at scale. Build the guardrail layer before selling.
Because month 1 is expensive and months 2–12 are cheap, a client who cancels at month 2 is a loss. Needs a 12-month term or a separate onboarding/setup fee.
Take one real client fully through every plane before scaling the roster. Ordered by value-per-effort: ship the cheap, already-built read-side first (it's the demo that sells the tier), then onboarding, then the genuinely-new action plane, then premium + retention.
Longest pole: Google Business Profile API access approval. Start it in Phase 0/2, not Phase 3. The read-side (Phase 1) is the demo that sells the tier — it's cheap and uses existing data, so build it early, even before onboarding machinery.
Defaults are noted where there's an obvious choice — flagged for confirmation, not invented silently.
Confirm the GBP API + Indexing API access path and quota. → The blocker. Apply Phase 2.
Operator console vs. client-facing approve button. Default: operator console (keeps it low-touch for the client).
Replace their form with ours on the reskinned site? Default: yes — we own the site, so we own the form.
VM cron vs. GitHub Actions. Default: VM cron alongside the pipeline.
Needed to cover the front-loaded month-1 cost against early churn. → Decide before selling.
{firm}.legalrankings.com wildcard → VM confirmed; verify CF cleanly splits apex (Pages) from wildcard (VM). → Verify Phase 0.
Verified against the live codebase, June 2026. The foundation already exists.
| Asset | Path | Role in Saul |
|---|---|---|
| Portal Flask shell | app_dot_site/portal/ | Auth, sessions, slug→account resolver, SQLite tenancy, manage.py CLI. Clone + reskin. |
| Dashboard SPA | app_dot_site/dashboard/index.html | Finished 7-section vanilla-JS dashboard (synthetic data). Wire to real per-account JSON. |
| Metric generator | atty_dashboard/generate_data.py | Proven BQ→JSON pillar/SoLV/weighted-visibility model. Extend to take a CID list. |
| Pipeline | pipeline/steps/ (10 phases) | Already produces ~90% of the dashboard's data for the whole market. |
| Account design specs | app_dot_site/app_sections/*.md | Locked pillar + account-layer design. |
| Sales site + CF zone | legalrankings_site/ | Apex/www stay here; *.legalrankings.com → VM for client dashboards. |
The read-side demo is the cheapest, highest-leverage build and the thing that sells the tier. The Google OAuth / GBP API approval is the long pole — start it the day this is greenlit.