Hey Dev.to 👋
I'm Anthony — I spent the last 4 months building Avision from scratch, solo. It's a Google Business Profile management platform that automates local SEO for small businesses and marketing agencies.
I wanted to introduce myself properly by sharing the stack, because that's usually what people here actually want to know.
The stack
Backend: Python 3.10 + FastAPI — running on a Hetzner CX41 (Ubuntu 22.04). The backend handles all GBP API calls, the RAG pipeline, Guardian Mode automation, and the Growth Radar keyword tracking engine.
Frontend/CMS: WordPress with a fully custom plugin (avision-dashboard) — ~300K lines of PHP and JavaScript. I know, I know. But WordPress gives you user management, billing hooks, and a mature ecosystem out of the box. Fighting it costs less than building from scratch.
AI/Intelligence layer: RAG architecture with Qdrant as the vector database (1,373+ knowledge chunks), OpenRouter for LLM routing, and a custom orchestrator that classifies intent, retrieves context, and generates responses in EN/FR/ES. I call it AVI — the intelligence engine behind the platform.
Payments: Stripe — one-time lifetime access plans + monthly wholesale per-location billing for agencies.
Auth: Google OAuth 2.0 — officially approved by Google for GBP API access (received homologation May 2026 after a strict review process).
Infrastructure: Hetzner VPS, CyberPanel + LiteSpeed, MariaDB, systemd services, fail2ban, weekly integrity checks.
What I'm writing about here
- Local SEO and Google Business Profile (the technical side most devs don't cover)
- FastAPI + WordPress architecture decisions (and why I made them)
- RAG in production — what works, what doesn't
- Building in public as a solo founder
If any of that sounds interesting, follow along. First technical article drops next week.
And if you're building something solo — say hi. Always curious what other people are working on.
python, fastapi, webdev, buildinpublic
Top comments (2)
The WordPress-as-frontend choice is more pragmatic than people give it credit for. User management, session handling, plugin ecosystem for billing portals -- building all of that from scratch in a React/Next app takes weeks that could go toward the actual product. The tradeoff is that your frontend and backend are now two separate deployment targets with different failure modes, so your monitoring story matters more than usual. If the FastAPI backend goes down but WordPress stays up, users see a dashboard that looks fine but nothing works.
One thing worth thinking about with the Stripe setup: lifetime access + monthly per-location billing means you have two completely different revenue models running through the same payment infrastructure. The lifetime plan creates a fixed cohort of users whose support cost grows over time but revenue doesn't. The per-location monthly billing scales with usage. Watch the ratio. If lifetime buyers generate most of your support tickets six months from now, you'll want to know early so you can either grandfather them or adjust pricing before the pattern entrenches.
The RAG architecture with 1,373 knowledge chunks is interesting for local SEO specifically. GBP data is highly structured (categories, attributes, hours, service areas) but the questions users ask are unstructured ("why did my ranking drop"). Curious whether your retrieval layer handles the gap between structured GBP API data and freeform user queries, or if those are separate paths.
Regarding the WordPress choice:
That's exactly the trade-off I made. Auth, sessions, roles, billing portal, transactional emails—all of that already exists in the WP ecosystem. The real risk you identified (FastAPI down, WP up) is real and managed on two levels: a Health Check every 30 minutes that alerts by email if the backend isn't responding, and a UX fallback on the JS side that displays a degraded message instead of a silently broken dashboard. It's not perfect, but it's monitored.
Regarding the LTD vs. recurring tension: That's a good point. The current structure: LTDs (AppSumo) provide access to the dashboard and audit, but Guardian and Radar remain monthly wholesale per record. So even an LTD buyer generates recurring revenue if they activate customer records. This partially protects me from the "endless support, zero revenue" scenario—but I will indeed track the ticket/revenue ratio per cohort starting in month two. It's a real short-term monitoring debt.
Regarding RAG and the structured/unstructured gap: These are two deliberately separate paths. Structured GBP data (categories, times, photos, reviews, score/100) is transmitted via the GBP API → DB → PHP payload injected into the context of each request. The RAG Qdrant (1,373 chunks) answers unstructured questions about local SEO semantics—why my ranking is dropping, how to optimize my posts, Google's suspension policy. Both converge in the FastAPI orchestrator, which receives both the DB profile context and the relevant RAG chunks before constructing the answer. The remaining risk: when a question mixes the two ("why did my score drop after changing my category?"), the intent classification must route to both sources. This is the most interesting post-launch task.