When "good enough" stops being good enough
After week one, I had a working system. It could handle properties, photos, basic authentication. I could have kept adding features—landlords, tenancies, inspections—but something was nagging at me.
The system wasn't production-ready. Not really. It worked for one agency, but what happens when ten agencies want to use it? How do they integrate with Rightmove? What happens when something breaks in production—do I even know it broke?
This week was about stopping myself from building shiny new features and instead building the boring infrastructure that separates a side project from actual software people trust with their business.
The multi-tenancy epiphany
Here's a decision I almost got catastrophically wrong: I nearly built LetAdmin as single-tenant software. One database per agency. Each agency gets their own deployment.
Sounds reasonable, right? Except it's a nightmare to maintain. Want to fix a bug? Deploy to 20 different instances. Want to add a feature? Test it 20 times. One agency needs a security patch immediately? Well, I hope you're not planning to sleep tonight.
So this week I bit the bullet and implemented multi-tenancy properly. Every agency shares the same application, but their data is completely isolated. An agency at northside.let-admin.com literally cannot see—at the database level—any data belonging to southside.let-admin.com.
Was it scary to build? Absolutely. Did I worry about getting it wrong? Constantly. But now when I fix a bug or add a feature, it's live for everyone instantly. That's the kind of leverage that makes a solo developer sustainable.
APIs: because agencies already have too many systems
Nobody asked for an API. But I built one anyway, and here's why: every letting agency I've talked to already uses about seven different systems. They have something for property portals, something for accounting, something for compliance, something for tenant referencing...
If LetAdmin is going to replace any of those, it needs to play nicely with the others. That means APIs. Proper OAuth 2.0 authentication, rate limiting, the works. So when an agency says "we need this to push properties to Rightmove automatically," the answer is "yes, here's the documentation."
Building APIs before anyone asks for them feels premature. But building them after someone needs them urgently? That's when you build them badly under pressure.
The test coverage obsession
I'm going to admit something: I hate writing tests. They're slow, they're boring, and honestly, I'd rather build features.
But here's what I learned on a previous project: skipping tests feels fast until it isn't. You change something small, something breaks somewhere else, users find the bug, and suddenly you're spending your evening emergency debugging because you couldn't be bothered to write a 5-line test six months ago.
So this week I forced myself to get to 100% test coverage. Every single line of code has a test. Does this guarantee the code works perfectly? No. But it guarantees that if I accidentally break something, I'll know before my users do.
It's unsexy. It's slow. But it's the difference between "works on my machine" and "works in production at 2am on Saturday."
What agencies actually gain from this
If you're running a letting agency, this week probably sounds incredibly boring. Multi-tenancy? APIs? Test coverage? Who cares?
Here's why you should: this is the week LetAdmin became software you can actually rely on.
You won't lose your data. Multi-tenancy with proper isolation means even if there's a security breach somewhere, your data stays yours. Always.
Your existing tools keep working. Need to push properties to Rightmove? Pull data into Xero? The API makes that possible—and agencies don't need to hire developers to build custom integrations.
Updates don't break things. When I add that new feature you've been asking for, the tests ensure I'm not accidentally breaking the reports you run every Monday morning.
It just works. Fast property pages, drag-and-drop photo ordering, infinite scroll that feels natural—these aren't revolutionary features, but they're the kind of polish that means you spend less time fighting your software and more time letting properties.
What I learned
The hardest part of this week was discipline. I wanted to build landlord management. I wanted to add inspection forms. I wanted to implement automated email templates.
But I didn't. Instead, I built the infrastructure that means when I do build those features, they'll actually work reliably for agencies running real businesses.
Sometimes the most productive week is the one where you ship nothing users can see, but everything that means what they can see will actually work.
Next week: back to visible features. But now with a platform that can handle them properly.