── case 07 / house-editor ──

House Editor

A browser-based 3D tool for sketching rooms, placing furniture, and exploring a layout in real time.

At a glance

Problem
I wanted to see how much of a working 3D tool one extended Claude Code session could produce, in a category I had no background in.
My role
I set up the repo and its reference projects, then did the acceptance testing and the cut list.
Result
A working browser MVP where you add rooms, drop in furniture and orbit the layout in 3D, with everything auto-saved and no account needed.
live demo · house-editor Open full screen ↗

At a glance

Problem
I wanted to see how much of a working 3D tool one extended Claude Code session could produce, in a category I had no background in.
My role
I set up the repo and its reference projects, then did the acceptance testing and the cut list.
Result
A working browser MVP where you add rooms, drop in furniture and orbit the layout in 3D, with everything auto-saved and no account needed.
Under the hood — for the technical folks

I built this as a Vite + React + TypeScript app in Claude Code, using React Three Fiber on top of three.js. The layout is three columns: a sidebar with add-room and add-furniture buttons plus lists of what’s in the scene, a 3D canvas in the middle, and a property panel on the right that edits whatever’s selected.

The data model is two flat Zustand stores. A persistent store wraps persist(immer(...)) middleware and holds the House object: a flat list of rooms, a flat list of furniture, all levels in one place. Walls and floors are not stored — they’re derived from each room’s rectangle at render time, so moving a room is a single update to one number rather than a cascade through a scene graph. A separate transient store holds UI state (selection, hover, active level) so reloads never restore stale selections.

Two reference projects were cloned into a local reference/ folder as architectural inspiration only, with nothing imported or bundled: pascalorg/editor (a professional Next.js/WebGPU 3D building tool) and neu-vi/houseCrafter (an ICCV 2025 research diffusion model that turns 2D floorplans into 3D scenes).

Those references did the work a single prompt couldn’t. They put a real flat data model on the table before any code was written, which is why the first working version came back with geometry derived from rooms rather than a brittle scene graph.

Technical highlights:

  • Declarative 3D scene with React Three Fiber — rooms, furniture, lights, shadows, orbit/pan/zoom camera, a drei <Html> label above each room
  • Two flat Zustand stores — persistent useHouseStore via persist(immer(...)), transient useUiStore for selection/hover/level
  • Discriminated-union types for Room and Furniture so new kinds can be added with full type safety
  • Derived geometry: walls and floors computed from room rectangles at render time, keeping the data model minimal
  • Auto-save to localStorage['house-editor:v1'] on every change — no explicit save button
  • A seed house that makes the tool fun to explore on first open, with a one-click reset
  • ~1,150 lines of TypeScript total. Zero runtime dependencies on a backend, no login, no analytics — a static bundle that runs entirely in the browser.

Known MVP limitations (explicit, not bugs): rooms can overlap with no collision detection, no drag-to-move 3D gizmos, no undo/redo, only single-level editing in the UI (data model supports multiple), no keyboard shortcuts, no JSON export UI.


What I wanted

I wanted to see how much of a working 3D tool I could get out of a single extended Claude Code session. The hypothesis: if I set up a repo with the right context, could I describe what I wanted in plain English and end up with something real — not a demo, not a toy? A house editor was the test case because it’s a category I had zero background in, so nothing about it could lean on what I already knew.

How I got it

I set up the repo and dropped two open-source projects into a reference folder — a professional 3D building editor and a research paper that turns floorplans into 3D scenes — not to copy any code, but so the session had concrete examples of the kinds of patterns I was vaguely gesturing at. Then I described what I wanted and built it out from there. What came back was a working React scene with rooms I could add, furniture I could drop in, colors I could change, and a whole flat data model I only later understood was a deliberate choice. My work on this one was the acceptance testing and the cut list — clicking through every control and deciding what matched what I had in my head and what had to go.

What it does

Add rooms from a menu — bedroom, bathroom, kitchen, living room, hallway, office, garage, pantry. Drop in furniture — beds, sofas, tables, a TV, a fridge, desks, chairs, a kitchen island, a washer and dryer — as simple boxes. Click anything to select it, then edit the size, position, color, or name in a panel on the right. Orbit the camera to see the whole layout. Everything auto-saves to your browser, so closing the tab doesn’t lose anything. It’s still early — rooms can overlap, furniture can drift outside walls, there’s no undo. The idea was to get a working MVP out of one session, not to ship a finished product.

Why it matters to me

This was the one I took on just for fun, as an experiment in how far one session could go from a standing start. I didn’t need a house editor — I wanted to find out what happens when you take on a category you know nothing about and build in it anyway. You get something real. That’s the whole answer, and it’s the answer that’s been shaping how I think about every project since.

What I learned

The part I didn’t expect was how much the setup mattered. Before writing a single prompt, I dropped those two reference projects into the repo so Claude had concrete patterns to study — a professional 3D tool and a research project on floorplan-to-3D generation. Those references were the whole difference between “make me a 3D editor” producing a cartoon and producing something I could actually use. The lesson I took away: in a prompt-first workflow, the most important thing you do is give the model enough context to make the right choices on its own. The prompt is only as good as the inputs standing next to it.

What I learned
This project made me realize how much a good tool depends on the data model. Keeping rooms and furniture as flat lists made the editor much easier to extend and reason about.