RENT2RENT

How RENT2RENT works

Forty seconds of what the client sees: Rightmove listings collected every few hours, 99 % of them dropped with a reason, the ceiling rent and the target offer for every house, an enquiry the AI drafts and a person sends, and the board from listing to signed lease.

What we built

• A Rightmove parser on Playwright with saved searches, scheduled runs every few hours, a pool of UK proxies with rotation, quarantine and resume from the same page.
• The return calculation in both scenarios, the whole house and the studios, with the ceiling rent, the target offer, a verdict per house and rejection filters that always name the reason.
• Enquiries through the Rightmove form from the client's own accounts, with templates, landlord questionnaires and a human gate on every send; replies come back into the card, classified by the AI.
• A board of eight columns, comments, history, Telegram notifications, export, users with roles and an audit log. The interface in English, Ukrainian and Russian.

Ceiling rent, not a list of houses

The calculation follows the client's method. Occupied nights are the occupancy times 365; the gross income is the nightly rate times the nights; VAT, the platform fee and operating costs come off, and what is left before rent is the key figure. Net profit is that figure minus the annual rent, ROI is net profit over the rent, because the house is rented, not bought.

• The ceiling rent is the rent above which the deal goes negative: the hard limit for haggling. From it the system derives the target offer, the figure to open the conversation with at the ROI the client wants.
• Two market variables. The nightly rate and the occupancy. For an area the system has not seen it asks the model and clamps the occupancy to a 50 to 85 per cent corridor, so an optimistic estimate cannot inflate the return.
• Your figure beats the model's. As soon as the operator enters their own rate for an area, the system remembers it and never asks the model about that area again. The scoring settings show what will change before anything is recalculated.

Enquiries under human control

• From the client's own accounts, each with a proxy address of its own, fixed for good and separate from the parser pool, so the platform never sees a signed-in user and a crawl of hundreds of pages from one address.
• Two safety switches, a toggle in the interface and a variable on the server, and both must be on. Sends are spread across accounts with a daily limit and an 8 to 14 minute pause between them.
• Templates as an A/B test with a weight per template; the dashboard shows which template actually books a meeting. Landlord questionnaires are answered from a profile, the free-form questions are drafted by the AI and shown before sending.
• Replies come back into the card, classified as interest, clarifying, soft refusal or hard refusal; a phone number in the text turns into a WhatsApp button. The answer is drafted by the AI and sent by the operator.
• AI photos furnish the original, never invent a room, because the picture goes into a test advert and the viewing must match it. Generation starts only after the agent shows interest, every photo is approved by a person, and the monthly AI budget warns at 80 per cent.

Results in numbers

The figures are from the live system two months after the second iteration went into production.

• 1,460+ listings collected by the parser from the client's searches, about 530 of them in the latest week.
• 99 % rejected automatically by the filters, each with a reason; the operator reviews a dozen houses, every one with a ceiling rent and a target offer.
• 68 areas with a market estimate, every one of them open to the operator's own figure.
• A run takes 1 to 7 minutes, every few hours, with no proxy lost to a ban so far.
• Zero sends without a person: the dry-run mode and the server switch are both logged.

Under the hood

• Next.js + TypeScript admin panel on Vercel, in three languages, with a light and a dark theme.
• FastAPI on Python with PostgreSQL, Redis and Celery workers, in Docker on a VPS: the parser needs resident workers, a real browser and proxies with fixed outgoing addresses, which serverless does not give.
• Playwright crawl worker behind the proxy pool; a model through an API for market estimates, questionnaire answers, reply classification and photo staging, with a spend counter per task and a monthly limit.
• GitHub Actions deploys on every push; passwords and account cookies are encrypted at rest.

What comes next

• Live sending after calibration on the real enquiry form, with the human gate kept.
• WhatsApp through the Cloud API, so the conversation with the agent stays in the card.
• More platforms: Zoopla and SpareRoom in the UK, Idealista for the Spanish market; inbound enquiries from tenants and a tenant base.