FullStack Brandon
Case studyThe 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.

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.
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.
I made the portfolio itself a working product people can explore, rather than only describing what I can build.

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.
The renderer shows what happened. The engine decides what is allowed to happen.

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.
AI can choose the next move. It cannot invent stock, money or a new command.

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.
I care about the tiny details because they make the world understandable as well as enjoyable to watch.

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.
The experience needs to be pleasant to explore and clear enough to inspect. Both are part of the product.

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.