Scheduloo in production -- the edge cases we didn't see coming

Scheduloo has been in production with real users for about eight weeks. The core functionality works. Calendar sync, appointment booking, buffer times, confirmation emails. All of that held up. What did not hold up was our assumption that users would use the product in ways that resembled how we imagined it being used.

This is the part of building software that nobody really prepares you for. Not bugs in your code, but correct code being used in contexts you never modelled.

The timezone problem we thought we had solved

We handled timezones. We were very confident we had handled timezones. User's local timezone stored at registration, all times stored in UTC, converted on display. Textbook.

What we did not handle was the scenario where a business owner in Mumbai sets up a booking page, shares it with clients, and one of those clients is in Dubai. The Dubai client sees available slots in their timezone, which is fine. The Mumbai owner receives the booking confirmation and sees the appointment in their timezone, which is also fine. Then the Dubai client WhatsApps the Mumbai owner to confirm "see you tomorrow at 3pm" and they are both talking about different times.

The system was technically correct. The human experience was a mess. We added a feature within two weeks: every confirmation email now shows the time in both the host's timezone and the guest's timezone, with a note explaining the difference if they differ. Small change. Should have been there on day one.

Recurring bookings and the edge case nobody mentioned

One of our early users, a yoga instructor in Pune, started setting up a recurring weekly class. Our system supported recurring bookings. What it did not support well was a recurring booking that needed to be cancelled for one specific week because of a holiday, without cancelling the whole series.

She ended up cancelling the entire recurrence and manually recreating it. She did not complain. She just did it. We only found out when we looked at her booking data and saw an unusual pattern. When we called to ask, she explained it very politely and said she assumed it was "just how it worked."

That assumption, "just how it works," is the thing that kills products quietly. Users do not always tell you when something is broken. They adapt. And then they churn because adapting is tiring.

What we learned about watching, not just asking

We set up basic session recording after week three. Watching five users navigate the dashboard taught us more in two hours than our entire pre-launch user interview process. Interviews tell you what people think they do. Recordings show you what they actually do.

The gap between those two things is where most product decisions go wrong. We have a list of eight improvements queued from those recordings, none of which were in our original roadmap.

Production is the real spec. Everything before it is a guess. A well-informed guess if you do the work, but still a guess.