Rethinking property management and communication with AI

System architecture: Open link Web app link: rentenai.com

The problem

Property owners and managers spend hours on repetitive work: answering the same tenant questions, coordinating maintenance, and keeping track of everything across emails, messages, and spreadsheets. Most property management systems digitise this work but still leave people doing it by hand.

When I mapped the working week of a property manager in Porto who runs 15 apartments housing around 56 students a semester, the pattern was clear. She wasn't short of software; she was short of hours. Twenty-two recurring workflows, and almost every one of them bottlenecked on the same thing: her, personally, sending and chasing messages.

The line that stayed with me was about capacity, not time: "Too many students arriving and only me and José." She couldn't take on more properties because she was already the constraint in the ones she had.

My role

I founded RentenAI and own the product end to end: discovery, product strategy, UX and UI design, and building the MVP. As a designer with a Computer Science background, I used Claude Code to develop the product myself, which let me test ideas with real users much sooner than a traditional design-then-handoff process.

Process & key decisions

1. Starting from real workflows

Rather than surveying the market, I sat with one operator and documented how her week actually ran: every task, every handoff, every point where something waited on someone else. Twenty-two workflows came out of it.

Five patterns repeated across nearly all of them: chasing people for replies, retyping the same data between WhatsApp, Excel, and tax filings, coordinating between tenants and cleaners where one late reply cascades, policing deadlines for over a hundred people, and a hard ceiling on growth.

The insight that shaped everything: almost none of this work needed her judgement. It needed her to type. That gap between decisions and transcription is what the product is built to close.

2. Designing where the AI acts, and where it asks

The defining design decision was drawing the line between autonomy and approval.

Routine answers wifi passwords, bin days, cleaning schedules the agent handles alone. Get one wrong, and the cost is a mildly awkward message. But anything touching money, a contract, or a tenant relationship is drafted and sent to the operator for one-tap approval. The agent decides; it never executes.

This wasn't a technical constraint; it was a trust decision. Operators hand over their tenant relationships slowly or not at all. A system that quietly sent a rent reminder to the wrong person would end the relationship on day one. Making the agent visibly ask permission is what makes the autonomy elsewhere acceptable.

3. Meeting people where they already are

Every competing product asks tenants to download an app and create an account. In Portugal, the landlord–tenant relationship already lives entirely in WhatsApp/Telegram.

So the agent works inside WhatsApp/Telegram. Tenants install nothing, sign up for nothing, and often don't need to know it's there assistant carries the operator's own name. The design constraint became: if it requires the tenant to change behaviour, it's the wrong solution.

4. Building the MVP with Claude Code

Instead of stopping at prototypes, I built and tested a working MVP using Claude Code. This shortened the loop between a design idea and real feedback, and it let me design around how the AI actually behaves, not how I assumed it would.

That mattered more than expected. Designing a conversational agent in Figma tells you what a message looks like. It doesn't tell you that the agent will answer a question three seconds after it's asked, before the person has finished their thought, which reads as robotic rather than helpful. I only found that by building it and watching real conversations.

5. Piloting with a real customer

RentenAI is now in beta with the property owner in Porto whose workflows the product was designed around. The pilot shows me where the product saves time, where users hesitate, and which features to prioritise next.

Outcome

• Working MVP designed, built, and tested end to end

• In beta with a live pilot customer managing dozens of properties

• Full system architecture designed: agent reasoning, approval workflows, and a multi-property data model

• Aims to reduce property owner operational and communication time by 70- 80%.

What I'm learning

Designing for an AI agent is mostly about designing restraint. The hard questions weren't what the agent could do; they were what it should decline to do, when it should stay silent, and how long it should wait before answering. Building it myself with Claude Code collapsed the distance between a design decision and seeing its consequence in a real conversation, which changed how I work: I now design far less in Figma before testing something live.

The other lesson was about adoption. The strongest product decision I made wasn't a feature; it was removing every step that asked a tenant to do something new.