The Platform

Problem

Shipping several small AI-powered products as one engineer means every app re-solves the same problems: AI provider access, cost control, deployment, monitoring, conventions. And LLM APIs bill by usage — one runaway loop in a hobby app can cost real money. The goal: run many small apps without rebuilding infrastructure each time, and without ever letting AI spend go unmetered.

Solution

A personal platform of small single-purpose services, each in its own repository with self-describing metadata, all sharing one version-pinned contracts library. Every AI call flows through a single AI gateway that alone holds the provider keys, which makes cost control architecturally impossible to bypass: a synchronous pre-flight budget check before each call, asynchronous usage events over Kafka after it, and automatic downshift to a free local model when spending nears a ceiling. A control plane owns the app registry and scaffolds new repositories from templates; everything runs local-first on Docker Compose and streams live state over server-sent events to swappable dashboards. The platform is also an experiment in method: each repository is built by an AI coding agent working from a written spec, with decision logs and human review gates — software about running AI, built with AI. As the fleet grew, the method grew its own infrastructure: agents in different repositories coordinate through a demand protocol — a repo that needs something from a sibling raises a formal request, a coordinator service validates and dispatches it, and a human approves the result — and every repository carries a persistent operational memory (session journals, decisions, a queryable knowledge base) so each agent session starts where the last one ended. A design studio built on the same rails produces the visual themes the platform’s apps ship with.

Features

• One AI gateway holding all provider keys
• Budget ceilings with synchronous pre-flight cost checks
• Automatic downshift to local models near a spending ceiling
• Self-describing repositories scaffolded from templates
• Version-pinned shared contracts across every service
• Live platform state streamed over server-sent events
• Cross-repo agent coordination via a gated demand protocol
• Per-repo operational memory so agent sessions build on each other

Architecture

1. Apps
2. AI gateway — sole key holder
3. Budget pre-flight
4. AI providers / local models
5. Usage events over Kafka
6. Live state feed
7. Dashboard

Tech

• Java
• Spring Boot
• Angular
• Kafka
• PostgreSQL
• Docker Compose
• Server-Sent Events
• Hexagonal architecture
• AI coding agents

Challenges

• Making cost enforcement impossible to bypass rather than merely discouraged — solved structurally: only the gateway holds provider keys, so there is no path around metering.
• Keeping dozens of small repositories consistent as a solo engineer — solved with a conventions library, repo templates and a compliance validator.
• Evolving shared contracts across many consumers without breakage — solved by publishing them as a pinned, versioned package.
• Coordinating changes that cross repository boundaries when every agent works inside exactly one repo — solved with the demand protocol: requests are files, dispatch is a service, approval is human.

Lessons

• Boundaries enforced by structure beat boundaries enforced by discipline: a rule the filesystem enforces cannot rot.
• Spec-first, agent-built development works when the spec is the source of truth and a human holds the review gate.
• Metering belongs at the choke point, not in every app.

Future work

• Move from local-first to hosted once the first product goes commercial
• More apps on the same platform rails
• A richer live visualization of platform state