Nobody will ever send me a message that says "I love your availability editor." It will never trend. No one screenshots a settings screen and says "look how beautiful this is." And yet I just spent two days on it — two days that felt longer than the week before them — and I'd argue it's some of the most important work I've done on the whole product.
Here's the thing I keep relearning: the parts of a product that get attention and the parts that decide whether it actually works are almost never the same parts. The public profile page is the face. The booking flow is the handshake. But the availability editor — the boring screen where a host tells the system when they're free — is the spine. Get it wrong and every single booking that follows is built on bad data.
So why did it take two days? Because of a fight that doesn't have a clean answer: powerful versus simple.
I built it one way first — a big grid. Every day, every hour, click to toggle. Maximally powerful. You could express any schedule imaginable. It was also a nightmare to look at, a wall of little cells that made a simple "Mon to Fri, 10 to 6" feel like programming a microwave from 1994. I threw it out.
Then I went the other way — dead simple toggles. Just on/off per day, pick a start and end time. Clean! Beautiful! And immediately too dumb for real people, because real hosts have lunch breaks, and split days, and "I do mornings on Tuesday but evenings on Thursday." The simple version couldn't say what their actual lives needed to say. So I threw that out too.
I kept landing in the gap between "so flexible it's confusing" and "so simple it's useless," and the truth is most hosts live in the boring middle: a normal weekly schedule, with a couple of exceptions. So the design has to make the common thing effortless and the rare thing still possible. That's the real art, and it's so much harder than either extreme. Anyone can build the powerful version. Anyone can build the simple version. Building the one that feels simple but quietly handles the edge cases — that's the two days.
Then there was the separate little war over blocked dates. "I'm off on June 20th." Sounds trivial. But how does someone say that without it being clunky? A calendar popup? A list they add to? Where does it live so it doesn't clutter the weekly view but isn't hidden so deep nobody finds it? I rebuilt that piece more times than I'll admit. A one-line feature — "let me mark a day off" — ate hours, because the interaction is the feature, not the concept.
At some point I had to physically stop myself. I caught myself about to rebuild the whole thing a fourth time, chasing some imaginary perfect version, and I made the harder decision: ship "good enough." Not sloppy — good enough. Clear, handles the real cases, slightly imperfect on the exotic ones. Because a perfect availability editor that ships next month is worth less than a good one that lets people book now. Perfectionism on an invisible screen is just procrastination wearing a nice outfit.
Here's what those two days actually taught me, and why I'm writing a whole post about a settings page: the boring screens are where the real product lives. Users feel the spine even when they're looking at the face. A clunky availability editor means hosts set their hours wrong, which means guests see wrong slots, which means broken bookings — and the guest blames the pretty profile page, never knowing the failure started two screens back in a UI nobody admires.
So I gave it the two days. Nobody will thank me. That's exactly why it mattered.
Tomorrow I get out of the code and into the scarier room: pricing. What this thing should cost, and whether anyone will ever actually pay.