Hugo RibaudAI consultant and trainer in Marseille, freelance developer

Problem Statement

The marketing lead had to reach 3,000 content creators with a message tailored to each profile, alone and without technical skills. Three segments coexisted, each with a different commercial approach. Writing each personalised email by hand took time the volume simply didn't allow, and generic personalisation produced no replies.

Technical Approach

• Session 1: architecture of an automated outreach workflow, chatbot subscription versus API, hands-on with the orchestration tool on a real case
• Session 2: building the end-to-end pipeline and writing the per-segment prompts, on test data
• Session 3: full run validated, and a deliberate call to pause web enrichment in order to launch on a simple, well-understood foundation
• Session 4: connecting the pipeline to her own spreadsheet, duplicate-send protection, official signature, controlled test emails
• Ongoing support: written recap after every session, versioned standard operating procedure, sending guardrails while the system is in test

Technologies Used

Key Learnings

• In hands-on training, what each session ships matters more than the syllabus: the trainee has to leave with something that runs
• The trainee creates her own accounts, API keys and connections. In the fourth session she was the one who caught a formatting trap before it happened, an amount that would have turned €3,200 into €3.2, because she had run into it elsewhere. That's the point where training flips: she stops executing and starts checking.
• Cutting an appealing but fragile component (web enrichment) to launch on a simple foundation saved two weeks
• Data sovereignty came up at the kick-off, not at the end: for an SME, knowing where the data lives is a prerequisite, not an extra
• A spreadsheet as the control panel is what makes the system genuinely autonomous: she decides who gets contacted, without going through me

Problem Statement

The executive handled his board communications, risk tracking and opportunity monitoring by hand. Each task took a disproportionate amount of time, and nothing in his daily work told him where AI could concretely help.

Technical Approach

• Audit of recurring tasks and setup of the working environment on his real documents, on his own machine
• Three automations built with him: assignment risk radar, board communication, end-of-assignment report
• A weekly briefing, scheduled and prepared automatically before his week starts
• Monthly follow-up: syncing his workspace across two machines, and adapting the automations to each new assignment

Technologies Used

Key Learnings

• Non-technical profiles often get the best results: they have no preconception of what AI 'should' do
• Working on the client's real files from minute one removes the abstract demo phase entirely
• The clearest return is on recurring reporting, because that's where the task repeats identically
• A monthly engagement only works if the client builds alongside you, otherwise it turns into support instead of evolving the setup

Problem Statement

Emails, calendar, leads, tickets, notes, server monitoring: each tool has its own interface, and nothing connects them. Consumer assistants can't see these tools, or ask to be handed every access. I wanted an assistant wired to my own sources, hosted at home, and unable to do anything I hadn't planned for.

Technical Approach

• Spec, mockups and implementation plan written before the first line of code, then development driven by AI agents, reviewed at every step
• Connectors to email, calendar, CRM, Linear, Obsidian notes, weather, monitoring, and server and NAS updates
• A voice agent with 15 tools: look up, search, capture a note, create a ticket, log time
• Security first: no public access (Tailscale private network), identity check, unprivileged container, and the most sensitive credentials read by the host server instead of being handed to the app
• Continuous deployment after every integration that passes the tests, with no expiring access key (OIDC identity federation)
• Transparency about data flows: voice goes through ElevenLabs and reasoning through Claude (Anthropic), outside France. These services see the content of the conversations and the brief, never the tools' credentials

Technologies Used

Key Learnings

• Writing the spec before the code changes the pace: the fundamental questions are settled before the first line, and every trade-off stays on record (66 in the v1 review)
• An assistant that acts needs a written scope: each voice tool does one precise thing, and nothing else
• Security is decided in the architecture: a network shared with other services would have been enough to bypass the identity check
• Sovereignty has to be stated plainly: high-quality voice currently goes through services outside Europe, and the client should choose knowingly

Problem Statement

The association was running on an aging Java/Spring Boot 2.7 + Vue.js legacy system that was expensive to maintain and limited in features. They needed a modern ecosystem covering their various activities (mediation, training, debate) with reliable and cost-effective infrastructure. Additionally, 255 reflection questions were managed in Google Sheets, unusable during training sessions.

Technical Approach

• Complete migration from Java/Spring Boot 2.7 + Vue.js to Next.js 16 + Supabase, planned in 7 phases
• Multi-application architecture: Argumenter (complex business app with classes, arguments, challenges, real-time votes, QR codes), Logos (toolbox), Réfléchir (debate roulette with 255 topics), Website (showcase)
• Réfléchir: migration from Google Sheets to Supabase PostgreSQL, interactive SVG roulette, live projection mode for training, admin dashboard
• Self-hosted VPS infrastructure: Docker containers behind Caddy, API gateway moved from Kong to Envoy in August 2026 with no downtime
• Self-hosted multi-tenant Supabase: data isolation through Row-Level Security and RPC functions, PostgreSQL upgraded from 15 to 17 in June 2026
• Automated monitoring: Beszel, Uptime Kuma, Sentry, scheduled health checks, backups and restore tests
• Real-time alerts via ntfy for incidents and backups
• CI/CD with GitHub Actions for automated front-end app deployments

Technologies Used

Key Learnings

• Migrating a Java/Spring Boot monolith to Next.js + Supabase without downtime comes down to rigorous phase-based planning
• Self-hosted multi-tenant Supabase requires careful API gateway and GoTrue configuration for data isolation
• Automated monitoring is essential for reliable self-hosted infrastructure
• Caddy greatly simplifies TLS/HTTPS management compared to Traefik for small infrastructures
• A 4-app ecosystem can run for around €13/month on a well-configured VPS
• Transforming an existing client tool (Google Sheets) into a web app reduces the adoption curve to zero
• Live streaming mode requires fine-grained state and animation transition management

Problem Statement

International camps managed everything on paper and Excel: restaurant menus, event programs, emergency contacts, announcements. Each new site required weeks of configuration. Residents constantly harassed the front desk for basic information, and low-connectivity areas made traditional cloud solutions unusable.

Technical Approach

• Multi-tenant architecture enabling new site deployment in less than a day with full customization
• React Native/Expo mobile app with offline-first support for limited connectivity areas
• Next.js web CMS allowing non-technical teams to manage content autonomously
• Supabase real-time synchronization for urgent announcements and updates
• Push notification system for instant communication with residents
• Robust REST API with offline sync conflict management
• Infrastructure with Supabase PostgreSQL database

Technologies Used

Key Learnings

• Well-designed multi-tenant architecture from the start enables massive scalability without rewriting
• Offline-first mode is crucial for field applications - connectivity should never be assumed
• An intuitive CMS drastically reduces support requests and empowers teams
• Managing a solo project of this scale requires rigorous discipline and modular architecture
• Real-world testing (isolated camps) reveals edge cases impossible to anticipate in development