0
Kai Detmers
← Project index
Enterprise workflow prototype · anonymizedArchitecture case

Orbit— make demand legible before delivery starts.

A prototype for turning loosely expressed internal demand into a governed request lifecycle. Requestors get a simple conversational/front-door experience; operations gets a queue; governance gets status, provenance and handover structure.

Stack

AppNext.js 16 · React 19 · TypeScript
Persistencerepository abstraction · Upstash Redis path
ValidationZod · explicit lifecycle contracts
Visual layerReact Three Fiber · Drei · Framer Motion
QualityVitest · dependency-cruiser
DeliveryVercel prototype · gated access

How it evolved

Reconstructed from a dense prototype commit history. Client/employer-specific branding and content are intentionally omitted; the case focuses on product and architecture decisions.

01
Build the request flow before the operating model is fully settled.

The early prototype focused heavily on interaction and repeatedly redesigned the front door. This was useful: the ambiguous part of demand intake is not the database schema, it is getting a person to express enough context without feeling like they are filing a ticket.

02
Use an expressive AI object, then keep tuning it down.

Multiple commits iterate on the central orb — shape, ring angle, brightness, growth and overall cleanliness. The pattern suggests an intentional attempt to make AI feel present without turning the screen into a chatbot mascot.

03
Add the intake queue.

Once requests existed, the product had to become two-sided. The operations surface introduces triage and lifecycle state, separating the requestor's simple experience from the team's denser working view.

04
Replace local prototype state with deployable persistence.

A repository abstraction and Upstash-backed path moved the app beyond a single-machine demo and forced clearer boundaries between domain state and presentation.

05
Anonymize the product surface.

Later commits remove company-specific naming and branding. That is not just portfolio hygiene: it demonstrates that domain logic and interaction patterns can survive identity/branding replacement.

UI rationale

Requestor side stays emotionally lightThe front door uses a single focal AI object and progressive questions. A dense enterprise form would encode the organisation's internal structure into the user's first interaction.
Operations side gets densityOnce a request enters triage, queues, status, ownership and governance matter more than atmosphere. The two modes deliberately do not use the same information density.
The orb is status, not decorationIts value is signalling listening/processing/progression without adding another panel. Iterating brightness, rings and motion was about keeping presence while avoiding a “magic AI” spectacle.
Lifecycle should be visibleRequestors need to know what happens after submit; operators need to know what is blocked. State transitions are product language, not backend-only enums.

Architecture boundary

Intake→Direct request, conversational capture or scheduled channel produces a normalized demand record.
Lifecycle→Typed state transitions make ownership, audit and handover explicit.
Repository→Persistence is abstracted from UI; prototype paths can move from local state to Redis-backed deployment.
Ops→Queue and governance surfaces consume the same domain state at higher information density.

Honest boundary

Orbit is a strong workflow/interaction prototype, not a finished enterprise platform. Identity, access control, scheduling, handover integrations and some persistence paths were prototype-grade. The useful portfolio signal is the operating-model thinking and separation of requestor / operations / governance concerns.

Related