All writing

Bos.Dog, Three Months In

What our first facility actually uses, and what we built because of it

  • 6 min read
  • Sunny Luthra

In July we wrote up Building a Boarding OS for India: how Bos.Dog replaced WhatsApp, a paper register, Excel and Tally for dog boarding facilities, and why we designed it for a caretaker on a kennel floor with one wet hand.

Our first facility has been on Bos.Dog since 7 June 2026. In October we read its production data: read-only queries, counts only, no names or phone numbers. Every number in this post comes from that read, taken on 19 October. Some of what we wrote in July held up. A good part of it did not.

What we said, and what the data says

July postOctober data
Design for a caretaker on AndroidOne staff account, the owner. 132 of 143 sign-ins were on a desktop browser
A 7pm daily update with photosNo care logs since 9 July, so no updates
A report card at checkout that parents share182 report cards generated, 0 shared through the share link
A public profile that captures enquiries10 leads in total. Enquiries come by phone or WhatsApp and go straight into a booking
Replace the whole stackBookings and invoices are used every day

The last row is the one that matters. The facility moved its bookings and billing into Bos.Dog and kept them there. It skipped almost everything else.

What one person does all day

The facility runs Bos.Dog as a one-person front office. The owner signs in between 10am and 7pm, mostly around noon, on a desktop.

Bookings. About 55 a month. Check-in was recorded on 87% of them and a kennel assigned on 81%. Two habits stood out. 24% of bookings were entered after the dog had already arrived, and 75% were edited more than a day after they were created: dates, kennels and amounts change during a stay. The booking is a running record, not a reservation.

Invoices. One per stay, 154 since June, with 131 payments recorded. But 92% of those payments had no payment method, because "Mark paid" was a single tap that didn't ask. Cash and UPI could not be told apart, so the owner could not check the cash drawer against the books. The median time from checkout to payment was 3 days; a quarter took more than 10.

Customers. 54 of the 87 parents who booked since June have booked two or more times. This is a repeat business, and most of it never touches a lead form.

The money screens were wrong

The facility's previous software exported its bookings and invoices, but not whether the invoices had been paid. So 871 old invoices arrived in Bos.Dog as unpaid or part-paid. Two imported bookings had a checkout date of 31 December 2030, a typo in the source data.

The result: the Outstanding total showed about fifty times the facility's real dues. The real figure, 34 unpaid invoices, was there, but hidden under history. A money screen that is wrong by that much gets ignored, and then the real dues get ignored with it.

What we built in October

Each change below starts from one of the numbers above.

  • A go-live cutoff for invoices. Invoices issued before the cutoff stay as history and are left out of Outstanding, the Unpaid filter and the dues lists, unless you turn on "Show legacy". Only an owner can set it.
  • "Mark paid" asks how. UPI, Cash, Card or Bank, one tap, remembering the last one used. The Invoices page then shows what was received this month by method.
  • Dues on the Today screen. Unpaid invoices grouped by days since checkout (under 30, 30 to 90, over 90), each with a one-tap WhatsApp reminder that carries the invoice link and goes to the parent's current number. The row then shows when the reminder went.
  • Bookings that fell behind the calendar. A card for dogs still checked in after their checkout date and arrivals that were never checked in, with a button to check out, check in or mark the dog as a no-show.
  • Arrivals and departures over 7, 45 or 90 days. The owner asked for this on 12 September. The window had been fixed at 7 days.

None of these are large. All of them are where the owner already spends the day.

What we stopped building for them

The same data told us what to stop: care logs and daily updates, staff roles and tasks, expense entry, and mobile polish for owner screens (8% of sign-ins were on a phone).

We didn't remove any of it. A facility with a team of caretakers will use care logging, and the screens caretakers use still have to work on a budget Android phone. But the next facility like this one gets the bookings and money work first.

Meanwhile, India became a setting

In July we wrote that Bos.Dog runs in IST and rupees, "not as configuration, as the assumption". In October we made it configuration, to open the UK.

Before starting we counted what was pinned to India: 381 references to IST time functions across 105 files, and 293 references to rupees, paisa or the rupee formatter across 99 files. The facilities table already had a time zone column that no code read. That unused column was the way in: the facility became the unit of locale, and every hardcoded assumption was pulled through it.

Each facility now carries its own country, time zone, currency, phone format, tax rules and words. The 7pm update goes out at 7pm local time. India keeps its GST invoice rules, with CGST and SGST and a 16-character invoice number per financial year. UK facilities get prices that include VAT, "Carer" and "Drop-off" instead of "Caretaker" and "Check-in", a privacy notice for parents, and an opt-out in every offer message. Signups from countries we don't support yet go to a waitlist. The UK edition of the home page is at bos.dog/uk.

Hardcoding India was the right call for the first market. It kept the product simple while we learned what a facility needs. The time zone column was the one thing we had kept general, and it made the change cheap.

What we would tell someone three months after launch

Read production data before the roadmap. Counts only, read-only. Ours changed the order of everything we built in October.

Check who the user is. We designed for a caretaker on the floor. Our first user is an owner at a desk. Both exist; only one was using the product.

An import moves meaning, not just rows. Payment state didn't come across, and the money screens were wrong by a factor of fifty until we noticed. Check the totals after an import, not just the row counts.

Hardcode for the first market, but keep one seam open. One unused column made going global a pull-through instead of a rewrite.

Common questions

What does the first Bos.Dog facility actually use?
Bookings and invoices. One owner enters about 55 bookings a month on a desktop, checks dogs in and out, raises one invoice per stay and marks it paid. Care logs, daily updates, leads, campaigns and expenses are close to unused there.
Why did imported invoices show up as unpaid?
The facility's previous software did not export payment state, so 871 old invoices arrived as unpaid. Bos.Dog now has a go-live cutoff: invoices issued before it are kept as history and left out of outstanding totals and dues lists.
Does Bos.Dog work outside India?
Yes. Each facility now carries its own country, time zone, currency, tax rules and wording. The UK is the first market after India, with prices that include VAT and a privacy notice and offer opt-out for parents.
  • Case Study
  • Operations
  • India

Written by

Sunny Luthra

Founder & Lead Product Engineer, mRova

Creator of the HarnessArch specification, a public model for the systems built around language models. Writes here about what running our own products taught us that client work alone would not have.

Let's build your next product

Whether you are starting from an idea or scaling a system that has outgrown its first build, the next step is a conversation — not a form.

Founder-level attention, no handoffs, engineers who deploy.

Schedule a call