Tolobi: a rental platform where the AI decides who sees a home
One platform connecting landlords, tenants, guests and roommates, where AI writes the listing, suggests the price, and surfaces properties to the people most likely to rent them. The most consequential engineering is the constraints around all three, because all three are regulated decisions in housing.
- 3 AI touchpoints, each regulated
- 5 user types from one permission model
- 0 personal email addresses exchanged
- 1 open catalogue, recommendation as ordering
What the platform does
Renting is full of friction, and most of it sits in three places. People cannot communicate cleanly. Landlords guess at a price. Writing a decent listing is slow, manual work that most owners do badly.
A landlord adds a property and the platform generates the listing from what they entered, so a good advertisement is a review rather than a writing task.
It suggests a price grounded in the local market for that specific area, so the owner starts from an informed number rather than a guess.
It surfaces the property to tenants whose stated requirements it actually meets.
And it keeps everyone talking in one place, with real-time chat and a correspondence layer that lets two strangers exchange messages without exchanging personal email addresses.
Underneath, a permission model serves five very different kinds of user from one system: landlords, tenants, guests who have not registered, roommates looking for each other, and administrators.
- Client
- Tolobi, a rental and property management platform
- Sector
- Real estate and property technology
- Product
- Multi-role rental marketplace with AI listing generation, pricing and recommendation
- Our scope
- Platform architecture, permission model, three AI touchpoints and their constraints, communication layer, cloud infrastructure
The one fact that shaped everything
The AI does the three things housing law has always watched.
Who is shown a home. What the advertisement says. What it costs. Those are not three product features that happen to use a model. They are the three points at which housing discrimination has historically happened, which is why all three are regulated almost everywhere a rental platform can operate.
When a landlord writes their own listing, the landlord is responsible for what it says. When the platform generates it, the statement is the platform's. When a landlord chooses who to show a property to, that is their decision. When a recommender does it, the decision belongs to whoever built the recommender.
There is a harder version of the same point. A model does not need to be given a protected characteristic in order to act on one. Postcode, browsing behaviour, budget, language setting and time of day all carry demographic signal, and a recommender trained on who enquired about what will faithfully reproduce the pattern of who has lived where. If a neighbourhood was segregated, that is the pattern it learns.
Intent is not a defence in housing, and it is not available to the platform either. So fairness on this platform is a design constraint rather than a policy page.
The four decisions that mattered
If you read nothing else on this page, read this.
Every listing stays reachable by anyone, so ranking is a convenience laid over search rather than a decision about which homes exist for you.
A description of an imagined occupant is ordinary rental language and unlawful in an advertisement.
An area-based number needs to be explainable, because an area is not only a geography.
Hiding a control is not a permission.
Recommendation orders, it does not gate
A recommender in most products is a convenience. If a music service is bad at guessing what you want, you scroll. In housing it is different, because the thing being recommended is where somebody lives, and a recommender that systematically shows different homes to different kinds of people is doing something the law has a name for.
The mechanism does not require anybody to intend it. Train a model on which tenants enquired about which properties and it learns the historical pattern of who lived where. Remove every protected field from the inputs and the signal persists, because postcode, budget, search behaviour and language setting all carry it.
That leaves a genuinely hard product question. Recommendation is valuable. The answer cannot be to abandon it.
What we did
Recommendation is built on what the tenant asked for. Bedrooms, budget, area, dates, pets, furnishing, accessibility. Things a person chose to tell the platform precisely because they want them acted on. Behaviour refines within those stated requirements rather than substituting for them.
Search is never hidden behind recommendation. A tenant can always reach every listing matching their filters. Ranking orders what is available. It does not decide what is available.
Every listing is reachable by anyone. A property is not withheld from a person because a model believes it is not for them. Ranking an open catalogue is a service to the tenant; deciding which homes exist for them is something else entirely.
The reason is recorded. Which stated requirements produced a recommendation is kept, so a question about why somebody was or was not shown a home has an answer.
The recommender cannot steer, because it has nothing to steer. It orders a catalogue that stays open, rather than deciding what a person is allowed to find.
A fairness question is answerable. Recorded reasons mean the platform can explain a recommendation instead of pointing at a model.
Tenants still get the benefit. Relevant properties first is the friction the platform set out to remove, and constraining the mechanism does not remove the value.
The constraint holds as the model improves, because it is a property of where recommendation sits in the product rather than of how the model was trained.
The generator writes about the property
Generated listing copy goes wrong in two directions, and they need different answers.
It describes a home that is not there. A model asked to write appealing copy will add appealing detail. An overstated description is a misrepresentation, and the tenant discovers it standing in the flat.
It describes a tenant. "Perfect for young professionals. Ideal for a small family. Not suitable for children." Every one of those is ordinary estate agent language, several are unlawful in a housing advertisement, and a generator trained on rental listings will produce them fluently, at scale, in the platform's voice.
The second is the sharper problem for exactly that reason. The training data for property copy is property copy, and almost every rental listing ever written describes an imagined occupant.
What we did
It writes from facts rather than about them. Copy is generated from the attributes the landlord entered. A feature that was not entered does not appear, however much it would improve the paragraph.
It describes the property only. The subject of a listing is a building. Who might suit it is not the platform's to write, and a generator that never characterises a tenant cannot exclude one.
The landlord confirms before it goes live. Generated copy is a draft the owner reviews and publishes. The person who knows the property signs off on the description of it.
A listing describes the flat somebody will actually see, which removes the wasted viewing that damages trust in a rental platform faster than anything else.
The platform does not author an unlawful advertisement. Which is the version of this risk that is uniquely the platform's, because generating the words is what made it so.
Quality is consistent without being invented. The original problem, thin and inconsistent listings, is solved by structure rather than by embellishment.
Landlords keep the last word. Review before publish is a fairness control and a quality one at the same time.
Price is a suggestion with a basis
Landlords mis-price constantly. Too high and the property sits empty. Too low and they lose money for the length of a tenancy. Most have no reliable local data and are guessing from what a neighbour said.
An area-based suggestion fixes that, and introduces the third version of the same problem. An area is not only a geography. In most cities it correlates with who lives there, which means an automated pricing model that learns area by area is learning something adjacent to demographics whether anybody wanted it to or not.
There is also a commercial trap. A pricing engine that suggests confidently and is wrong costs a landlord real money over a twelve month tenancy, and they will not use it twice.
What we did
The suggestion is comparable-driven and explainable. It is grounded in what similar properties in that market actually achieve, and the landlord can see the basis rather than receiving a number from nowhere.
The landlord decides. The platform suggests and never sets. The owner adjusts, and the adjustment is theirs.
It prices the property, not the applicant. One suggested price per property, presented to everyone identically. Price is not personalised to whoever is looking.
The basis is recorded, so a suggestion can be examined later rather than being an output nobody can reconstruct.
Landlords start from an informed number, which reduces both vacancy and the quiet cost of under-pricing.
A suggestion can be argued with, because it comes with its reasoning. A landlord who can see why is a landlord who will use it again.
Everybody is quoted the same price for the same property. Personalised pricing in housing is a place this platform deliberately does not go.
The model can improve without the guarantee changing, because the constraint is structural rather than a property of a particular version.
Permissions are data
Five kinds of user want different things from the same objects: a landlord managing properties, a tenant searching them, a guest browsing without an account, a roommate looking for a person rather than a place, and an administrator over all of it.
The obvious build checks the role in the code. If landlord, show this. If admin, show that. Written once per screen, and again on every screen added afterwards. A sixth role means revisiting every branch. A new module means writing them all again, and the one that gets missed is not visible until somebody sees something they should not.
What we did
Roles hold permissions, users hold roles, and both relationships are many to many. The interface is assembled from what a person actually holds rather than from a branch on what they are called.
A new role is a row. A new module declares what it needs and inherits enforcement rather than reimplementing it.
The same rule decides what renders and what the server will answer. An interface that omits a button while the endpoint behind it still responds has decorated a permission rather than enforced one.
The platform grew without the access model rotting, which is the usual failure mode and the reason it was worth building properly at the start.
A sixth user type is configuration. Adding one does not mean auditing every screen that already exists.
There is one place to check. A security review examines how permissions resolve rather than every branch in every module.
Enforcement is not cosmetic. What a user can see and what they can reach are the same decision.
The guest who never signed up
Browsing and enquiring without registering is deliberate, because a sign-up wall loses most of the people who hit it, and somebody looking for a flat at eleven at night is not going to create an account first.
But a pre-viewing questionnaire collects real details from a person who declined to have an account, and that makes them a data subject the platform holds information about without the relationship an account implies.
So what is kept is decided rather than defaulted. What the questionnaire collects, how long it is held, and what it may be used for are answers the platform has rather than a side effect of a lead capture form.
And the person can reach it. Somebody who declined an account should not have to create one in order to see or remove what was collected about them.
The platform stays open to everybody, which is the commercial point, without treating the people who came through the open door as a lower category of person. And a question from a regulator about pre-registration data has an answer that was designed rather than reconstructed.
Two people who can talk without exchanging identities
Rental deals stall and sour in the gaps. Questions unanswered, details lost across calls, texts and email, no shared record, and no privacy.
Each party corresponds through an address the platform issued. Messages are received, threaded to the right conversation, and delivered on, and neither side ever learns the other's real address unless they choose to share it themselves.
An enquiry is not a commitment. Asking about a flat should not hand a stranger a permanent way to contact you, and this falls hardest on the tenant, who has less power in the transaction.
A dispute has a record. What was agreed about a deposit, a viewing, a repair or a date exists in one thread rather than across two inboxes, a phone and a message app.
And the honest cost. Relaying correspondence means the platform handles it. Retention has a period, access has a reason, and the arrangement is explained to both parties.
People reply from wherever they are and the thread survives. A tenant can enquire about ten properties without acquiring ten permanent contacts. And when something goes wrong, there is one place to look.
The controls underneath
Access is resolved in one place, and the same resolution governs what renders and what the server returns.
Correspondence is retained for a stated period rather than indefinitely, and access to it has a reason rather than a role.
Guest data has a defined life, and the person it belongs to can reach it without an account.
Three classes of event are recorded with actor and time. Who changed a listing after publication, who accessed another user's messages, and who altered a permission or a role. These are the three that would be asked about afterwards.
Generated content is traceable to its inputs. Which property attributes produced a description, and which stated requirements produced a recommendation, are kept, because a fairness question that cannot be answered is a fairness question that has already been lost.
Payment handling stays with the payment provider, so the platform holds references rather than instruments.
Which criteria apply, and one that does not
Privacy is the criterion this platform lives on. The people it holds data about include tenants, landlords, roommates, and guests who declined an account and were captured anyway. Defined retention on correspondence, guest data with a life and a route to reach it, and an address model that lets two strangers correspond without exchanging identities are all answers to that.
Confidentiality is the second, and it sits in the permission model. Five user types on one platform means the question of who can reach what is asked on every screen, and answering it in one place is what makes it answerable at all.
And one thing the criteria do not cover.
None of the five trust services criteria asks whether a recommender steers by a protected characteristic, or whether generated advertising copy describes a preferred kind of tenant. A platform can satisfy every criterion completely and still be doing the thing this page spends its first three sections on. That is not a criticism of the framework. It is a reason not to treat a control set as a substitute for thinking about what the software actually decides.
The control set was designed against the criteria rather than mapped to them afterwards. That is a statement about how the platform was built. It is not a claim to hold an attestation.
The constraints we designed around
Nobody reads a listing they had to write
The challenge. Landlords either spend real time on a description or post a thin one. Both are bad outcomes, and asking them to try harder does not work, because the person with one flat has no reason to become a copywriter.
What we did. Made a good listing the default output of entering the facts, with review rather than authoring as the landlord's job.
Listings go live faster and read consistently across the platform, which matters more than it sounds, because a catalogue where quality varies wildly trains tenants to distrust all of it.
A sign-up wall is where most visitors leave
The challenge. Requiring registration before somebody can look loses the majority of them, and the ones lost are disproportionately the people just starting to search.
What we did. Opened browsing and enquiry to guests, and treated the details collected as data with obligations rather than as a lead.
More visitors engage, and interested people are captured for conversion instead of lost at a wall, without the platform quietly accumulating a database of people who never agreed to be in one.
A roommate is a different kind of match
The challenge. Matching somebody to a property and matching two people to live together are not the same problem. Shared living carries different legal treatment from whole-property letting in most jurisdictions.
What we did. Treated it as its own matching context with its own rules rather than as a variation on property search, so the distinction is explicit in the system rather than assumed.
The feature works without importing rules from a context where they do not apply, or exporting them into one where they do. Getting this wrong in either direction is a problem, and the safe-looking direction is not automatically the correct one.
The impact, depending on your job
If you run the business
Fairness is a market access question before it is an ethical one. A rental platform that cannot answer how its recommender works has a problem in every jurisdiction it wants to operate in, and the answer is much cheaper to build in than to retrofit under scrutiny.
Generating the listing moves responsibility to the platform. That is the cost of the feature, and it is worth paying, but only if the generator is constrained. Unconstrained, it is a liability that scales with adoption.
The open catalogue is a commercial position too. A tenant who suspects they are being shown a curated subset stops trusting the platform, and trust is the entire product in a two-sided marketplace.
If you run engineering
The recommender constraint is the part worth your attention, because it is architectural rather than a property of the model. Ranking an open catalogue cannot steer, whatever the model learns, and the guarantee survives the model being replaced.
Then the permission model. Many-to-many resolved in one place, with the same rule governing render and response, which is the difference between an access model that scales and one that quietly stops being true.
If you run a delivery team
Most of what is on this page came from deciding where things live. Permissions are data. Generated copy is constrained by what it may write about rather than reviewed after the fact. Recommendation sits over search rather than replacing it.
That last one is the maintainability decision as well as the fairness one. A ranking layer over an open catalogue can be changed, tuned or removed without anybody losing access to anything.
If you own the numbers
Vacancy is the cost that pricing addresses, and a week of empty property is worth more than most software.
Wasted viewings are a real expense, and listing accuracy is what removes them.
Guest capture converts without a registration wall costing the majority of visitors before they see a property.
One permission model serves five user types, so adding a sixth is a configuration change rather than an audit of everything already built.
Talk to the client, not just to us
Everything on this page is our account of our own work. If you are seriously evaluating us, we will arrange a reference call with a client who has been through a build like this one, and you can ask them the questions you would rather not ask us.
Technologies we built with
We name the layers rather than the suppliers on the user data path, because a supplier map is our client's exposure rather than our credential. Full detail available under NDA.
More case studies
View all case studiesPutting AI somewhere a wrong answer has consequences?
Tell us what you're building, and we'll tell you honestly how we'd approach it.