Case study · Internal platform
RAHO Platform
A multi-app clinic ecosystem I architected and built end-to-end with agentic AI.
In developmentPrivate repo ×17- repositories
- 17
- Go BFFs
- 6
- Flutter apps
- 4
- faster
- 8×
Explore the architecture & case study
Clients
Gateway
Backend-for-Frontend
Core & AI
Clients
Member app · Flutter
Patient/member app (35 screens): self-service booking, membership card & packages, medical records & lab results, optional TOTP MFA, three languages, light & dark mode. 15 repositories call the real Member BFF via Dio.
Clients
Home-care app · Flutter · offline-first
Field health-worker app (11 screens): records therapy sessions at patients’ homes, vitals & materials, an idempotent write outbox, prefetch before signal drops and local draft autosave.
Clients
Executive AI app · Flutter · AI
AI assistant for directors (12 screens): text chat, voice, conversation history and reminders. Sign-in requires three factors: password, executive role and a TOTP code.
Clients
Employee (ESS) · Flutter
Employee self-service app that reaches the backend through the gateway, with error reporting to a self-hosted GlitchTip.
Clients
Internal web · Next.js · Turborepo
A Turborepo monorepo for the Doctor, Operations (CS, lab, logistics, finance, marketing), HR and Partner web apps — sharing one tested RBAC guard package.
Clients
Landing page · React · Vite
Public landing page with React 19, TypeScript, Tailwind CSS and Framer Motion; CI typecheck + build and image releases to GHCR.
Gateway
API Gateway · Kong
A single entry point for every client; each app family gets its own route to its BFF.
Gateway
Realtime gateway · Go · LiveKit
Issues LiveKit (WebRTC) tokens for member ↔ CS voice calls, verifying member JWTs with a public key — pure Go stdlib, zero external dependencies. Tokens are verified end-to-end against a real LiveKit server.
Backend-for-Frontend
6 BFF services · Go · OpenAPI
member · clinical · operasional · hr · mitra · executive
One BFF per app family, written in stateless Go stdlib. Contract-first APIs (OpenAPI), RS256 JWTs scoped by platform role, deny-by-default authorisation, and identity/branch always taken from token claims — never from client input.
Core & AI
Odoo 19 · Python · PostgreSQL
System of record: all data and business logic live in Odoo with custom addons. BFF mutations run through Odoo logic and guarded facades, so every actor’s authority is re-checked.
Core & AI
AI orchestrator · FastAPI
The only component holding AI vendor API keys: guardrails, a per-role tool registry, two-step write confirmation with HMAC tokens, quotas & a cost breaker, and an audit trail — guarded by 297 tests.
Core & AI
MCP server · Python · FastMCP
The AI’s “hands” into Odoo: validated, read-only MCP tools capped at 50 rows per call, with every invocation written to an audit log.
Technical highlights
- Odoo 19 as system of record; every app family gets its own Go BFF with a contract-first OpenAPI spec.
- Layered security: scoped RS256 JWTs, deny-by-default, TOTP MFA for executives, and separate JWT keys for external partners.
- Clean-architecture Flutter apps (BLoC, GoRouter, get_it) — including an offline-first field app with an idempotent outbox.
- Measured optimisation: the lab-results screen went from 72 queries / 214 ms to 6 queries / 29.5 ms after an N+1 fix.
My role
Sole architect & engineer — requirements, architecture, implementation and deployment, with Claude Code & Codex.
Private company repositories — technical details can be discussed directly.
- Odoo ERP
- Python
- Go
- Flutter
- Dart
- BLoC
- GoRouter
- Next.js
- React
- TypeScript
- FastAPI
- PostgreSQL
- Kong
- LiveKit
- WebRTC
- Docker
- OpenAPI
- JWT
- MCP
- Claude Code
- Codex
- Turborepo
- GitHub Actions
- Firebase
