4
3 Comments

I Inherited a Failed Startup. Here's How I'm Turning it Around.

Hello! Please tell us about yourself and what you're working on.

I am the CEO, Chief Everything Officer of Handle, Kris Gellci. I grew up and went to school in the metro Detroit area, and my background is in software engineering (specifically, iOS). Aside from engineering, I spent 2 years working at an inner city middle school in Detroit. This was an eye opening experience when it comes to the education system and the disadvantage inner city schools have over schools in the suburbs.

I moved to San Francisco in August of 2014 to work on Handle. Coming from a large company where I received at least 200 emails per day, the struggle to keep things organized was real for me. When Shawn Carolan, the founder of Handle, showed me an early version of the product, it instantly clicked for me.

Handle combines your to-do list, inbox, and calendar. The single feature that impacted my decision to join was taking an email out of the inbox and putting it on your to-do list. We have all hacked email in different ways to come close to this behavior, marking unread, flagging, applying labels, etc. People's struggles to keep their inboxes organized is a real one, and when Shawn opened Pandora's box and introduced me to Handle, I was blown away.

Currently you're running Handle on your own, but it wasn't always this way. What were things like when you joined?

I joined Handle as a software engineer pre-launch. Leaving family and friends in Detroit was not an easy decision. Moving to a new area, especially as expensive as San Francisco, was the most difficult thing I had done in my life so far.

When I joined, Handle had just recently raised an A round, almost $10 million total. The team was large, about 15-20 employees. In early stage VC-funded Bay Area startups, the goal is explosive growth. You value the company based on perfection and thus swing as hard as you can for the fences to nail it. The interest is in a company that goes from seed to world domination and $billion+ valuation in a short period of time. We swung for the fences as hard as we could.

We had an explosive release in the App Store, and in the first week we had over 100k downloads on iOS alone. Although the launch was really strong, through a mix of missing features and UX issues, we were quickly shedding all of the new users. Our growth and retention were not good, and we needed to scramble and regroup.

Initial Post-Launch Downloads

With such a large team of engineers and designers in San Francisco, we had a high burn rate. Salaries and other expenses were totaling hundreds of thousands of dollars per month, yes, per month. We were running out of money fast, and we had to make the hard decision to cut the team almost in half. I had been at Handle for less than a year at this point, and this was my first ever experience with layoffs. It was surreal, but when the dust settled, I was still a part of the team.

How did you end up running the company by yourself?

Although we had slimmed Handle down to 7-10 people, we still maintained the structure and overhead of a 15-20 person team, and our process was eating up development time. In retrospect, we should have been more scrappy and thinned the team to 5 people max.

Once the bank account really started to run low, we looked for acquisition opportunities and found several. The day the team separated and the company had 0 employees was the day we turned down a large acquisition offer from a multi-billion dollar company. It was an acquihire which required most of the employees to join the new company. Unfortunately, we decided as a team not to go this route.

Fast forward a few months: I'm working at Glassdoor on their iOS application. Shawn comes to me with an opportunity: quit Glassdoor, take over Handle, do what you think should be done to turn it around, and get full control of the assets, bank account, legal decisions, code base, etc. The catch? If you want to pay yourself a salary, figure out how to make the business succeed.

I struggled with this decision for almost 5 whole minutes, but in the end it was simple. Looking at every possible metric, this was a bad idea financially for myself and my girlfriend. I was pretty much guaranteed to burn through most of my savings. Taking all of this into account, I asked myself if I would regret not following this path, the answer was 100% yes, and thus I took the plunge.

What's it like inheriting a big codebase and existing business as a solo developer? And what's your tech stack?

Handle is one of the largest mobile apps I have ever worked on. Built into a single application is an email client, a fully featured to-do list, and a calendar system. Just one of these alone would be a big application. Because of the complexity of the code and myself being the only person working on Handle, I have had to make some tough choices.

I decided right off the bat that I could not support both web and iOS as the only developer. Most of the users are on iOS and my expertise is iOS, so I decided the main focus for growth and monetization would be on the iOS side. I am investing my time implementing features which I think would lead to organic growth, higher retention, and would not impact the web flow in any negative aspect.

Handle, being on iOS and web, uses a variety of services. The two large ones are Firebase and Heroku. Firebase is mainly used for storage of to-dos while Heroku is used for authentication and analytics. I further rely on Mixpanel and Fabric for analytics. (Mixpanel is actually fairly expensive at this point, so I'll likely migrate to Google Analytics.) I've had to hold off on these sorts of chores since they provide almost no value to short-term growth. Extensive analytics are of course very useful for long-term planning and growth.

You've got lots of competitors in the productivity space. What's your strategy for cutting through the noise and growing Handle?

Competition is fierce in the productivity space. One benefit to being a single employee is that I can take user feedback and current trends into account and quickly decide what features to build. I have received feedback and implemented features all in the same day, usually very difficult to do when part of a larger team. Being the product owner and the developer, it is much easier to estimate the return on investment for every feature I work on.

The strategy so far has been to work on new features centered around the to-do list. My focus is on making planning and organization as quick and easy as possible. I immediately post features I am working on to Twitter, Reddit, LinkedIn, etc. The best way to get feedback is to post features in gif or video form. I use this as a way to drum up support, while gathering feedback on features I am building before shipping them.

This strategy has worked so far. I took over Handle full-time on October 25, 2016. At that point it was shedding users on a weekly basis. Since then it has grown from 12.8k monthly active users to 20.5k. I have spent $0 on marketing to achieve this growth. Instead, I focus on spreading the Handle message via social media platforms. Lifehacker has written two articles about Handle since I took over, and Apple featured Handle under the "Enhanced for 3D touch" section on the featured page of the App Store.

Growth in Monthly Active Users

While an increase in new users is great, you need to retain those users if you plan on increasing and maintaining active users. To increase retention, I built a planning tool into Handle. The to-do list in any app falls apart the minute the user decides not to work on the to-dos they've scheduled. They end up with a behemoth list filled with commitments they have missed — a very discouraging thing to open and work off of every day.

The planning feature consists of individual tools which allow users to quickly plan their day without the overload of a huge abandoned list of commitments. It is built after observing users who rely on pencil-and-paper to-do lists. They start with a blank page every day and copy over any important unfinished items from the previous day. The planning tool in Handle takes this process and makes it more efficient, helping users ditch their pencil-and-paper approach.

I have also been working on a feature which will be a great growth catalyst. So far users have had no incentive to invite others, and the organic growth from within the app has been almost non-existent. That's where shared lists come in. Users who rely on Handle to manage their life can now collaborate with others on projects, chores, vacations, etc. This is the first feature in Handle which provides a strong path for organic growth.

I launched this feature on January 19, 2017, and I used all of my social media channels as well as the mailing list of all current Handle users to let them know about it. Sending thoughtful updates helps bring back users who have stopped using Handle.

What's the story behind your revenue? How have you monetized Handle?

Back when I first joined the team we hadn't yet set up a monetization structure, and it stayed that way for a while. We eventually set up a subscription service test to see how much users would pay. The subscription service was only visible on the web, and thus a very small number of users saw the paywall. Most customers could still use the product without paying.

The results for this small test were interesting. During the beginning of the test, revenue was about $600-$700/mo. Currently the revenue is at about $300-$400/mo, but here is the kicker: the subscription service back-end has been shut down for the last 8 months. Users would input their credit card info and attempt to pay, but we would never actually collect their payment info or charge them. The revenue coming in now is from users who started paying almost a year ago and have not canceled the service.

Handle absolutely needs to increase revenue in the future. I am not drawing a salary from the company, and I can only sustain myself from savings for a little while longer. Handle itself costs about $1k/mo to operate with 0 employees. My goal for the next few months is to really accelerate growth with features like shared lists while finally implementing a subscription model in the iOS app.

There is a fine balance between growth and revenue. I could put up a paywall and force users to either pay or lose access, but I do not feel that this is the right way for both future growth and keeping existing users. While many users who love the app would surely pay, it is not fair to take away from users who have invested so much time into Handle. The current user base is so passionate about Handle that I am confident a subscription model without locking unpaid users out is the right way to go. This will be the best way to avoid stunting growth while giving users the opportunity to support the future development of Handle.

As revenue increases and I am able to hire a few more developers, it will be much easier to implement features that current users are requesting. Getting Handle to cash flow positive is crucial for 2017. To put this into numbers, the goal is to get to $15k monthly recurring revenue within the next 3 months.

What are the biggest lessons you've learned so far? If you had to start over, what would you do differently?

One thing I experienced quickly while running Handle full-time was guilt. I work as many hours per day as I can, even on weekends, but some days I feel immense guilt when I don't finish my to-do list for the day. This was something I had not experienced working at any other company. On days where I have to spend time doing anything other than writing code, I feel like I have wasted time. When I am working on creating assets, marketing materials, or writing blog posts for Handle, I feel guilty that I am not, instead, writing code.

I quickly learned that the time I spend on growth is worth it in the end. Although I am still unable to shed the guilt of not writing code, without generating excitement for Handle, Lifehacker would not have written about it, Apple would not have featured it, and people will not discover it. Building a product is only half the battle, the other half is getting users. Having a $0 budget for marketing, I am relying on as much free press and marketing as possible.

At the end of the day, I have to keep myself productive. There are days which are huge ups and I am unable to stop working on code, from morning until late at night. There are also days where I have to force myself to finish features and get the most out of the day.

I do actually use Handle to keep myself true to my commitments. Part of what is driving the features in Handle is what I think will make me more productive so I can get more work done.

What's your advice for aspiring indie hackers?

When building mobile software, I have seen that tight iterations and release cycles are crucial, especially for a small startup. I have a large number of beta users made up of the most active Handle users. I ship features to them every few days, and I gather feedback via a Facebook group. Afterwards, I feel confident that the features I am shipping will have a positive impact on growth and retention as well as minimal new bugs. As a single developer moving fast, the beta group is an amazing resource.

One book which has helped me in this journey is Growth Hacker Marketing by Ryan Holiday. The book has great examples of growth hacking used by large successful companies. While I have not employed any of the same strategies, it has helped put me in the right mindset when it comes to marketing on a $0 budget. The book is also short, which really helps when you would rather spend time writing code.

Where can we go to learn more?

If you are interested in following me on my journey: Medium, Twitter, and also feel free to connect on LinkedIn.

Whatever your goal may be, Handle will help you reach it: iOS, Chrome, handle.com.

  1. 1

    You talked about guilt when working on non-coding tasks and also about ensuring you stay productive when doing these non-coding tasks. What sort of methods you use to set goals and then track productivity for these other tasks?

    I, as a developer, find easy to set goals and track progress for coding tasks. However, I'm uncertain how to do the same when wading through non-coding tasks.

    1. 1

      I will usually use the pomodoro technique on whatever task I am working on. 25 min of work + 5 min break. Coding or not, I usually have some sort of idea of what the maximum time I want to spend on a task is.

      The important part is deciding what to do if a task takes longer than you think it should take. Some tasks need to get done no matter what but some tasks can be left unfinished. If I think a task should only take me 25 min but at the 25 min mark, I am not even close to finishing it, I may just ditch it all together, losing 25 min is better than losing the whole day. This applies to both coding and non coding tasks. If I spend 25 min investigating a bug and find that I am nowhere near tracking it down, I may just table it and never fix it, If it becomes more serious, I revisit.

  2. 1

    This comment was deleted 3 years ago

    1. 1

      There will be features I implement later on which will be only for users that support Handle via subscription. Email search / email bulk triage would be under that umbrella. I have to make sure that features I lock under that plan work perfectly. Users are willing to accept flaws when supporting an application, once a user pays money because they want to unlock a feature, that feature better work with 0 flaws :)

      The plan is to offer users subscription as a way to support something they like, eventually new features which do not directly impact growth will only be available to those users.