The obvious feature I'd been avoiding
Here's an embarrassing admission: for seven weeks I built a property management system without... landlords.
Yes, I know. Properties have owners. Managing those relationships is literally half of what letting agencies do. But I kept putting it off because I knew it would be complicated.
This week I finally built landlord management properly. And yes, it was complicated.
Why I'd been avoiding it
It's easy to manage properties as standalone things. Address, bedrooms, rent, photos—all straightforward. But add landlords and suddenly everything gets messier:
What if three siblings jointly own a property but one handles all the communication?
What if someone owns properties at 50%, 25%, and 100% across different investments?
What if an agency is migrating from another system with thousands of landlord records in a messy spreadsheet?
What if two agencies are using the same LetAdmin deployment and landlord records get mixed up?
These aren't edge cases. They're normal situations that any letting agency deals with every day. And I needed to get them all right.
The joint ownership puzzle
Here's a scenario that broke my initial design: married couple owns three properties. Two of the properties they own jointly (50% each). The third property, the husband owns 75% and the wife owns 25% because she inherited a quarter share from her parents.
How do you model that? You can't just say "these properties belong to this couple." You need ownership records that connect landlords to properties with percentages that can vary per property.
So I built a join table. Landlords have many properties, properties have many landlords, and the relationship tracks ownership percentage. Textbook many-to-many relationship.
But then the UI gets weird. You can't just display "Owned by John and Jane Smith" anymore. You need "Owned by John Smith (75%), Jane Smith (25%)" on one property and "Owned by John Smith (50%), Jane Smith (50%)" on another.
Getting that to display clearly without overwhelming the interface took more iterations than I'd like to admit.
The CSV import that had to work
When I talked to agencies about switching to LetAdmin, they all asked the same question: "How do we get our existing landlord data in?"
They're managing hundreds or thousands of landlords. Manual data entry? Forget it. Nobody's typing in a thousand landlord records.
So I built CSV import. But landlord data in real spreadsheets is messy:
Some have "Full Name" in one column. Others have separate "First Name" and "Last Name" columns. Some mix individuals and companies. Some have duplicate entries because they've migrated systems before.
The import system I built this week handles all of it: intelligently parsing names, detecting duplicates before creating chaos, supporting both file uploads and direct Google Sheets URLs, and—critically—making sure imports are scoped to the right agency in multi-tenant deployments.
The result? Agencies can migrate their entire landlord database in minutes instead of weeks.
The multi-tenant problem I couldn't ignore
Remember how LetAdmin is multi-tenant? Every agency gets their own subdomain, their data is completely isolated, they never see each other's properties?
Well, landlords need exactly the same isolation. Agency A's landlord list should never, ever show Agency B's landlords. Not in lists, not in reports, not in API responses, never.
This week I extended the tenant scoping system to landlord records. Every query automatically filters by current agency. CSV imports scope to specific agencies. Ownership relationships respect tenant boundaries.
The beauty of this architecture: it's completely transparent. Agencies don't think about multi-tenancy, they just use their system and their data is isolated automatically. But getting it right required careful database design and paranoid testing.
What agencies actually get
If you're running a letting agency, here's what this week means for you:
Proper landlord records. No more tracking ownership in spreadsheets or email folders. Every landlord is a proper record with contact details, ownership percentages, and property relationships.
Joint ownership that works. Multiple owners per property with configurable ownership percentages. The system tracks who owns what share and displays it clearly.
Painless data migration. Import your entire existing landlord database from CSV in minutes. The system handles messy data intelligently and prevents duplicate records.
Relationship tracking. See which landlords own the most properties, contact all landlords who own properties needing EPC renewals, run reports on portfolio performance by landlord.
Complete data isolation. Your landlord data never mixes with other agencies using the same platform. Multi-tenancy just works.
What I learned
This week taught me something about technical debt: avoiding complicated features doesn't make them go away, it just makes them more painful later.
I put off landlord management because joint ownership seemed tricky and CSV import seemed boring. But every day I delayed, agencies were managing landlord relationships in spreadsheets instead of proper software.
The lesson? Sometimes you need to build the complicated thing, even when you'd rather build something flashier. Landlord management isn't exciting. It won't win awards. But it's essential, and delaying it was just making the system less useful.
Also: multi-tenant architecture is non-negotiable. You can't add it later. Getting it right from the start means every new feature (like landlord management) automatically works correctly across all agencies without special handling.
Next week: probably something more exciting. But the landlord foundation is solid now, and that unlocks a lot of future features around reporting, communication, and landlord portals.