Here's a thing that seems obvious in hindsight and wasn't obvious at all while building: a person who books a yoga class on Tuesday might host a coaching session on Thursday. The same human, two roles, one life. And until today, Book A Sloth treated them as two different people -- a guest account here, a host account there, no connection between them.
That's fine for a prototype. It's not fine for a real product that real people use daily. Because the moment someone has to maintain two logins, two email addresses, two passwords for the same platform, you've told them something about your product: that you didn't think about their actual life. You thought about your data model, and you made them live inside it.
Unified identity
Today I unified it. One account, one login, two capabilities. You sign up once. If you book things, you're a guest. If you set up a page and offer services, you're also a host. Both at once, same email, same session, clean switch between the two worlds. No "create a separate host account." No confusion about which login goes where.
The hardest part wasn't the merge itself -- it was the URL structure. Guests and hosts need different spaces, different dashboards, different flows. But they arrive through the same front door. So I separated the URL structure clearly: guest-facing routes live in one namespace, host-facing routes in another, and the account that ties them together sits above both. A person moves between their two lives without ever feeling like they left.
Google-first onboarding
While reworking identity, I also made Google sign-in the primary path. Not the only path -- email/password still works. But the dominant one. Because in India, in 2026, asking someone to create yet another password is asking them to either reuse an existing one (insecure) or forget it by next week (frustrating). Google sign-in is one tap, no password to remember, no OTP to wait for. Friction removed at the exact moment friction kills you -- the first interaction.
Razorpay and UPI's ceiling
The other deep work today: hardening Razorpay subscriptions for UPI AutoPay. India's UPI has mandate caps -- there's a ceiling on what you can auto-debit without the customer re-approving. If your subscription price exceeds the cap, the recurring charge silently fails and neither you nor your customer knows until someone notices the money didn't arrive. So I built awareness of those caps into the subscription flow. The product now knows the limits, warns hosts who set prices near them, and handles the edge case where a mandate needs re-approval gracefully instead of silently breaking.
Identity and money. The two things a platform has to get right, because getting them wrong doesn't just frustrate people -- it breaks their trust in a way that's almost impossible to rebuild.