The original description
« I manage around thirty rental units on behalf of several owners. Each property has an address, a floor area, a monthly rent and charges, and belongs to an owner. A property is let under a lease, with a tenant, a start date, a term and a security deposit. Every month I need to know which rents have been collected and which are overdue, and I want to be warned about leases coming to an end. I also need a per-owner statement I can send them. »
The plan you approve before generation
Before a single line is written, Blueprint Maker turns that description into a plan you approve. For Trousseau the plan fits on one screen: five entities — Owner, Property, Tenant, Lease, Rent — and the links between them. A property belongs to an owner; a lease ties a tenant to a property; a rent belongs to a lease and carries its month.
The statuses inferred from the text appear in the same plan: a lease moves through active, ending, terminated; a rent through due, collected, overdue. The indicators you asked for are spelled out. If an entity is missing, a status is one too many, or a label isn't the one you use, you fix it here — what gets generated is what was announced.
- Entities: Owner, Property, Tenant, Lease, Rent
- Relations: property → owner; lease → property; lease → tenant; rent → lease
- Statuses: active / ending / terminated; due / collected / overdue
- Indicators: rent collected this month, current arrears, leases coming to an end, occupancy rate
Navigation: one section per entity
The generated application opens on a plain sidebar: Dashboard, Properties, Owners, Tenants, Leases, Rents. Each section leads to a list — not a spreadsheet, a real application list: search at the top, columns you sort with one click, pagination, and a counter telling you how many results match the current filter.
The rent list shows the month, the property, the tenant, the amount and the payment status. A faceted status filter and a period filter sit alongside the search. Those filters live in the page address: the "rents overdue this quarter" view can be bookmarked, or sent to your colleague — they open exactly what you were looking at, not the default view.
Every list exports to CSV, and the export carries exactly the rows shown on screen, filter included — the count is in the button label, so you know what you are taking before you click.
The deadline banner: what needs handling this week
This is the most useful piece of a rental tool, and it is added automatically as soon as an entity carries a due date. Above the list, the application shows a banner summarising the state in one line: how many deadlines have passed, how many fall today, and how many land within seven days.
Below it, the five nearest deadlines are listed by name, sorted by date, each with a "Handle" button that opens the relevant record directly. If there are more, the banner says so rather than growing. A row whose status marks it as settled drops out of the banner on its own: you only see what is left to do.
In practice: you open the application on Monday morning and see, without sorting or filtering anything, the overdue rents and the leases about to expire.
The property record: current lease and rent history
Clicking a row opens a READ-ONLY record — not the edit form. The distinction sounds minor; it isn't: you look at a property twenty times for every time you correct it, and opening a form to read is the surest way to change something by accident. The "Edit" button is right there, when that is genuinely what you want.
A property record carries its address, floor area, rent and charges, and its owner. Below comes the part that changes everything compared with a spreadsheet: the current lease with its tenant and end date, then the rent history for THIS property as a dated table — the months collected, the one overdue, the next one due.
That linkage isn't cosmetic, it comes from the generated relational database. Fixing a tenant's contact details fixes them everywhere; an owner's statement derives from their properties, nothing is retyped by hand.
Indicators that lead somewhere
The dashboard carries the indicators the description asked for: rent collected this month, current arrears, leases coming to an end, and portfolio occupancy. These are queries against the database, not entries: every rent recorded updates them.
Two details change how you use them. First: each card states ITS period, under the figure — "This month", "Last 30 days", "All time". A number without its window always reads as "recent", and that is rarely what it means.
Second: the card is clickable. Clicking "current arrears" opens the rent list with the indicator's filter already applied, announced by a chip you can remove with one click. You go from the figure to the rows behind it without rebuilding the filter from memory — and if one of the indicator's clauses cannot be reproduced as is, the click still takes you to the list, simply without the filter: a half-filtered list that looked complete would be worse than no filter at all.
The per-owner statement, built to leave the screen
This is the pitch's explicit request, and it gets its own screen: a per-owner summary statement aggregating their properties, the rent collected over the period and the charges, with a header stating the unit of the amounts.
That screen carries a deterministic "Print" button — not a call to a service, not a template filled in by an AI: the browser's own printing, with A4 layout and page breaks provided by the application's stylesheet. The button itself is hidden from the output, so it never appears on the printed page. From there you print, or save as PDF through the browser, and send it.
What the application does not do, and you should know before
Trousseau keeps the register: which property, which lease, which tenant, which rent, settled or not. It does not collect money: no online payment, no direct debit, no bank reconciliation is generated. A rent is marked collected once the money has arrived elsewhere.
It does not issue a rent receipt in the legal sense: the summary statement prints, but it is not a regulated template with numbering and mandatory wording. It produces no tax return, and has no electronic lease signing.
Finally, it DISPLAYS deadlines, it does not send them: the banner reports what is overdue and what is coming when you open the screen, with no automatic email or text message to the tenant. These are pieces a developer can add — the code exports — but they do not come out of the generation.
Demo data: judging on full screens
Trousseau arrives populated: several months of simulated life, properties at plausible addresses spread across several owners, leases at different stages, rents collected and — deliberately — a few overdue plus a lease close to its end date, so you can see the banner and the indicators working on something other than zeros.
That is a deliberate choice: you cannot judge a management tool on empty tables. The demo data is then cleared to make room for the real thing. The application lives at its own URL, and its full source code exports (ZIP or GitHub push), standard Next.js + Prisma.