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 (1)
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.