The mobile sidebar problem
Here's an embarrassing confession: I didn't realise the mobile experience was broken until I actually used it on my phone.
The sidebar worked perfectly on desktop. You click a menu item, navigate to that page, sidebar stays open for the next navigation. Makes sense, right?
On mobile though? Disaster. You tap "Properties", the sidebar slides in from the left covering the screen, you tap a property, and... the sidebar is still there covering your content. You have to tap the overlay to close it, then finally see what you wanted. Every. Single. Time.
How did I miss this? Because I was developing on a laptop. Classic mistake.
This week was about fixing things like this—the small frustrations that seem minor in isolation but compound into "this software is annoying to use." And let me tell you, agencies won't tolerate annoying software when they're managing hundreds of properties.
When property status gets complicated
One of the conversations that shaped this week: a letting agent explained that their property was "tenanted but they're advertising it because the current tenant is moving out next month."
Our system couldn't represent that. A property was either "available" or "let"—binary. Real world? Not binary at all.
So I split property status into three separate concepts:
- Tenancy Status: Is someone living there now?
- Marketing Status: Are we advertising it?
- Financial Status: What's the revenue situation?
Seems obvious in hindsight. But it required stepping back from "how property management systems traditionally work" and asking "how do agencies actually think about properties?"
The result? An agency can now have a property that's "Let" (tenant in place), "Available" (accepting viewings), and "Active" (generating revenue)—all at the same time. Because that's reality during the notice period.
The audit trail I didn't want to build
I'll be honest: audit trails are boring. Nobody gets excited about logging who changed what when. But then I talked to an agency that got into a dispute with a landlord about rental prices.
"The landlord claimed we'd agreed to £1,200 per month. Our system said £1,000. We had no way to prove what was originally agreed or when it changed."
They lost that landlord. Not because they were wrong—because they couldn't prove they were right.
So this week I built a comprehensive audit system. Every property update logs who made the change, when, and what the old value was. It runs in background jobs so it doesn't slow down the application, and it creates a permanent record that can't be altered.
Is it glamorous? No. Will it save an agency from a costly dispute someday? Absolutely.
##Mobile matters more than I realised
I've been guilty of treating mobile as an afterthought. Build it for desktop, make it "responsive", job done.
But watching someone actually use LetAdmin on a phone in a property (terrible lighting, one hand holding their phone, trying to upload photos)—it changed my perspective.
This week I fixed a bunch of mobile-specific issues:
- The date picker now works properly with one thumb
- Form buttons stay visible even when the mobile keyboard is up
- The sidebar closes automatically after navigation
- Modal forms have proper spacing so buttons aren't hidden
These sound trivial. But they're the difference between "I can use this on site" and "I need to wait until I'm back at the office."
What agencies actually get
Here's the thing about polish: it's invisible when done right. Agencies using LetAdmin this week won't think "wow, great audit trail!" They'll just know that when their compliance officer asks who uploaded that EPC certificate and when, they can answer instantly.
They won't marvel at the three-dimensional property status system. They'll just know that when they're showing a property that's technically still tenanted but the tenant's leaving next month, the system can represent that accurately.
They won't appreciate the mobile sidebar fix. They'll just use their phone between viewings without getting frustrated.
Good UX is invisible. But bad UX? Everyone notices that.
What I learned
This was the first week where I focused on problems that weren't obvious until someone actually used the software in the real world.
It taught me that building features isn't enough. You have to watch people use them, listen to where they get confused, and fix the annoying bits even when they seem trivial.
The best software doesn't make users think "this is clever." It makes them think "this just works." And sometimes getting to "just works" is harder than building the feature in the first place.
Next week: back to bigger features. But I'm keeping this lesson—if it's annoying, it needs fixing, even if it's "only a mobile thing."