Boussole: managing search visibility and Google reviews
Boussole is an SEO management SaaS that I design and build: it connects Google Search Console and Google reviews to an article editor that explains what to fix, all in one place.
Status: version 0.13.0, built and validated in-house on demo data. The application is not yet open to the public, so no access link is offered.
Context and problem solved
Google Search Console provides raw figures that are hard to use on their own. Google reviews are scattered across locations. And articles are often written without knowing exactly what to fix to be more visible.
Boussole addresses these three needs in a single tool: what to act on first to gain traffic, where to reply to reviews, and how to write better articles. It is aimed at a company or an agency that follows one or several sites and locations.
How it works
- SEO module: daily Search Console synchronisation with up to 16 months of history, comparison over time and indicators the console does not compute: “Quick Wins” (keywords in positions 4 to 8), “Near-podium” (positions 2 to 3), cannibalisation between pages, untapped opportunities, brand and non-brand. CSV exports.
- Google Reviews module: reviews from all locations in one inbox, replies published on Google from the tool, response rate and delay, reply templates, listing completeness, bulk updates and posts.
- SEO Editor module: write or improve an article before publishing, with a score out of 100 broken down by criterion, a Google snippet preview, repeated words with synonyms, and a warning when two drafts target the same keyword. Boussole publishes nothing: the HTML is copied into the CMS of your choice.
- Integration options: signed outgoing webhooks, a read-only statistics API (access key valid for one year), scheduled SFTP export and scheduled email reports.
The editor’s score is Boussole’s own, computed from readable rules: it is neither a Google grade nor a ranking promise. No artificial intelligence is involved in the analyses.
Technical choices and architecture
- Stack: Python 3.13 API (FastAPI, SQLAlchemy and Alembic migrations) on PostgreSQL, with the Search Console data table partitioned by month; asynchronous tasks (Celery, Redis) for the daily synchronisation; Next.js 16 interface (Server Components), Tailwind CSS, shadcn/ui and Recharts.
- Isolation: each organisation only sees its own data. The rule is enforced on the server side (session token and data-access layer), never by the interface, and checked by isolation tests between two organisations.
- Security: hashed passwords, encrypted secrets (Google tokens, SFTP credentials), strict session cookies, page import by URL protected against server-side request forgery, SFTP server verified by its fingerprint, signed webhooks, secret detection before every commit.
- Container-based deployment: Docker Compose (proxy, database, cache, API, scheduled tasks, interface) with a Traefik reverse proxy; in production, databases are not exposed, networks are separated, resources are capped and a daily backup is rotated.
- Tests and quality: unit tests, integration tests on real PostgreSQL and Redis, interface tests, a full browser journey and a 320 px accessibility audit; strict linting and typing; standardised commits checked automatically.
- Lean dependencies: every dependency is justified and audited. A dependency audit cut npm packages from 747 to 488 (from 105 to 78 in production), with no known vulnerability in production.
- Documented API: OpenAPI contract versioned and checked by a test, with Swagger UI and ReDoc.
Difficulties and lessons learned
- Data that arrives late: Google publishes Search Console data two to three days late. The default period therefore ends on the last day actually available, to avoid misleading curves.
- Addresses that do not fit in a path: a page URL contains “/” characters that the proxy rejects when they are encoded in a path. Parameters therefore travel in the query string.
- Heavy analyses: calculations are done in SQL rather than with a data-processing library (removed), and measured up to 100,000 keywords. The project log already notes the next step: precomputed daily totals.
- Staying honest about what a score can say: the editor shows Boussole’s score, explains each criterion and promises no ranking.
- Data lifecycle: cascading deletion of an organisation, warning then deletion after prolonged inactivity, to comply with the GDPR.
- Main lesson: write the specification first, then add isolation tests from the very first features rather than afterwards.
Honest status
Today, the three modules (SEO, Google Reviews, SEO Editor) and the integration options are built and validated in-house.
What remains before opening: validate the connection with real Google accounts and a test payment account, test published-page measurement with a real key, connect the email-sending service, have the privacy policy legally reviewed and choose the server. No date is announced.
What this shows about my work
- Designing a multi-organisation SaaS from specification to operation, with tested data isolation.
- Integrating third-party APIs (Google Search Console and Business Profile) while handling real-world constraints: delays, quotas, consents.
- Building security, GDPR compliance and accessibility in from the design stage.
- Documenting: user guide, specification, technical documentation and API contract.
A management tool to build?
Describe it in a few lines and I will tell you how I can help.