Oramo is the property management platform I’m building for Romanian landlords. This is the case study of two features I shipped as sole designer and sole developer — and the question about data, trust, and multi-tenancy that they turned out to share.
Launched in April 2026 into a €2.75B/year rental market with near-zero existing software adoption. Property onboarding sits under three minutes. The market-intelligence engine covers 750+ Romanian neighborhood zones from day one. The in-product AI assistant answers questions about a landlord’s portfolio without learning its way to anyone else’s.
Before any code, we spent the first stretch of the project validating the wedge. 29 Romanian landlord conversations, a competitive review across five listing and management portals, and a structured survey produced one finding that shaped everything after: 86% of landlords we spoke with operated their rental portfolios with zero profitability visibility. They knew what rent came in. They did not know, at any given moment, what any given property was actually earning them.
The tool of record was Excel, often paired with WhatsApp threads with tenants. The landlords who used listing portals used them to post vacancies, not to run their business. The market they were operating inside — roughly €2.75B/year in Romanian residential rentals — had near-zero software penetration on the supply side. That was the opening.
Technical co-founder. Sole designer. Sole developer. In a three-person founding team covering real-estate expertise, financial strategy, and execution, I own product strategy, design, and the full stack (Next.js, Supabase, Vercel). Every feature described here I scoped, designed, and shipped. The AI-native workflow — Claude Code as the primary development copilot — is what makes a sole-developer product of this scope possible in 2026, and it shapes how I think about the rest of my career.
1. Build the data layer as if it were the product, because eventually it will be. Oramo ships with a market-intelligence engine that parses 750+ neighborhood-level zones across Bucharest and other Romanian cities. Today the engine aggregates asking-price data from the three dominant Romanian listing platforms — Storia, OLX, and Imobiliare — and normalizes it into per-zone benchmarks. That is what a landlord sees when they check what their flat “should” be renting for.
The design decision that matters is what happens next. Listings are asking prices — what landlords hope to get. They are not actual prices — what rentals close at. Over time, as Oramo users sign leases inside the product, the platform accumulates the first real-rental-price dataset in Romania: actual closed-lease data, per zone, with transaction-level specificity no listing site can produce. The listing scrape is explicitly designed as a bootstrap — accurate enough to ship with, structured to be replaced. The long-term surface for the landlord is the same UI; the data behind it gets better as the userbase grows.
This is not a plumbing detail. It is the product thesis. A property management tool that happens to own real-rental-price ground truth is a different kind of company than one that resells listing data. I designed the engine’s output surface — the per-zone benchmark, the trend line, the “your property vs. your zone” comparison — to work whichever dataset is underneath it, so that the transition, when it happens, is invisible to the user and quiet in the codebase.
2. An AI assistant inside a multi-tenant product is a permissions problem wearing a conversation costume. Oramo’s in-product assistant is a natural-language chat. A landlord can ask it things like “which of my properties is underperforming its zone?” or “who’s late on rent this month?” and the assistant answers from context it legitimately has access to.
The design decision — and the part that took real thought — was what the assistant must never do. A landlord should not be able to ask the assistant, and should not be able to phrase a question in a way that lets the assistant quietly reveal, anything about another landlord’s portfolio, a neighboring property’s specific rent, or any global detail of the product it wasn’t meant to expose. Not because the data isn’t in the system — of course it is; the engine is sitting right next to the assistant — but because the assistant’s epistemic boundary has to match the user’s permission boundary exactly, on every turn, for every phrasing.
The working principle I arrived at: the assistant’s context is the user’s own data plus anonymized zone-level aggregates. Anything more specific than a zone is outside the boundary, regardless of how the question is phrased. That sentence is one line of prose; implementing it correctly — context assembly, retrieval scope, refusal behavior, and the confidence with which the assistant refuses — is most of the work. It is also, structurally, the same work that any AI assistant inside a B2B product will need to do, in any industry where data isolation matters.
3. Choose conversation where the alternative is a form nobody wants to fill in. The reason the assistant is a chat and not a dashboard panel is worth naming. Small-portfolio landlords — the people Oramo is built for — are not power users of software. They are busy people managing a few flats alongside a real job. Dashboards reward people who want to look at their data. Conversation rewards people who have a question and want the answer. When we ran the wedge research, nobody we spoke to described their landlord problems as “I wish I had a dashboard.” They described them as questions — “is this one still worth it?”, “am I leaving money on the table?”, “did Gigi pay?” The interface followed the question.
Oramo launched publicly on April 7, 2026. Property onboarding runs under three minutes end-to-end; the automated notification architecture (rent overdue, lease expiry, payment confirmation, utility anomalies) replaces the manual tracking responsible for the single largest source of landlord frustration surfaced in research — 45% of it. Post-launch bug reports inbound through LinkedIn were resolved within 48 hours of public launch via direct customer contact. The market-intelligence engine and the assistant shipped in the first release and are in use today.
The harder thing to measure, and the thing I pay most attention to, is whether the assistant is answering honestly inside its boundary. That is not a feature you ship once; it is a posture you maintain in the data layer, the retrieval logic, and the prompt — and you re-verify every time any of those three change. That discipline is, in my view, the actual senior design work on any AI-in-product surface in 2026.
Two things carry forward into whatever I work on next. First: the right shape for a senior designer’s role on an AI-native product is somewhere between product design and information architecture — the most consequential decisions are about what the system should and should not be able to know, and those decisions live in the data layer, not the interface. The UI is downstream.
Second: AI-native development is real. One person designed, built, and shipped this product in the time it would have taken a small team two years ago. That is not a cost-saving story; it is a story about what a senior designer who can hold the full stack in mind can now produce. It is also, not coincidentally, the same shape of work I’d want to bring to a larger team — someone who designs the surface, understands the system underneath, and can make the tradeoff calls in the room rather than over a handoff.