The Landlord App: Property Management, Built Quality-First

The Landlord App is a web-based property management platform for self-managing UK landlords — the people running roughly one to ten properties themselves, without a letting agent — and, deliberately, for their tenants too. Rather than landlord software with tenants bolted on as records, it's a genuinely two-sided platform where both sides collaborate.

It's an in-progress product I'm designing and building solo. This case study is less a feature tour than a look at how I think — the decisions, trade-offs and quality discipline behind it — because that's what matters if you're considering working with me.

Most self-managing landlords run their properties on a patchwork of spreadsheets, email, WhatsApp, cloud folders, paper and memory. Information scatters, and nothing lives in one place. Their tenants, meanwhile, have nowhere central to see documents, track rent, report a repair or reach their landlord — so every interaction is fragmented.

The real cost isn't just wasted time; it's disorganisation and risk. Compliance certificates — Gas Safety, EICR, EPC — quietly expire, and a lapsed certificate isn't mere admin: it can bring fines and can legally block a landlord from regaining possession. Documents get lost, rent disputes come down to “did you pay?” with no shared record, and it all compounds as a portfolio grows.

Most existing tools are single-sided and finance-first — built for the landlord's bookkeeping, with the tenant as a payment record. The Landlord App makes the opposite bet: a two-sided, communication-first platform where landlord and tenant work together. It targets an underserved middle — landlords too big for spreadsheets, too small to justify an agent's fee or enterprise software — and it competes on focus, not feature count, obsessing over the handful of workflows landlords perform every week.

To be clear about scope: today's product isn't a replacement for a letting agent. It's the organisational backbone that makes self-management far easier — the foundation for something larger, built deliberately over time (more on that below).

In a platform where landlords and tenants share one system, the challenge isn't writing features; it's modelling ownership, permissions and lifecycle correctly. My instinct, shaped by a decade in QA, is to keep asking “what happens if…” until the design handles the real world, not just the happy path.

The tenant invitation is a good example. It looks trivial — a landlord invites a tenant — until you interrogate it:

None of those were bugs — they were decisions to make before implementation. Working through them turned a simple registration screen into a tenancy-centred invitation model: a secure onboarding mechanism that ties a specific person to a specific tenancy while preserving the permission boundaries that run through the rest of the app.

I don't do this in isolation, either. I use AI as an experienced engineering partner — to challenge assumptions, surface risks and review decisions — while the judgement and direction stay mine. It accelerates the thinking; it doesn't replace it.

Quality here isn't a phase at the end. A decade in QA taught me the cheapest defect is the one that never gets the chance to exist — so instead of “how will I test this later?”, I ask “how do I design this so it's easier to build correctly and harder to build incorrectly?” That question shaped the stack, the data model and the security model before a single test was written.

In practice, that means defence in depth — strict TypeScript, shared validation schemas, database constraints and Row Level Security — each catching a different class of problem. And I'm precise about where the project stands today: those built-in gates are working now, while broader automated test suites, including tests that prove the access boundaries hold, are the deliberate next step. I'd rather show exactly where it is than imply coverage that isn't there yet.

The product is exactly where I planned for it to be: at the smallest version that can prove the idea, ready to be validated with real landlords before it grows any further. The core is in place — the six workflows, secure onboarding, and database-enforced access control — on a production-quality architecture. This is a deliberate MVP stage, not an unfinished one: the next milestone isn't more features, it's evidence.

So my current work is intentionally narrow — hardening the automated tests around the security boundaries and critical workflows, deploying a stable MVP, and putting it in front of real landlords to learn what genuinely helps them day to day. At this stage a single piece of honest feedback is worth more than another feature, because the job right now is to validate the idea, not to inflate it.

Beyond validation, the roadmap is sequenced by intent rather than ambition. First, deepen the organisational core — automated compliance reminders so a certificate never lapses unnoticed, richer document and maintenance handling, notifications and reporting. Only later come the higher-complexity capabilities like rent collection and financial tooling, each earning its place by justifying the complexity it adds.

The long-term vision is a genuine “property management company in your pocket” — but I'm careful to hold that as a destination, reached one validated step at a time, not a claim about what exists today. Naming where something is going is easy; the discipline is being honest about how far along the road it actually is.

For most of the last decade, my role has been to assure the quality of software that other teams designed and built — finding the risks, strengthening what shipped, and being the person who asks “but what happens if…”. This project is where that role changes shape. Here I own the entire lifecycle: the discovery, the product decisions, the architecture, the engineering, the quality strategy and the deployment, end to end.

That's the transition this represents — from safeguarding other people's products to being fully accountable for one of my own. And it has confirmed something I long suspected: the instincts I built in QA are at their most valuable when they shape a product from its very first decision, not when they're brought in to check it at the end.

If you're deciding whether to work with me, this project is the honest answer. It's how I'd approach your product too: start from the real problem your users have, model it faithfully, weigh every trade-off against your goals, and make the decisions today that keep the software cheap to own and safe to change for years.

And it reflects the one belief that runs through everything I build: progress isn't measured by how many features you've shipped, but by how much you can trust what you've built — and that trust is designed in from the very first decision, never bolted on at the end. That's the standard I've held this project to, and exactly the standard I'd hold yours to.