Part 3: The Deciding Deep Dive
Our final chapter in shutting down a company and starting it right back up.
In my previous two blogposts, I’ve covered how Dmitry Fink and I had shut down our startup and then described our efforts to reboot with the remaining capital. The last blogpost ended with:
“One of the azimuths we explored was the specific challenges we had faced at our first company. We looked at the actual pains we had experienced and studied potential solutions. One of these deep dives led us to build Bugsee.”
This is my third and last post in the Pulp Fiction themed restart trilogy.
The final stretch of the journey
The mobile apps at our previous venture had bugs. These bugs caused a range of unexpected behaviors, such as a broken animation, a mispeled [sic] text, a missing image or a counter-intuitive UI.
Reporting these bugs to our dev team was often a challenge. So Dmitry and I tried to recall our typical flow.
Once I saw a bug on my latest version of the app, I would first take a screenshot. Quite useless in the case of a sloppy UI transition, but what else could I do?
Then I’d attempt to reproduce the steps leading up to the problem. Of course, the intermittent bugs were often impossible to recreate. How could I know that clicking on a specific icon four screens ago caused this problem? What if the problem was caused by a temporary connection loss?
Then I would email our dev team with the pieces of collected data. While some issues were easy to describe, others were too complex to be put in words. You just had to be there.
Then the dev team would come back with tons of additional questions — Which build? The one from yesterday or today’s AM? Which iOS? Was the phone on WiFi or 3G? What did you do right before you got that screen?
As some of our developers were in a different time zone, these back-n-forth emails would sometimes take several days. Often we’d get to the bottom of the problem, but sometimes we would end with “well, just put it in Jira, we’ll be watching for it”. There simply wasn’t enough info to root cause the issue.
On top of that, our production apps also crashed on occasion. The reported call stack wasn’t always sufficient to understand the condition that caused the crash. So we faced a similar conundrum. What exactly did the user do to get to that particular case? What else the system was doing at the same time? The historical context was crucial in some difficult crash cases.
Next steps
Dmitry and I first asked ourselves, how could we backtrace what had led to those rare bugs? How does one report a problem with all the contextual and historic data, without even leaving the app? How can we shorten the time it takes the developer to reach that a-ha moment when looking at the report?
Then we tried to answer our own questions.
We needed an all-encompassing bug and crash reporting mechanism. It had to continuously record (and store locally) all app screens, touch events and all network traffic. This way, if a problem occurs, everything has already been recorded. So there is no need to reproduce the problematic sequence.
Which resembled a flight data recorder, aka the plane’s black box.
We could totally see ourselves using such a system if it were to exist. So we started researching the space. Many tools have solutions for debugging issues on the backend. But when it came to debugging and analyzing the front end — there were no complete solutions. That was surprising to us, considering how much effort is spent today on polishing the user experience and app UI.
Competitive analysis showed that there are two big players in the space of crash reporting and several small players offer some subset of in-app bug reporting functionality. None of them had a comprehensive offering, none offered a quality video that wouldn’t slow down the app UI while being App-Store-safe. No one also offered detailed network logging synced to the video.
We ran an initial feasibility study and built a functional iOS prototype to showcase to potential customers and to our investors. We showed it to the developers in our network and got a unanimous feedback that all of them wished they had it as part of their workflow.
OK, we can see ourselves using it, we got initial validation and have a working prototype. Next we needed to research the space of developer tools. We needed to scope the size of the market and its trends. As Atlassian (maker of Jira) filed their S1 last year, Goldman Sachs fortuitously assisted us with our research.
We met with all our previous investors, showed them the demo and the deck with all the collected feedback. It took us some time to answer all their questions, but we did get their necessary commitments.
Continuing the marriage analogy from previous post… due to the apparent butterflies in the stomach feeling, we knew we had finally found our the one. Dmitry and I looked at each other and shook hands over our renewed vows to the new project.
New Years break was just around the corner, which was perfect for a “bachelor getaway” before getting into a long term relationship with our new venture…
Legal
During the New Years break, we started to deal with the legal aspects of transitioning one company into another. It was a fascinating challenge and a fun exercise with our talented attorney.
We had to address the following:
- We needed to move the leftover cash from the previous company.
- We had to rebalance founders equity, as our original split between Dmitry and I was based on no longer relevant assumptions. Plus, we needed to reset our vesting.
- Our previous company had many paid customers. While the risk was small, we did not want to drag along past liabilities to the new venture.
There were two obvious options. One was just to rename the company. Solved the moving-the-cash problem, but didn’t address anything else. On the other end of the spectrum was — close the first company, return the money to investors and fund a totally new company a minute later. Clearly solved all the issues.
Yet, there was one tiny complication — the logistical nightmare of returning every investor their piece of the remaining capital and then collecting it back. When we modeled everything, including accounting for the two priced rounds we had in the previous company, it became apparent we needed a simpler way to handle it.
We had to find a solution that was in between these two extremes. I won’t go into the details here. Not because it’s a secret, but rather because explaining all the details here requires a review from our a legal. And it’s not the best use of our lawyer. However, if you’re ever in a similar situation, feel free to reach out, happy to share our experience and thought process.
Bugsee — you know, like “see the bug”
And that’s how Bugsee was born in January 2016. Following Paul Graham’s advice, we secured bugsee.com.
We launched our public beta in late April. So far our X Factor is at 920 companies with 1,300 developers signed up to try Bugsee. We plan to roll out our pricing by the end of November. Bugsee is free until then. Check out Bugsee demo account and documentation, so you too can see what’s the fuss all about.
Epilogue
Perhaps the most difficult part of the restarting journey was probably lack of tangible deliverables. Throughout our entire careers, Dmitry and I used to build things. And now, for the past several months, every Friday we’d look back at the past week and what did we do? We had been only thinking, googling and excelling (Microsoft kind)…
Thank you for reading our story. I hope it can help someone in the startup ecosystem. It’s our way of paying back to the community for everything we’ve learned from others. If you ever in a similar situation or just have a question — feel free to reach out. More than happy to connect.
Alex Fishman is a Founder/CEO of Bugsee — a debugging tool for developers. Bugsee lets developers watch videos leading up to crashes and bugs. Check out Bugsee explainer videos for iOS and Android and Web, or our Demo.
