I Built My Own Software Because Running A Dog Walking Business Was Getting Too Complicated

When I started Wag & Walk, I did not expect to end up building software.

In fact, part of the reason I started dog walking was because I wanted something very different from my previous career in digital project management. Walk dogs. Get paid. Come home. That was roughly the plan.

It turns out running a dog walking business involves quite a lot of things that are not walking dogs.

There are enquiries to respond to, meet and greets to arrange, client information to collect, bookings to manage, payments to track, weather to check, reports to send and a calendar that increasingly starts to resemble a game of Tetris.

Then there is the actual logistics. Where is the next dog? How long will it take me to get there? Can I realistically fit another booking into that gap? Has somebody changed their usual day? Is that recurring booking actually recurring this week?

None of these things are particularly difficult on their own. The problem is that they are all happening at the same time.

I started with the obvious tools

Initially, there was not really a system. WhatsApp handled conversations. Google Calendar handled my diary. Client information lived in forms and notes. Payments were something I kept track of separately. New enquiries came through different places depending on where somebody found me.

For a very small business, that is completely manageable. Until it is not.

As I added more regular clients, I found myself checking the same information repeatedly. I would look at the calendar, then check a message, then work out where I needed to be, then check whether somebody had paid, then go back to the calendar.

I was not spending hours doing any individual task. I was spending a few minutes doing dozens of them. That distinction became important.

The problem was not the tools

Google Calendar is very good at being a calendar. WhatsApp is very good at messaging people. Neither of them knows what a dog walk is.

A calendar event does not inherently know which dog I am walking, whether the booking has been paid for, whether I have completed it, whether I need to send a report afterwards or whether I have enough time to get to the next booking.

I could put all of that information into a calendar event manually. But then I would effectively be building a dog walking management system inside the description field of Google Calendar.

At some point I realised I was trying to make general-purpose tools understand the way my business worked. That was backwards. So I started building something that did.

The Hub started very small

I did not sit down and decide to build a software product. I wanted somewhere that showed me what I actually needed to know: who am I walking today, what time, where, have they paid, and what do I need to do next?

That became the first version of what I now call the Hub.

Then the annoying thing about solving one problem happened. I noticed the next one. If the Hub knew about my bookings, why was I manually putting those bookings into Google Calendar? So I connected the two.

The Hub became the place where I managed the booking and Google Calendar became a copy I could still use alongside everything else in my life.

Then I added the weather because that is something I need to think about before walking dogs. Then walk reports. Then payment tracking. Then recurring bookings. Then the ability to start and finish a walk and record the actual times rather than just the scheduled ones.

Each addition has followed roughly the same rule:

What am I repeatedly doing outside the Hub that the Hub already has enough information to help me with?

Apparently I am still a project manager

There is something slightly ironic about all of this. I left digital project management and started a dog walking business. A few months later, I am standing in a park thinking about user journeys.

The difference is that I am now the user. That changes the way I have approached building it.

I am not trying to predict what a hypothetical dog walker might need. I am using it while actually running Wag & Walk.

When something irritates me three times, I start thinking about whether the system should fix it. When something takes too many taps while I am holding a lead, that is a design problem. When I am moving bookings around and worrying that I have forgotten to update something somewhere else, that is a workflow problem.

When I am travelling between dogs and need the information quickly on my phone, that is a usability problem.

The requirements are not coming from a workshop. They are coming from Tuesday afternoon.

It still does not run the business for me

This is probably the distinction I care about most. I do not want software making decisions about the dogs I look after.

It does not decide whether it is safe to walk a dog in hot weather. It does not decide whether a dog looks unwell. It does not decide how I communicate with a client. Those are my responsibility.

What I want it to do is remove as much administrative friction around those decisions as possible. Tell me what I need to know. Keep the boring things in sync. Make it harder for me to forget something.

Give me more of my attention back for the part of the business that actually matters: the dogs.

I do not know what the Hub becomes

At the moment, it is built around Wag & Walk. That is deliberate.

There are already established platforms for pet-care businesses with enormous feature lists. I am not particularly interested in trying to recreate all of them. I am interested in solving the problems I actually encounter.

Maybe eventually that produces something useful to other independent dog walkers. Maybe it remains the slightly over-engineered internal system of a dog walker who used to manage digital projects. Either outcome is fine.

For now, every time the business becomes slightly more complicated, I have an unusual advantage. I can change the software that runs alongside it.

I started Wag & Walk because I wanted to build a dog walking business. I did not expect that I would end up building the software I wanted to run it on too.