As I wrote in From Business Guy to Programmer back in April 2012, I wanted to shake up the business guy persona I had and contribute to the codebase of whatever my next project would be. I thought I'd share with you in brief the story of how in only one year I learned to code, started a company, and sold it.
The background
Throughout 2012 people have asked me what sparked my interest in wanted to learn to program and how it all came to be. I looked them in the eye and told them "it all started when I was on heavy painkillers lying in bed recovering from a tonsillectomy." For those of you who've had a tonsillectomy later in life, you know the awful feeling of helplessness, and for those of you who haven't, it's basically ten days of misery where you can't think, eat, drink or do anything for yourself. It's awful.
Somehow through the mind-numbing painkillers, I arrived at the epiphany that something in my professional life had to change. My tonsillectomy brought about the realization that I was tired of having to rely on other people. For ten days straight it was "mom" this and "dad" that. I felt out of control because there were simply things I couldn't do while laid up in bed. I knew what I had to do, but couldn't do it.
If you can program, you can push through the pain and build (almost) anything you can imagine without relying on other people. That's what I wanted. Not having to rely on other people was the key for me. I wanted to be able to take any idea I had on paper and turn it into a working prototype.
While recovering from that surgery, I had the idea of building an Application Tracking System (i.e. a "recruiting app"). Part of the reason for this was that the product and technology seemed fairly simple. I'd tried a lot of them during my days at Carbonmade and they were all terrible. It also felt like a great entry point into Human Resources, which is something I've always had my eye on getting involved with. I texted my friend of many years, Yaron Schoen, to see whether he'd be interested in building a product together. He said he was.
A quick prototype in two months
As soon as I recovered and made it back to NYC, I met up with Yaron and we talked a bit about what we'd make. We'd both used the available recruiting apps and we both agreed that they're terrible, that it seemed as though no product people worked on them, and that none of them were well designed. We knew that with a little effort we'd be able to come up with something way better.
But I needed to learn to program. So in February I jumped in (check out the Programming Resources I used). It took about two to three weeks to get the basic Ruby and Ruby on Rails syntax down. Not anything too complicated at that point, just being able to make a basic sign-up form, password reset, user pages, user system, platform for comments, and other steps for building a basic CRUD app.
Yaron was a bit surprised that I felt capable of starting on a basic prototype by the end of February — how can you blame him? I was visiting a friend in San Francisco for two weeks in March rather than going to SXSW that year, and felt as if we could get something stable enough out the door by the end of my visit.
By the end of March, we'd built what we thought was a usable first prototype for a recruiting app. I showed it to a dozen friends in early April and we had half a dozen using it immediately. They loved it. We didn't think it was all that great, though, and quickly got back to work on a new version of the product that would ultimately be the one we'd sell eight months later.
From prototype to reasonably decent software
With a half dozen active companies using our little piece of software, we felt confident enough to carry it over to the next phase. If you can't prove enough demand with a prototype then you should build a new prototype. Luckily, we had the demand to keep going.
Not only did we re-design it completely, but I also decided to start over with the codebase. I used what I'd learned over the first two to three months programming the prototype to build something a lot closer to Ruby on Rails conventions. As you learn more and more coding, you look back at how you did things only a few months earlier and laugh. Some of my code was that bad.
By July, we had completed the new version of what was formally known as Uncover and released it to our userbase. They loved it. We'd fixed all of the annoying bugs and idiosyncrasies, added new features, and had a handful of very appreciative users. We then went out and got another dozen companies (Harvest, Skillshare, WooThemes, SeatGeek, etc.) onboard to use our new software.
It went really well, and although there were still plenty of kinks in the software, it was better than anything else that was in the market. While our competition seemed to be focused on their app being able to do everything, we wanted to keep it minimal, clean and consistent. I think we accomplished this — and by the end of August, too.
Going after the bigger picture
Early on in our process, we already had higher aspirations for Uncover, however. From the beginning, we wanted it to be more than just a recruiting app. We wanted to cover the employee side of human resources. Yaron and I have always been fascinated by how employees are treated, the limited information they have access to, the terrible tools they have for managing their employment, and a lot more. We think there are a lot of more interesting challenges connected with existing employees than there are for people looking for work and recruiting.
As a simple thought exercise: if you're a company of fifty people, do you care more about the fifty people currently working for you or the next person you're looking to hire? As an employer you obviously care more about the people you have on staff already, and so did Yaron and I. We felt that if we could take the recruiting app we'd built and make it the pipeline into the greater employer/employee app that we wanted it to be, then we could be satisfied.
In October, we decided that we'd do some sketches and some prototyping around what we were more interested in: post-employment life rather than pre-employment life. We got a ton of interest — not only from company CEOs, but employees to whom we showed our app, and from investors too. But what was consistently getting in our way was that the world of pre-employed people and post-employed people is so drastically different. It doesn't make a lot of sense as one app. People just didn't get it as an app that bridged the two worlds, and neither did we.
So why did you sell?
I strongly believe that you can, and should, only focus on one thing at a time, something specific. We could have ventured down the recruiting app rabbit hole with fifteen awesome active companies (we hadn't yet tried for more) loving our product, but it's a small market, heavily dependent on sales, and there's a ton of competition.
All of these cautionary factors — apart from the small market one — Yaron and I were comfortable with, but to be perfectly honest, recruiting is just not that interesting. It's not intellectually challenging and both of us have reached a point in our lives that we're interested in bigger conquests. We're really looking to change lives, maybe change millions of lives.
So we got together, talked it out, welcomed Mike and Jason to the team, and decided to sell what we were then calling Uncover (now HireTracking) so that we could focus on our employer/employee app. (More on the new Uncover soon.)
It has been the biggest relief during the last year of my life to focus on a single problem rather than what we thought was a single problem but was really two distinct problems (pre vs. post). We've become razor focused, and we're producing higher quality work at a faster rate than ever before. I'm really looking forward to showing you what we've built.
For now I'll just say, though, don't get caught up in what you originally built, but focus instead on what it can point toward.