GARSON

A live product (11 microservices, web + mobile) with AI day-planning, any model you choose — built by a coordinated AI team: Codex, Claude Code.

Comment

Inspiration

I wanted a personal productivity system that actually plans my day instead of just listing tasks - and I wanted to find out how far a solo founder can go by directing a team of AI agents rather than writing every line by hand. GARSON became both: a real product I use daily, and a live experiment in AI-orchestrated engineering.

The name comes from the French "garçon" - the attendant who anticipates what you need. That's the idea: an assistant that plans, remembers, and quietly keeps your day organized.

What it does

GARSON is a personal productivity OS:

  • AI day-planning - describe your day in natural language ("call Nikki tomorrow at 15:00 for the Website project") and GARSON schedules it.
  • Calendar - day / week / month / year views, recurring tasks, focus-mode timer tied to the actual task duration.
  • Projects and tasks - Kanban boards, Gantt-style progress bars, attachments, comments.
  • Any AI model, your choice - a multi-provider architecture (OpenAI, Anthropic and others) with bring-your-own-key support, so the AI layer isn't locked to one vendor.
  • Real infrastructure for real users - 5 languages, Telegram bot integration, social/friends, in-app messenger.

It's live in production at app.garson.su - not a demo environment spun up for this hackathon.

How we built it

GARSON is 11 Go microservices (auth, core, realtime, files, audit, notify, ai, social, messenger, worker, tgbot), a Next.js web app, and a Flutter mobile app, backed by PostgreSQL, Redis, RabbitMQ and MinIO, deployed via Docker Compose behind Nginx with Prometheus/Grafana/Loki observability.

What makes the "process" unusual: development was directed by a solo founder coordinating a small team of AI agents with distinct roles -

  • an "architect/reviewer" agent that designs, accepts work only after observing it live in production, and maintains a running non-conformance register of every defect and its root cause,
  • a "builder" agent that implements features,
  • Codex, reviewing changes before they ship,
  • an independent "auditor" agent that red-teams the product for security and UX gaps a builder would miss.

For this hackathon, we extended GARSON's existing multi-provider AI layer to run its day-planning on Codex throughout the sprint to review the changes.

Challenges we ran into

  • "It compiles" is not "it works." Several regressions only became visible when tested against a live database or the real production endpoint - a hardcoded schema in a test file quietly drifted from the real migration, and a one-line bug (an empty string being converted to NULL against a NOT NULL column) resurfaced three times across different code paths before we grepped every occurrence instead of just the one in the bug report.
  • Deploy pipeline correctness. A version-mismatch in our diff-based deploy pipeline once caused a partial rollout - fixed with a version-aware deploy gate that now blocks any release where the live service version doesn't match the deployed commit.
  • Multi-tenant safety. Adding new resource types (task attachments, comments) meant re-verifying cross-tenant access on every new endpoint by hand — automated scanners don't catch IDOR-class bugs.
  • i18n at scale. Adding a translation key to the dictionary isn't the same as actually using it in the UI — we caught several places where strings were "translated" in the JSON file but still hardcoded in English on screen.

Accomplishments that we're proud of

  • A genuinely production system, not a hackathon prototype: real users, real deploys, a real incident-and-lessons-learned register instead of "it worked on my machine."
  • A model-agnostic AI layer that can run on GPT-5.6 today and something else tomorrow without a rewrite.
  • A development process where every acceptance is proven by observing production, not by trusting a status report - which caught real bugs before they reached users.

What we learned

That the hardest part of building with AI agents isn't getting code written - it's building the discipline to verify a claim of "done" against reality every single time. The same lesson that makes for good engineering makes for good AI-agent management.

What's next

Multi-day/multi-week task support, richer collaboration (shared tasks, real-time presence), and deeper natural-language planning as the AI layer matures.

Built With

Share this project:

Updates