Petboost Logo
Industry Insights

How We Built Petboost: One Business Type at a Time

Most pet software says "all-in-one." We earned it. Here is how we designed each business type individually before unifying them into one system.

Frazer McLeodFrazer McLeod
31 March 202614 min read
How We Built Petboost: One Business Type at a Time

Quick Version

Petboost was built by designing each pet business type individually (grooming, daycare, training, walking, boarding, puppy school) through hands-on time inside real Australian businesses, then unifying them into one multi-service platform without compromising the depth of any vertical.

Every pet software platform in the world says "all-in-one." Open any competitor's website and you will find the same claim: "One system for grooming, daycare, training, walking, and boarding." The words are identical. The promise is identical.

But the question nobody asks is: how did they get there?

Did they start with one business type and stretch it across the others? Did they add "boarding" by relabelling an appointment as a multi-day event? Did they support "training" by letting you create a recurring booking and calling it a course?

Or did they sit inside each business type, understand its unique workflows, and design purpose-built features before bringing them all together?

This is the story of how we built Petboost. Not as an origin myth, but as a verifiable account of the design decisions that shaped every corner of the product. Because when someone says "all-in-one," the follow-up should always be: show me how you earned it.


The Problem with "All-in-One"

The pet services industry is deceptively complex. From the outside, it looks simple: businesses book appointments for pets. A calendar with time slots should do the job.

But spend a single day inside a grooming salon, a daycare facility, a boarding kennel, or on a walking route, and you realise how different each business type actually is.

A grooming salon manages station capacity, coat-specific clipper settings, and breed-based weight restrictions. A daycare facility tracks play-area zones, temperament assessments, and pack compatibility. A boarding kennel operates on 24-hour billing periods with per-kennel occupancy limits. A walking business verifies locations, manages route-based capacity, and needs to prove the job was done.

These are not cosmetic differences. They are architectural differences that affect how the booking engine works, what data the system needs to capture, how invoicing calculates totals, and what information surfaces on an appointment card.

Generic booking tools (Acuity, Fresha, Square, Calendly) were designed for human-to-human services. They understand the relationship between a client and a service provider. But they have no concept of a pet sitting between the two, no vaccination tracking, no breed-specific eligibility, no multi-pet households.

Pet-specific platforms typically start with one business type and add others. A grooming-first platform might add "daycare" by letting you create a service category called "Daycare" with no play-area capacity, no temperament tracking, no zone management. It works on the surface, but the depth is not there.

We took a different approach.


1. Where It Started: Daycare and Hydrotherapy (2018-2022)

Petboost did not start as a software company. It started as a pet business.

In 2018, Annika Le Rade and I started Hound Health Bondi, a dog daycare and canine hydrotherapy business in Sydney's Eastern Suburbs. We tried every booking system available: Square, Timely, Acuity, and others. They were great tools for human service businesses, but none of them understood the fundamental relationship that defines every pet business: a person owns one or more pets, and each pet has different needs.

During the 2020 lockdowns, we had time to think properly. We spoke with over 40 pet business owners across Australia. Groomers, trainers, walkers, daycare operators, boarding facilities, puppy schools. We visited their businesses (when restrictions allowed), watched their workflows, and catalogued every pain point.

What we found was not a single problem. It was a collection of very specific problems, each unique to a business type.

From running Hound Health, we already understood daycare deeply:

  • Play-area zones are not just labels. A daycare with separate small-dog and large-dog areas needs per-zone capacity limits. When the small-dog area hits eight dogs, it needs to stop accepting bookings for that zone, not for the entire facility.
  • Temperament assessments need to happen before a dog joins the regular pack. This is not optional: it is a safety requirement. The system needs to enforce it.
  • Recurring bookings are the backbone of daycare revenue. The same dogs come every Tuesday and Thursday. The system needs to handle recurring bookings as a first-class concept, not a workaround.
  • Check-in and check-out flows happen in the chaos of morning drop-off. The interface needs to work with one hand while you are holding a lead in the other.

These were not feature requests from a backlog. These were problems we lived every day.


2. Training: Session Progress, Consult Gating, and Packages That Lock In Commitment (2022)

Dog trainers do not book appointments. They run programs.

A reactivity training program might be six sessions over eight weeks. A puppy foundation course runs for six weeks with a specific curriculum. A behavioural consultation is a one-off that gates access to ongoing training.

When we sat with trainers, we learned that their relationship with booking software was fundamentally broken. Generic systems let them create appointments, but they had no way to:

  • Track behavioural progress across sessions. Session 1: Bella pulls on lead, score 7/10 reactivity. Session 4: down to 3/10. The trainer needs this visible to themselves and optionally to the client.
  • Gate access to regular sessions. Many trainers require an initial consultation before accepting a dog into group training or ongoing 1-on-1 sessions. The booking system needs to enforce this: a new client cannot book a regular session until they have completed the initial consult.
  • Ensure commitment through packages. A trainer who sells individual sessions loses clients after session two when initial improvement plateaus. Packages that commit the client to a full program (six sessions prepaid) change the dynamic entirely. The system needs to support training packages as a distinct concept, not just a discount code.
  • Share notes with clients. After each session, the trainer writes up what was covered, what homework to do, and what progress was made. The client needs to see this in their portal without the trainer sending a separate email.

We built all of this as a purpose-designed training experience within Petboost. Session notes with photos and attachments. Client-visible progress summaries. Initial service gating that prevents direct booking without a qualifying appointment. Training packages with auto-deducting credits and expiry dates.

The training experience shares the same booking engine, payment system, and customer management as grooming and daycare. But the information it surfaces on the appointment card, the rules it enforces on booking, and the data it captures per session are completely different.


3. Puppy School: Age-Gated Enrolment, Class Pipelines, and Attendance Tracking (2022)

Puppy school was designed alongside trainers who run both group classes and private sessions. Their frustration was clear: existing software treated group classes as recurring appointments, which meant no enrolment management, no age eligibility, no attendance tracking, and no class capacity limits.

Age-gated enrolment. A puppy school for 8-to-16-week-old puppies needs to enforce age eligibility at booking time. If a puppy is 20 weeks old, they should not be able to enrol. We built age-based eligibility rules into the course enrolment system: the trainer sets the age range, and the system calculates eligibility based on the puppy's date of birth and the course start date.

Course templates and instances. A trainer runs "Puppy Foundations Level 1" every quarter. The template defines the curriculum (six weekly lessons), the capacity (eight puppies per class), and the price. Each instance is a specific run of that course with its own enrolment list, schedule, and attendance records. This is fundamentally different from a recurring appointment.

Enrolment pipelines. The trainer needs to see who has enquired, who has paid, who has been confirmed, and who is on the waitlist. We built enrolment as a pipeline with stages, not just a list. The trainer can see at a glance: "Friday 9am Puppy Foundations: 6/8 confirmed, 1 pending payment, 3 on waitlist."

Per-puppy attendance tracking. For each lesson in the course, the trainer marks attendance. Over six weeks, they can see which puppies attended every session and which missed a week. This feeds into course completion certificates and graduation records.


4. Walking: Location Proof, Route Capacity, and the Trust Problem (2023)

Walking businesses have a problem that no other pet service type has: they need to prove the job was done.

A groomer hands back a freshly groomed dog. A daycare sends photos during the day. A trainer demonstrates progress in person. But a walker picks up the dog, walks them for an hour, and drops them back. The owner is at work. They have no visibility.

We walked with walkers. Literally. We joined walking businesses on their routes to understand their workflow, and what we found shaped an entirely different set of features.

Location-verified check-ins and check-outs. When the walker checks in a dog, the system captures their GPS location. When they check out, it captures the location again. Both timestamps and locations are visible to the pet owner on an interactive timeline. This is not surveillance: it is proof of service that builds trust and eliminates disputes.

Walk photos and notes. During the walk, the walker can add photos and notes that appear immediately in the pet owner's portal. "Bella played with a Labrador at Centennial Park today" with a photo. This is the equivalent of a daycare's daily update, but for walking.

Suburb-based service restrictions. A walking business in Bondi does not service Parramatta. The booking engine needs to restrict self-service bookings based on the pet owner's suburb. We built suburb-limit constraints into the booking engine: the walker defines which postcodes they service, and the system only shows availability to pet owners in those areas.

Prepaid walk packages. A 10-walk package at a discounted rate locks in recurring revenue. The system auto-deducts a credit each time the walk is completed. The pet owner can see their remaining balance in the portal and purchase additional packages without contacting the walker.

Automatic payment after every walk. The walker checks out the dog, the card on file is charged, the branded invoice is sent. No awkward payment conversations. No outstanding invoices. The walker's job is to walk dogs, not chase money.


5. Grooming: Body-Area Notes, Station Capacity, and Coat Profiles (2023)

Groomers had the most vocal frustration with existing tools, and when we sat inside premium grooming salons across Sydney, we learned why. What we discovered changed how we thought about appointment data.

The clipper setting problem. A groomer needs to know that Bella gets a #4 blade on her body, a #10 on her sanitary area, and hand-scissored ears. This information needs to follow the pet, not the appointment. If Bella sees a different groomer next time, they need to see exactly what was done last time without asking the owner.

This led us to build body-area grooming notes: a system where each area of the pet (face, ears, body, legs, tail, sanitary) has its own persistent note field with blade settings, style preferences, and special instructions. This was not a text box labelled "notes." It was a structured data model designed with groomers who groom 15 dogs a day and cannot afford to ask "what did we do last time?"

Station capacity. A grooming salon with three stations cannot take four concurrent appointments. This sounds obvious, but generic booking systems track staff availability, not station availability. A groomer might be available, but if every station is occupied, they cannot work. We built per-resource capacity management that tracks stations independently of staff, with working hours per station and automatic overbooking prevention.

Breed and coat profiles. A Maltipoo's matting needs are different from a Husky's undercoat needs. We built a system of over 2,000 breed and grooming attributes that capture coat type, common breed-specific issues, weight-based service routing, and grooming history. When a new pet is added, the breed pre-fills relevant attributes. When the groomer opens the appointment, they see everything they need at a glance.

Weight-based service routing. A small dog groom takes 45 minutes. A large dog groom takes 90 minutes. The booking engine needs to know the pet's weight to assign the correct service duration and price. We built weight-based routing into the booking engine so the correct service variant is selected automatically when the pet's weight is known.

None of these features could have been designed by reading a requirements document. They came from watching groomers work, noting where they reached for a sticky note or opened a separate app, and designing the system to make those workarounds unnecessary.


6. Boarding: Kennel Capacity, 24-Hour Billing, and Overnight Care (2024)

Boarding was the vertical that challenged our booking engine the most. Everything we had built assumed appointments: discrete blocks of time with a start and end within a single day. Boarding stays are fundamentally different.

A boarding stay is not an appointment. It is a multi-day period with check-in and check-out times, per-night pricing, and specific care requirements. A dog boarded from Friday afternoon to Monday morning is not three appointments. It is one continuous stay with a tiered pricing model (first night might be $65, subsequent nights $55, multi-pet discounts applied per-pet per-night).

We spent time in boarding facilities to understand their workflow:

  • Kennel-level capacity, not daily limits. A facility with 20 kennels needs to track occupancy per kennel, not just "how many dogs are here today." Some kennels are large (suitable for two dogs from the same family), some are small. The system needs to know which kennels are available, not just whether the facility has space.
  • 24-hour billing periods. Most boarding facilities bill in 24-hour periods, not calendar days. A dog dropped off at 2pm on Friday and picked up at 10am on Sunday is two 24-hour periods, not three calendar days. This distinction matters enormously for pricing accuracy and fairness.
  • Vaccination enforcement. Boarding facilities require proof of current vaccinations before accepting a dog. The system needs to enforce this at booking time: if a dog's vaccination has expired, the booking is blocked with a clear message to the owner.
  • Care routines and feeding schedules. Each boarded dog has specific requirements: medication, feeding schedule, exercise preferences, anxiety triggers. These need to be visible to staff at a glance, not buried in a notes field.
  • Spillover rates. If a dog is picked up four hours after the 24-hour period ends, the facility might charge a half-day spillover rate rather than a full additional night. The system needs to handle this automatically.

We rebuilt our stay service architecture from the ground up. Stays have their own pricing engine (per-night with tiered discounts, multi-pet rates, and spillover handling), their own capacity model (per-kennel with size categories), and their own check-in/check-out flow (with care routine handover and feeding schedule display).


7. The Harder Problem: Bringing Them All Together (2024-2025)

After designing each business type individually, we faced the problem that most platforms try to solve first: how do you put it all together without turning the product into a bloated mess?

This is where the sequential approach paid off. Because we had designed each vertical independently, we understood exactly which parts of the system were universal and which were specific.

What is universal

  • The booking engine. Every business type needs to check availability, enforce constraints, and create bookings. The engine is shared, but the constraints are configurable per service type.
  • Payments and invoicing. Card on file, pre-authorisation, auto-charge, branded invoices: these work identically whether the service is a groom, a daycare session, a boarding stay, or a training session.
  • Customer and pet profiles. The Human-to-Pet relationship model is universal. Every pet owner has one or more pets. Every pet has a breed, weight, vaccination status, and care notes.
  • Automations. Booking confirmations, reminders, payment receipts, and Google review requests follow the same seven-stage journey regardless of service type.
  • Team management. Staff availability, service eligibility, and calendar views are shared across all service types.
  • Reporting and intelligence. Revenue, utilisation, customer metrics, and geographic intelligence span the entire business.

What is specific

  • Grooming: Body-area notes, coat profiles, station capacity, weight-based routing, 2,000+ breed attributes.
  • Daycare: Play-area zones, temperament assessments, recurring pack bookings, real-time check-in boards.
  • Training: Session progress notes, consult gating, training packages, client-visible progress.
  • Walking: Location-verified check-ins, suburb restrictions, walk photos, route-based capacity.
  • Boarding: Kennel-level capacity, 24-hour billing periods, tiered stay pricing, care routine handover, vaccination enforcement.
  • Puppy School: Age-gated enrolment, course templates and instances, class capacity, per-puppy attendance.

The key insight was that the universal parts provide the foundation, and the specific parts are not "add-ons" or "modules." They are purpose-built interfaces that surface the right information for the right context.

When a groomer opens an appointment, they see coat type, clipper settings, and station assignment. When a boarding facility opens a stay, they see kennel assignment, care routine, and feeding schedule. When a trainer opens a session, they see behaviour goals and progress notes. The same underlying system, but each view is designed for the person using it.

One plan, not five

We made a deliberate decision early on: one plan covers all service types. No grooming module add-on. No daycare surcharge. No boarding extension fee. Whether a business runs one service or seven, the price is the same.

This was not a pricing decision. It was a design decision. If we charged per module, we would have incentive to make each module feel separate and valuable on its own. By including everything in one plan, we had incentive to make everything feel unified. The pricing model and the product architecture reinforce each other.

Cross-service booking

A pet owner with a dog booked for daycare on Friday can add a grooming appointment on the same day in the same booking flow. One confirmation, one payment, one invoice. The groomer sees the grooming appointment. The daycare team sees the daycare booking. The owner sees one unified timeline.

This sounds simple, but it requires every service type to share the same booking engine, the same payment pipeline, and the same customer profile. It only works because we designed each service type on the same foundation from the beginning.


Why This Matters for Your Business

When you evaluate software for your pet business, ask one question beyond "does it support my business type?"

Ask: how does it support my business type?

Does it have grooming-specific body-area notes, or just a text field? Does it track kennel-level capacity, or just a daily dog count? Does it enforce age eligibility for puppy school, or just let you set a description? Does it verify walk locations, or just track appointment status?

The depth of specialisation is not something you can see in a feature comparison table. It is something you feel when you use the software every day. It is the difference between a system that tolerates your business type and one that was designed for it.

We did not build Petboost by adding business types to a feature list. We built it by spending time inside each one, understanding what makes it unique, and designing features that respect those differences. Then we solved the harder problem of unifying them.

That is how you earn the right to say "all-in-one."


See It for Yourself

Every claim in this article is verifiable. You can explore each business type on our website and see the specific features we built:

  • Dog Grooming: body-area notes, station capacity, breed profiles
  • Dog Daycare: play-area zones, check-in flows, recurring bookings
  • Dog Training: session progress, consult gating, training packages
  • Dog Walking: location proof, suburb restrictions, walk packages
  • Pet Boarding: kennel capacity, 24-hour billing, care routines
  • Puppy School: age-gated enrolment, class pipelines, attendance
  • Multi-Service: how it all comes together

Or start a free trial and see the depth for yourself. No credit card required.

Frazer McLeod

Frazer McLeod

CEO & Co-Founder

Frazer co-founded Hound Health Bondi and built Petboost to solve the problems he experienced running a pet business firsthand.

Ready to try?

See Petboost in action

Join many Australian pet businesses saving 20+ hours every week with intelligent automation.

1800 291 005