Flat-Renovation-OS

The problem

My home has an awkward layout.

The main living space and bathroom work well, but the rear of the property was originally one larger room and now needs to accommodate both a kitchen and bedroom. I wasn't happy with the existing partition, and changing it affects far more than simply moving a wall.

A new layout has consequences for plumbing, drainage, electrical points, appliances, furniture and eventually a full rewire.

Before removing anything, I wanted to answer questions such as:

• Where can the new partition realistically sit?
• Will a bed, wardrobes and kitchen units actually fit?
• Where could sinks and appliances move?
• How would new water and waste routes work?
• Where should electrical points eventually go?
• How can I communicate all of this clearly to contractors?
• Once work starts, how can I compare what was quoted with what is actually delivered?

A rough floor plan wasn't enough.

I wanted a sufficiently accurate digital representation of the property that I could use as the foundation for planning the entire renovation.

That became Flat-Renovation-OS.

Starting with almost no relevant experience

I hadn't done measured surveying, CAD, SVG drawing, coordinate geometry or 3D modelling before starting this project.

My first attempt was considerably simpler.

I hoped modern image-generation models might be able to take a hand-drawn floor plan, detailed measurements and written instructions and turn them into useful renovation visuals.

They couldn't.

They could create images that had the elements, but they couldn't preserve real dimensions and spatial relationships. Clearly this would not suffice.

That pushed the project towards code.

Before thinking seriously about interior designs, I needed to establish the underlying geometry.

Turning the property into data

I divided the property into individual areas and created a node system representing identifiable physical points: wall corners, openings, doorways, windows and other structural features.

Those nodes gave both me and the AI agents a shared language.

Instead of saying something like "the wall beside the bathroom door", I could refer to known points and record measurements between them.

That allowed measurements to overlap and cross-check each other rather than relying on a simple list of wall lengths.

The process gradually became:

real-world measurements → structured evidence → room geometry → reconciled 2D model → generated 3D construction shell

Getting the 2D model right was by far the hardest part.

Old buildings aren't perfect geometric objects. Walls aren't necessarily parallel, plaster varies in thickness and measurements taken at different positions can differ by several centimetres.

There were also plenty of smaller complications: door casings merging into walls, awkward reveals, cupboards, partitions and areas where photographs were easier to understand than written descriptions.

To help with that, the repository grew beyond code. It contains photographs, measurement records, node maps, walkthrough evidence, documentation and decision records so that an AI agent can go back and investigate why a particular part of the model exists.

Once the 2D geometry was finally stable, creating the first 3D representation was comparatively straightforward.

Keeping the human in the loop

AI made this project possible for me, but it also produced one of its biggest lessons.

During the surveying stage, I initially trusted the process AI was proposing because I had no surveying background of my own.

That eventually resulted in an enormous measurement process — at one stage I had roughly 20 pages of survey sheets telling me what measurements to collect.

While actually standing inside the property trying to follow them, it became obvious that the process had become unnecessarily complicated.

That was an important turning point.

AI was extremely effective once the problem was brought back onto the computer: interpreting measurements, manipulating structured geometry, writing tooling and helping investigate inconsistencies.

But it didn't automatically know what was sensible for a person to do in the real world.

I had to challenge the process rather than simply follow it.

For the final major room survey I simplified the approach considerably, collected the measurements that actually mattered and achieved at least as useful a result.

Why the model stays data-driven

It would have been much easier to manually adjust the 3D model until everything looked right.

That would also undermine the point of building it.

The permanent geometry needs to come from underlying data so that the 2D and 3D representations don't gradually become two different versions of the same property.

Where measurements conflict or modelling decisions have to be made, those decisions are documented rather than hidden.

That gives the project a traceable source of truth.

It also means that if an error appears later, an AI agent can work backwards through the repository and investigate where that geometry originated instead of simply moving something until the screen looks better.

The aim isn't mathematical perfection.

It is a model accurate enough to support real renovation decisions, with known uncertainty recorded rather than disguised.

The point where it became real

One of the most satisfying stages came after building the 3D shell.

I added an interactive measurement tool that lets me select two points within the digital property and calculate the distance between them.

I could then physically measure the same locations in the real property.

I deliberately used free wall-to-wall checks rather than only choosing measurements that had originally been used to construct the model.

Across a session of 19 validation measurements:

That was the point where the project stopped merely looking like the property and started feeling like a useful digital representation of it.

It also gave me enough confidence to accept occasional local node discrepancies where the overall physical geometry could be independently validated.

What exists now

The project currently has a reconciled 2D property model and an interactive 3D construction shell built from the underlying geometry.

The current application uses Three.js for the 3D environment, with a small Vite-based application around it. The shell is generated and validated programmatically rather than being manually modelled.

The current model includes the major permanent structure, doors, windows, fixed features and existing removable partitions, along with tooling for inspecting and validating the geometry.

There are still some final structural details to complete before I consider the first 3D shell finished.

Development is temporarily paused while I build this portfolio site, after which I'll return to the renovation project.

What comes next

Once the structural shell is locked down, the interesting planning work can start.

The intention is to add new elements as separate editable layers rather than modifying the underlying property model.

The next stages are likely to include:

• alternative partition positions;
• beds, wardrobes and other furniture;
• kitchen units and appliances;
• different room layouts;
• plumbing and waste routes;
• heating and electrical planning;
• design visualisations based on viable layouts;
• material quantities and renovation costs.

Eventually, I want to be able to move from “this design looks good” to much more practical questions:

Will it fit? How would it be built? What services need to move? What materials are required? And roughly what should it cost?

What I learned

This project started as a way to plan a renovation and ended up teaching me a lot about working with AI on problems where the answer has to survive contact with the real world.

The biggest lessons have been:

• Get the underlying data right first. A polished visual is of little value if its geometry is wrong.
• Give AI stable reference points. The node system gave both me and the agents a common language for discussing physical space.
• Preserve a source of truth. Documentation, structured data and decision records make later investigation much easier.
• Validate outputs independently. The 3D model became much more trustworthy once I could compare arbitrary digital measurements with the real property.
• Challenge AI-generated processes. A technically thorough workflow isn't automatically a practical one.
• Use human context where AI doesn't have it. Standing in the room sometimes made an unnecessary measurement or an incorrect interpretation immediately obvious.

I'm still not a surveyor, architect or 3D-modelling specialist.

What this project has given me is experience taking an unfamiliar, messy real-world problem, breaking it into something AI could work with, learning enough along the way to challenge its decisions, and then validating the result against reality.

That is the part of Flat-Renovation-OS that I find most useful beyond the renovation itself.