Skip to content

Use case

The best way to evaluate Delta AI is to read what it produced. A full Discord-style communication platform was built and published openly, with its entire history intact.

What was built

Section titled “What was built”

A real-time community platform for creator and fan communities: text chat, voice and video rooms, invite-based membership, friend connections, email notifications, and moderator tooling with roles, timeouts, bans and an audit log.

Six TypeScript services, each a standard container image:

Service Responsibility State
identity_service Mirrors the identity provider’s users, owns profile data PostgreSQL
community_service Communities, roles, permissions, moderation, audit log PostgreSQL
chat_service Message history, idempotent sends, transactional outbox PostgreSQL
realtime_gateway WebSocket fan-out to connected clients Stateless
voice_service Room access tokens, moderation enforcement Stateless
notification_service Transactional email, invite delivery PostgreSQL

The system design

Section titled “The system design”

The architecture step produced one overview diagram of the whole system: the services, the event bus between them, and the external providers they depend on.

System design diagram showing six services connected through a Kafka event bus, with PostgreSQL per stateful service and external providers for authentication, email and media
The generated system design. Six services, a Kafka event bus, PostgreSQL per stateful service, and three external providers.

Each service also has its own diagram, produced during specification, showing its internal components rather than how it relates to the rest of the system. Both kinds ship in the repositories below.

Read the output

Section titled “Read the output”

Every artefact Delta AI produces for a real project is in these repositories:

  • The showcase — what was built and how to navigate it
  • System design — the architecture document and its overview diagram
  • chat_service — the most representative service: rich domain logic, a transactional outbox, and a fail-closed dependency on community_service

Each service repository contains the same structure:

docs/architecture.md          component boundaries, data flow, failure modes
docs/openapi_spec.yaml        the complete HTTP contract
docs/user_stories.md          testable acceptance criteria
docs/engineering_guide.md     conventions the implementation follows
docs/decisions/               architecture decision records
diagrams/                     the service diagram, .drawio and .svg
src/  tests/                  the implementation and its test suite

What the run produced

Section titled “What the run produced”
Measure Result
Services 6
Pull requests 7 (6 services + system design)
Tests written 300+ across the services
Time from first prompt to merged Under two hours

What it demonstrates

Section titled “What it demonstrates”
  • Provider research — authentication, email and media were researched and chosen, not assumed
  • Plan approval — every service’s specification was reviewed before implementation
  • Specification quality — each service ships an OpenAPI contract, testable user stories and its own diagram, not just code
  • Reviewability — the whole system arrived as seven reviewable pull requests
Section titled “Related”