FullStack Brandon

Case study

The challengeBuild a world that looks alive—and has working systems behind every move.

A little world.
A lot going on.

A 3D business. An AI decision maker.
Every choice has a consequence.

Actual FullStack Brandon 3D island and business controls
A working world · actual local app
DECIDE → DELIVER → BUILD

I didn’t start with a customer problem. I set myself a challenge: build an enjoyable world that shows how I design interfaces, connect AI, render in 3D and make a detailed system work as a whole.

01

The challenge

Make the world do more than look alive.

A courier walking to a shop is easy to show. Making that trip agree with stock, orders, money, time and progression is the interesting part. I wanted a beautiful miniature world where the details have consequences.

My decision

I made the portfolio itself a working product people can explore, rather than only describing what I can build.

Actual FullStack Brandon world and controls with a developed business
The playable world · actual local app
↓Next The solution02
02

The solution

Give the business one source of truth.

The simulation owns inventory, money, routes and legal actions. React presents the controls; Three.js renders the resulting state. When a delivery finishes, the visible handoff and the business records describe the same event.

My decision

The renderer shows what happened. The engine decides what is allowed to happen.

Actual business inspection panel showing queued orders and delivery states
Orders have a state · actual local app
↓Next The decisions03
03

The decisions

Give AI a defined job and legal choices.

The server edition sends the current business context and permitted actions to Jev through an API. A returned choice is validated before the engine applies it. Timeouts, invalid replies or an exhausted allowance use a labeled rules fallback.

My decision

AI can choose the next move. It cannot invent stock, money or a new command.

Actual decision tree showing business inputs, legal choices and a labeled rules fallback
Read → weigh → choose · rules fallback shown
↓Next The world04
04

The world

Make every system visible in the scene.

Deliveries fund vehicles, a crew and production. Routes, boarding, carrying and handoffs connect the animation to the work. Daylight and weather change the feel of the island while roads, transport and work schedules change what the business can do.

My decision

I care about the tiny details because they make the world understandable as well as enjoyable to watch.

Actual miniature simulation island under night lighting and rain
Daylight and weather belong to the world
↓Next The result05
05

The result

Explore, intervene and inspect what changed.

Follow the courier, choose a priority or introduce a disruption. Open the decision inspector and rewind recorded history to see the consequences. The public browser edition makes the world easy to try; the separate server edition contains the provider integration and persistent API workflow.

My decision

The experience needs to be pleasant to explore and clear enough to inspect. Both are part of the product.

Actual simulation replay with recorded history and its timeline control
Recorded history · inspect the outcome

Behind the build

My part in FullStack Brandon.

I designed the 3D world, the interaction model and the systems that connect them. React, Three.js, API boundaries, saved state and bounded provider requests each have a specific job. The interesting work is in their handoffs: keeping a decision, a delivery, the accounting and the visible scene consistent.

Evidence & what’s next

Current local captures show the world, business panel, decision tree and replay. The tree shown is explicitly using the rules fallback; it is not evidence of a live provider response. The night scene is an existing app capture. The public browser demo uses a rules controller and browser storage. The GitHub architecture and verification notes explain the separate Node/SQLite/AI edition.

The public demo runs a rules controller and saves to the browser, not a shared cloud world. The repository also contains a separate Node/SQLite edition with optional AI. Its deployment and provider claims are distinct from the browser demo.

Check that delivery events, stock and revenue agree; verify save/reload and replay; compare controller outcomes on matched scenarios before claiming AI improves decisions.

Have a workflow in mind?

Discuss a workflow ↗