Building for Our Own Needs: A Tale of Two Tools
Developers don’t want to solve problems. It’s really as simple as that. Unless the problem you’re solving is contributing directly to your business’s value proposition and is also one of your core competencies, you’re better off finding a tool or library that will do it for you.
That’s why, when we needed user tracking and error reporting for our big, complex real estate web app, NowRenting, we were disappointed to find that nothing out there seemed to fit the bill. We kept on finding ourselves writing code to address needs that it felt like would be common to many web apps, and could all be addressed by the same type of technology. We needed to:
- See what our users were doing
- Find and reproduce bugs
- Manage suspicious visitors
And we needed something that was plug and play, like a JavaScript library — include it, configure it, and it just goes.
It turns out that the fundamental technological solution — basically, to run a particular little bit of code on the end user’s browser — was in use pretty widely by other tools. But none of them had the feature set we needed, and none of them lived up to the simplicity and ease of use we expected.
So we built Hawk.
It’s surprising how easy it was to integrate Hawk into our regular NowRenting workflow. (You’ve got to eat your own dog food, after all!) Developers will reach for the easiest tool at hand — we don’t want to solve problems, remember — and Hawk quickly became that tool, even in its earliest stages.
When it’s a choice between, on the one hand, setting up your local development environment to exactly emulate a user’s state when an error occurred and, on the other, pulling up the Hawk error report, it’s an easy choice. The Hawk report is going to be not only quicker, but more accurate — because Hawk had code running on the end user’s browser at the time the error happened. It was right there, watching.
So we’ve found that when we’re working on diagnosing a bug, it’s by far the quickest way to get the information we need, and that’s true whether it’s a bug we have a user support ticket about, or something Hawk itself alerted us to.
One feature we had decided on from the very beginning was the Trello integration, because Trello is such an essential part of our workday. We’re already using Trello cards to track errors, we thought. Why not have Hawk send errors directly to Trello? It was fun to see those first few reports appear on our Development board — almost like our app itself was talking to us.
It’s been an interesting journey. We’ve found that being our own customer is a really good motivator. And we’re building some features now that we hadn’t even thought of during the original design phase: NowRenting will have a need, and we’ll say, “Oh! We could just build that into Hawk!”
We’re at the stage right now where early customer feedback is really valuable, and we designed our pricing to reflect that. Both the free plan and the 7-day trial period include all the same features as the full paid plan (the free plan throttles concurrent user sessions). If you’re a web developer, we hope you’ll consider giving it a try!
