The week we became visible

This week, for the first time, we said out loud that RENAVID exists. Launch is probably the wrong word. The site has been up for a while, but this was the week we shared the first post on Instagram and put it plainly: this is what we are working on, and you are welcome to look.

By Sunday morning, a little after eight, 274 people had found their way to the site. It is a number that says very little, and yet it carries something for me. It means we are now visible to the world, and that at least a few hundred people who wonder what AI might do for buildings and the people who run them have passed through. A small milestone, however it looks from outside. The same day, the first letter goes out, to the few who have signed up for The Letter so far, and I notice I am thinking about it more than almost anything else. Not because the letter is long or difficult, but because it is the first time we say something at a fixed hour to people who have chosen to listen.

What we write comes out of what we build

It may not look that way from the outside, but most of our time at RENAVID does not go into writing. It goes into the systems. The daily work is running our properties, developing the software we have built for ourselves, simplifying how things flow, and trying whatever is new in AI that might make a difference inside a building. To do that sensibly we have to stay current, and it is out of that work that the pieces in The Journal come. We do not write about what we have read. We write about what we have done, and what happened.

We locked our operations system in September, in its third version, after rebuilding it twice. We have written about that before. Since then, the time has gone into planning the next one.

After weeks of sketching we now know what we want it to be: a renewed version with the third system as its backbone, with entirely new functions, and above all with a different purpose. The system we have today answers the question of what needs doing in the buildings and whether it got done. The next one is meant to be the place where the day begins. Right now, everything that comes in, email, text messages, fault reports, our own notes, sits in four channels with no shared queue, and anything that is neither an inspection nor a work order, calling someone, ordering something, reading a contract, making a decision, has no home at all. So what we are building is a layer on top of what already exists, something like a workspace for the property company: an inbox where everything about the buildings lands in one place and is sorted into what it is, tasks with owners and dates, documents with expiry dates, finances and energy use at a glance per building, and, in time, a portal for tenants. Each property becomes its own home screen, and everything is reached from there. Agents will be able to work inside it, but as users with roles and a visible trail, never through a back door.

That is what we are setting out to build. The first step was to get the existing system out of the tool it was built in.

Moving to code

The third system was built in Lovable, a tool where you describe what you want and receive an interface and a database in return, without writing the code yourself. It was the right way to get from an idea to a system in daily use, and I would choose it again for that journey. The next version we are building in code, with Claude Code writing and us directing, and for that everything had to come out.

We connected Lovable to a code repository, a place where all the code lives as files with its full history, and exported the system there. We took the keys out of the repository so they never travel with the code. We created a copy of the database, empty of real buildings, where everything can be tried before it touches the live system. And before anything was built, we had Claude Code read through all of it with a single instruction: understand the system completely, write it down, build nothing. The reason was simple. A system you have built by describing it is a system you have never read. We wanted to know what we actually had before we put anything on top of it.

The report came back after a couple of hours, and it held more than I had expected.

The drawings did not match the house

The first thing was that the database’s history was incomplete. Lovable writes every change to the database as a file, and those files together are supposed to recreate the system from nothing. But two tables, all three functions and a number of constraints existed only in the live database, not in the files. The tool had built them and moved on. The house stood there; the drawings were missing pages. It could be repaired, and the repair was proven by building a copy from nothing and seeing that it held.

The second thing was more serious, and to explain it I need to say something about how a system like this is put together.

It has two layers. On top, the interface: what you see and click on. Underneath, the database, where everything is actually stored: every building, every inspection, every piece of evidence as rows in tables. We had been careful with the database. Before Lovable was allowed to build a single screen, we wrote its structure by hand, in SQL, the language databases speak: which tables exist, what may go in them, how they relate. You do this because the structure is the only thing that lasts. Screens get replaced; tables stay. The most important rule we put down there: the function that closes a work order refuses unless evidence exists. We tested it by trying to cheat, and it said no.

The second rule, that evidence can never be edited or deleted, we solved in the upper layer. We never built the buttons. It was a deliberate decision, and it is written in the build log. Since the interface was the only way in, the rule held in practice, and we wrote that the ledger could not be changed.

So we asked Claude Code to run a security test, the kind of test we should have run ourselves in September. Not through the interface, but as an ordinary signed-in user working directly against the database, with the app out of the way entirely, trying to do what we had described as impossible. Edit a piece of evidence. Delete one. Change the requirement on an order after the fact. Reopen an order that was done. Mark an order done without going through the function with the gate.

All of it worked. There was no door into the room, so nobody had ever walked in. But the wall was made of paper.

The test also turned up three things none of us knew. The function that closes an order could be called without being signed in, using the public key every web app carries openly in its code; the database allows anyone to run functions by default, and nobody had removed that right. Every signed-in user had the right to empty an entire table with a single command. And the timestamp for when a piece of evidence was captured, the one we had built our whole handling of late evidence around, could be set to any time at all.

Nobody had done any of this. The app was the only way we had ever used the system, and the app had no such paths. But there is a difference between a system where nobody has found the way and a system where the way does not exist, and we had described the first in words that only fit the second.

Ten changes, one at a time

Claude Code wrote ten changes to the database, as files, and ran each one against the copy first. Each change comes with tests that show whether the hole it is meant to close is open or shut, 69 in all, and they have to pass after every single change, not just at the end. When everything held on the copy, I pasted the changes into the live system myself, one at a time, with a check before and after that was compared against the copy. Claude Code has no login to the live system. It reads, writes, tests and proposes. I run. We decided that before it had found anything, and after what it found, I am glad we did.

The last change was the only one that could go properly wrong. It replaced the rule “signed in means allowed” with roles, and roles mean that for every row the database asks who is looking. If that question is asked badly, nothing disappears, but nobody sees anything either: every screen goes blank, for everyone, me included. So the change was written to refuse to run unless someone with the owner role existed, and the undo sat ready beside it. It went in. I signed out, signed in, and the buildings were still there.

What the changes did, in short: evidence can no longer be edited or deleted, by anyone, agents included; the requirement on an order is locked when the order is created; a finished order cannot be reopened, and finished can only be reached through the function with the gate; the timestamp cannot be moved, and beside it there is now a second one the database sets itself, so that late evidence shows as late; signed-in-means-allowed has been replaced by roles; and every change to every table is logged from now on, with who and when.

For anyone who wants every step and every test, a guide will follow later this autumn. This is the short version.

Under way

We had planned for the first week to be about building something new. Instead it was spent reading what we already had, properly, for the first time, and I think that turned out to be the right order. The foundation now does what we said it did, not because the buttons are missing but because the database refuses, and that is the ground the next system stands on.

And the next system is the most ambitious thing we have attempted: a working place for a property company, where everything about a building arrives, is sorted, is acted on and is remembered, and where people and agents work from the same queue. We have sketched it for weeks. This week we started building it. The site is open, the first letter is on its way, and the fourth version is finally under way.