Below is an email interview I conducted with Todd Gardner. Please follow him and his company at the information below and if you are a frontend developer, take the time to explore what TrackJS offers.
- Can you tell us a little bit of your background as a developer? When did you start? What was your first language? What is your current language of a choice?
I started my career in IT operations, I was a system administrator at Toro in bloomington. I spent a lot of time automating actions and hooking up monitoring systems, which sparked my interest.
After a few years, Toro gave me the opportunity to switch into their software development group where I wrote a distributed IoT system that pulled data from ground sensors. We used C# and SQL Server, and a lot of gymnastics to make the whole thing work.
Lately, I write a lot more JavaScript than anything else. I tend to build web applications mostly, and it’s really the only option for applications in the browser. I typically write vanilla JS because it doesn’t change much, and I can pick up an old codebase and use it again. But I also dabble in React and Angular if it’s something that doesn’t need a long shelf-life.
- For those who don’t know what TrackJs is, can you provide a description of the application and its unique qualities?
TrackJS is an error monitoring service for web applications. It gives developers visibility into how well their applications behave in the hands of the users and reports errors in their code, third-party libs, or network failures. The web ecosystem is complex and asynchronous, it captures non-error events as part of error reports so that developers can understand the story of how the user got to the error.
- Where did the idea for TrackJS come from?
TrackJS is sort of the culmination of my development experience. I wrote a lot of web applications, and we always had to deal with weird errors. I would find myself creating these subsystems in my code to get better observability into behavior. In fact, I met my co-founders while building one of these systems at a local company.
After building simplistic versions of TrackJS several times for different consulting clients, we finally had the bright idea to build it on its own. I pitched my co-founders at Minnebar 2013. At the time, Eric Brandes was working on his own project, but was so excited about the idea that he dropped it and partnered with me. We hacked a demo together over a few weeks and brought it to a JavaScriptMN meetup in the old DevJam basement where we did our first pitch, and landed our first customers.
- When you set out to build the app, did you imagine the finished product to be something just for you to use, or did you always know that you wanted to release a fully realized and sellable product?
We were so naive. When we first started, the idea was that this wasn’t really a product, more of a bonus to our consulting work. If you hire us, you get all this error monitoring goodness for free! Of course, that didn’t work. That’s not really how the consulting world operates.
But as the system came together, and we talked to more people, we understood how painful this problem was, and how broadly interesting it could be.
- How many people work on it now?
Our team has taken several iterations. The initial team that I pitched was 4 people, and we didn’t even have a company yet. We just had a “shared copyright agreement” on what we wrote together, and hacked on nights and weekends. The team wasn’t quite right and we’ve said goodbye to a couple folks. The initial system was written mainly by Eric Brandes and myself, pairing together on the work.
A few months in, we welcomed Jordan Griffin to the team, and we began to specialize more into our current roles. Eric leads up the backend of the system with Jordan’s help. Jordan handles operations and making sure our systems are stable and resilient. I build the agents.
Our core team is still just 3, and we want to keep it that way. We enjoy working together and keeping our overhead low. With a smaller team, we can still move fast and focus on priorities better than other startups.
- How long did it take to get to a version of the application that you attempted to sell?
The idea was in March of 2013, we had a demo in July. Beta was in October. First sales in January.
- How many people are using your product?
Thousands, I am shocked and amazed by how many teams around the world use and love our product.
- What tools did you use to manage your tasks and stay up to date with what everyone was working on?
Haha, we get most of that for free with a 3 person team. It’s easy to talk and keep everyone up to date. We do track our work in Trello, but it’s mainly for keeping conversation together on a topic. We also have a Slack channel for less formal things.
- What percentage of development at this point is new features vs maintenance?
75% feature work I’d say. We optimize our work to keep maintenance minimal, which supports our small-team strategy.
- From an infrastructure perspective, is there anything you wish you had done differently early on? If so, what is it and why?
We started TrackJS in the cloud, relying on Platform-as-a-Service utilities to keep our code simpler. This helped us get started faster in the beginning, but it bit us in the ass. We got locked into a particular provider, and when our requirements outgrew the performance that the platform could provide, we were stuck.
2 years into our product, when we should have been refining features and investing heavily in marketing, we had to embark on a major rebuild that took us 6 months to make our code portable enough to switch providers.
I have a sour experience with PaaS to this day, I’m skeptical it’s worth the tradeoff for anything non-trivial. Especially when you consider the infrastructure isolation and automation options that we have today.
- As one of the primary engineers on small team, do you feel any amount of stress associated with wide and growing adoption of your product?
- If so how do you deal with that stress?
Oh hell yes. Building your our thing is a manifestation of all our decisions about software that people can look at and criticize. When someone doesn’t like it, it’s hard not to take it personally. I stress about performance and customers and growth all the time. You have to have thick skin to do this. To be able to take criticism, and distill it down to something meaningful, or realize that our product isn’t for everyone.
People want different things and prioritize different aspects of their tools. At TrackJS, we’ve prioritized simplicity and intuition to the detriment of integration and configurability. That means that any web developers can use TrackJS with no training and understand the impact and context of errors. But you can’t build custom dashboards or run complex queries. Life is about choices.
Handling the stress gets easier. We’ve got a pretty successful product today, so losing a customer or getting bad feedback doesn’t crush me like it once did. There is more to life than software, and it’s important to remember that things outside our computers are a lot more important.
- Where can everyone find more information about you, your product and your company?
Everything you need to know about TrackJS you can find at TrackJS.com. I occasionally have witty things to say on twitter, I’m @toddhgardner.
MNDevs.com 