Building a Boarding OS for India

A dog boarding facility in India runs on four tools, none of which were designed for it. WhatsApp handles inquiries. A paper register handles check-ins. Excel tracks occupancy. Tally produces invoices at month end. The four do not talk to each other, so the owner is the integration layer.

Bos.Dog replaced that stack. It is our own product, not a client engagement, which matters for the honesty of what follows: we still run it, so the decisions below were either validated or paid for.

Where the time was going

The headline number was three hours a day, lost to WhatsApp. Not to complex negotiations — to the same three questions. Do you have space in November? What do you charge for a Labrador? What vaccinations do you need?

Each answer takes two minutes. None of them are recorded anywhere afterwards. Next month the same questions arrive from different numbers and get answered again from scratch.

The second cost fell on the customer. Once a dog was dropped off, parents got nothing until pickup. Anxious owners called. Those calls interrupted the staff who were caring for the dogs, which is a self-reinforcing problem: the less visible the care, the more the interruptions, the less time for care.

Designing for wet hands

The single most consequential decision was who we designed for.

The person who buys boarding software is the facility owner. The person who uses it, forty times a day, is a caretaker standing on a kennel floor with one hand occupied and the other wet. If you design for the buyer, you build a dashboard. If you design for the user, you build something a thumb can operate.

So care logging is tap-based. Meals, walks and mood are single presses, not text fields. This is a downgrade in expressiveness and an upgrade in adoption, and adoption is the only thing that matters — a care log that staff skip is worse than no care log, because it produces a record that is confidently incomplete.

Everything is mobile-first Android, in IST, priced in rupees. Not as configuration. As the assumption.

The 7pm update

Rather than answer anxious calls, we removed the reason for them: an automated daily update with photos, sent at 7pm.

The mechanism is simple and the effect is not. Parents stop calling because they already know. The staff time saved is real, but the larger change is in the relationship — the facility went from opaque to transparent without anyone doing extra work, because the care log staff were already keeping became the customer-facing artifact.

This is the pattern from the pillar piece: the record you create for internal reasons is usually worth more pointed outward.

The report card nobody scoped

At checkout, the system generates a branded report card summarising the stay — meals, walks, photos, mood.

Parents post them on Instagram. Unprompted.

We did not plan this as a growth mechanism. It emerged because the data was already there and presenting it well cost almost nothing. The result is that an operations tool built to save the owner three hours a day also became the facility's most reliable referral channel.

The generalisable version: in operations software, look for the moment where a customer is already feeling good about the service. That is where a shareable artifact belongs. For boarding, it is pickup. For a clinic it is discharge. For logistics it is delivery.

Indian tax law is not a settings screen

Generic international tools lose Indian operations businesses on billing. GST is not a tax field you fill in; it is a structure invoices have to be built around. UPI is not an alternative payment method; it is the default.

Building GST-compliant invoicing and UPI-native billing as assumptions rather than options is unglamorous and is most of why a facility switches. Every hour spent hand-correcting a foreign tool's tax output is an hour the tool has handed back.

This is the concrete form of the vertical-over-horizontal argument. A horizontal invoicing product can add GST support. It cannot make GST the default without breaking every other market it serves.

Discovery, as a side effect

Facilities also needed to be found. Each one gets a public profile page that ranks for "dog boarding in [city]" and captures inquiries directly.

That closes the loop the WhatsApp stack left open: the inquiry arrives in the system rather than in a chat thread, which means it can be counted, followed up and converted. Discovery and operations stop being separate problems.

What we would tell someone starting this

Three things, in order of how much they cost us to learn.

Replace the whole stack or none of it. Partial migration means staff maintain two systems and reconcile by hand, which is worse than the original problem. The payoff arrives when the last spreadsheet closes, not before.

Adoption is designed on the floor, not in the roadmap. Every field you add is a field someone skips at 6am with a wet hand. Fewer, tappier, faster.

Find the outward-facing artifact early. It is usually already in your data, and it will do more for growth than a feature you would otherwise have built.

If you are looking at a stack like this in your own business, the conversation is worth having — we have been through it from both sides, as the builder and as the operator carrying the support load afterwards.

• Case Study
• Operations
• India