Greenfield build of a 3D viewer

The system

Questions asked

25

Sections

11

Runtimes

2

Model writes

the viewer

The problem

A viewer for 3D scans. Someone uploads a few hundred megabytes of mesh and expects to rotate it in the browser a second later, so something between the upload and the first frame has to parse a binary format, decimate the geometry into levels of detail, tile it, cache it and stream it. Both single-runtime answers are bad: decode in Node and you spend the project fighting a garbage collector that was never meant to hold a 400 MB vertex buffer; write the interface in Rust and you have given up React to avoid a language boundary you were always going to cross. The right answer is both, and the reason teams do not take it is that both costs a week of monorepo, two toolchains, a contract between them and a pipeline that can build each without knowing about the other — before a line of product code exists.

What ran

1. Answer twenty-five questions

   Eleven sections: project, architecture, UI, data, auth, state, testing, caching, CI, deploy, config. Every one of them is a target decision — a thing no parser could derive, because the code does not exist yet. You are choosing between block sets that have already been written and tested, not describing a wish.

2. Compose the monorepo

   The answers select blocks and the blocks are assembled. Nothing here is generated prose: run the same answers twice and you get the same tree, file for file.

3. Decide the caching before the code

   Next.js’ built-in cache is right on one instance. More than one replica and the replicas need to share, so the run wires a Redis cache handler instead. It is a question, up front, because retrofitting it after the viewer works is a rewrite of how every page is served.

4. Read what was just written

   A real structural pass over the scaffold on disk — not a memory of what it intended to write — and the planning context is built from that.

5. Plan the application, at file level

   The upload endpoint, the decode pipeline, the level-of-detail generation, the tile store, the streaming route, the canvas component, the camera controls. Written down before anything is created, and yours to read.

6. Build it one task at a time

   cargo build on the Rust side, tsc on the TypeScript side, between every task. Each passing task is its own commit. A failing task keeps the run on that task rather than stacking a second broken change on the first.

What it did

Where it ended

A security scan over dependencies and secrets, a second structural pass over the generated application, a check against the conventions the playbook holds for both runtimes, and a build — a real one, not a claim that it should compile. What you review is a branch with one commit per verified task and the file-level plan you approved before any of them ran.

What happens next

• Point the decoder at your own formats. It is the one part of this that is genuinely yours, and it is the part the model was spent on.
• Turn on the Redis cache handler when the second replica goes up. The block is already selected; the switch is configuration.
• Longer read: Building a 3D viewer from an empty folder walks the same run in detail.

A viewer is a good test of this shape because the hard part is small and specific. The decoder is difficult and it is yours. The monorepo, the contract, the container, the pipeline and the documents are none of those things — they are the same here as they would be for a mapping service or an audio editor, and paying a model to reinvent them each time is how a build gets expensive and inconsistent at once.