1,008 views
We get asked a lot about how features like Reporting & Analytics Dashboard actually come together, so here’s the honest version — including the parts that didn’t work the first time.
Where it started
Reporting & Analytics Dashboard pulls bookings, revenue, and client activity into one dashboard instead of manual spreadsheet tallies. That sounds simple to describe, but building it meant sitting down with working pet sitters and dog walkers and watching how they actually run a day, not how we assumed they did from the outside. A lot of software gets built from a whiteboard session and a set of assumptions about what a “typical” small business owner needs. We tried to build this one from actual observation instead.
I spent time going through my own operational history at Scritches first — pulling up old spreadsheets, remembering which numbers I actually checked regularly versus which ones I told myself I should check but never did — before we ever wrote a line of the dashboard’s code. That gave us a starting hypothesis, but it was one business’s experience, so we spent real time validating it against other pet business owners before committing to a direction.
What changed along the way
Early versions were more complicated than they needed to be. The first internal prototype had close to a dozen different report views, configurable date ranges for every single metric, and a settings panel that took real effort to navigate. It looked impressive in an internal demo. When we put it in front of actual pet sitters, most of them used exactly two of the views and ignored the rest entirely.
The version that shipped is simpler because we cut anything that didn’t directly save a sitter time or reduce a mistake. That’s a harder discipline than it sounds — it’s tempting to keep a feature “just in case someone wants it,” but every extra option is also extra cognitive load for someone who just wants to glance at their numbers and get back to running their business. We ended up removing roughly two-thirds of what the first prototype included.
A specific example of a decision we reversed
One early design let owners fully customize which metrics appeared on their main dashboard view, arranging widgets however they wanted. It sounded like a good idea — more control is usually better, right? In practice, it meant every new user faced a blank, uncustomized dashboard on day one and had to make several decisions before it showed them anything useful at all. We reversed this and shipped with a fixed, sensible default view instead, based on what came up most often in conversations with working owners. Customization is still something we’re considering for a future version, but only as an addition to a good default, not as a replacement for one.
Why it’s part of OPERATE
Every feature we build for OPERATE stays free forever — this one included. There’s no upsell tier waiting behind it, no “basic view is free but the real insights cost extra” structure. That decision shapes how we build things from the start, because it means we’re not trying to hold back functionality to create upgrade pressure. The dashboard is exactly as complete as we believe it should be for every user, not artificially limited to protect a paid tier.
How the testing process actually worked
Reporting & Analytics Dashboard went through several rounds of internal testing and direct feedback from working pet sitters before shipping, since the difference between a feature that looks good in a demo and one that survives a chaotic Monday morning is entirely in the details. We prioritized reliability and simplicity over adding every possible option, since most owners want something that just works without a learning curve.
Testing wasn’t a single formal round — it was closer to a rolling process where a small group of pet business owners used early versions during their actual work weeks and reported back what confused them, what they ignored, and what they wished existed. That kind of real-usage feedback caught problems that internal testing never would have, because internal testers already know how the feature is supposed to work and unconsciously use it “correctly.” Real owners, mid-workday, use things the way they actually think, which is a much better stress test.
What surprised us during development
One thing that surprised the team: owners cared more about seeing trends over time than about seeing precise numbers for a single day. We initially built the dashboard to emphasize today’s snapshot — bookings today, revenue today — and had to shift the emphasis toward week-over-week and month-over-month comparisons once we saw how people actually wanted to use it. A single day’s number in isolation rarely tells an owner anything actionable; the trend is what actually drives a decision.
Feedback from the pet sitter community continues to shape this
Feedback from the pet sitter community directly shaped several decisions along the way, and that process continues as we refine it further. This isn’t a feature we consider “finished” in the sense of being locked in permanently — it’s a living part of OPERATE that we expect to keep adjusting as we learn more about how different kinds of pet businesses actually use their numbers day to day.
If you’re using OPERATE and have thoughts on what’s missing or what doesn’t quite work the way you’d expect, that feedback genuinely goes somewhere. Several existing pieces of the dashboard exist specifically because an owner using an early version told us what they needed, not because we guessed correctly on the first try.
What we’d do differently if we started over
With hindsight, we’d have gone straight to talking with a broader range of pet business owners before building the first internal prototype, rather than starting from my own Scritches experience and validating outward from there. That approach worked, but it meant the first prototype carried some assumptions specific to a pet sitting and dog walking business that didn’t map as cleanly onto other kinds of pet businesses we later heard from — grooming operations, for example, or boarding facilities with different booking patterns.
None of that required a full rebuild, but it did mean a round of adjustments after launch that could have happened earlier if we’d cast a wider net from the start. It’s a reasonable trade-off for shipping faster, but worth being honest about.
Questions we get asked about the build process
How long did this feature take to build? From the first internal prototype to the version that shipped, several months, including multiple rounds of feedback and a significant simplification pass partway through.
Do you test with real business data or sample data? Both. Early internal testing used sample data to work out the basic mechanics, but the rounds that actually shaped the final design used real, working pet business owners looking at their own live numbers.
Will this dashboard keep changing, or is it done? It will keep changing. We treat every OPERATE feature as a living part of the product rather than something that ships once and stays frozen.
The role my own operational background played
Twenty years in policing before running a pet business taught me to distrust my own first assumption about what “obviously” matters, which turned out to be useful discipline while building this feature. It’s easy, when you’ve run one business for years, to assume your own instincts generalize to every pet business owner. They don’t always. Some of the most useful moments in building this dashboard came from a pet business owner telling us, politely, that something we thought was an obvious priority wasn’t how they actually thought about their own numbers at all.
Why we talk about this publicly at all
Most software companies don’t publish the messy version of how a feature got built — the wrong turns, the reversed decisions, the assumptions that didn’t hold up. We think that’s a missed opportunity, partly because it’s more useful to other pet business owners who are curious about how their tools actually get made, and partly because it holds us accountable to keep building this way rather than defaulting to guesswork once nobody’s watching.
It also means the next feature we build gets the same treatment — real conversations with working owners before assumptions get locked into code, a willingness to cut something that isn’t earning its place, and a public account of the process rather than a polished story that skips the parts where we got it wrong the first time.
That’s a slower way to build software, but it’s the only way we know of that consistently produces features people actually keep using six months after launch, instead of features that generate a nice announcement and then quietly go unused.
If you want a specific example of that pattern in practice, Automated Reminders — another OPERATE feature — went through a similar cycle: a first version built from my own operational experience, real feedback from working owners, and a simpler final product than the one we originally sketched out.
Curious how Reporting & Analytics Dashboard could work for your business? See what’s included in OPERATE.
