Growing an Interviewing Platform for Programmers to $170k/mo

Hello! What's your background, and what are you working on?

Hi, I'm Vincent Woo, founder of CoderPad — a platform for conducting interviews with programmers through a web browser. I'm 28 and from the California Bay Area. I studied computer science in college, and until I started CoderPad I was a pretty normal programmer at a few different companies.

That doesn't mean I liked it, though. I never really enjoyed school. Being an employee was better than being a student, but not by a lot.

I had a particularly tedious couple of years at Amazon and Google. Abstractly, I'd known for a long time that adults could be petty, shortsighted, and lazy. Something about being exposed to adults like that every single day mutated that abstraction into corporate resentment.

I outright refused to read any of my performance reviews, which was fine because I figured I knew what they said anyway. I wasn't a good employee, and I knew it.

I'm telling you this because I believe that my attitude towards being an employee has definitely colored my approach to building a business. CoderPad, a small business, makes money by providing a valuable service to much larger companies, like the ones I used to hate working for. Yes, the irony is not lost on me.

CoderPad's product is a high-fidelity environment for interviewing programmers, enhanced with code execution, debugging, and stack traces. We sell this tool to companies that are hiring a lot of programmers. Today we have three full-time employees (besides me) and have over $2M in annual recurring revenue booked.

What motivated you to get started with CoderPad?

CoderPad started as a side project while I was still working a day job at Everlane (the first and only job I have enjoyed). I was interviewing a bunch of candidates and kept getting into situations where I wanted to see how a candidate would figure something out.

One asked me if a certain Ruby object supported the .map operation, and I wanted to say, "Just try it!" The problem was, we were using some old-school shared text editor like Collabedit which didn't support advanced features like that.

I thought this was ridiculous, so I tried to buy a product that would do what I wanted: provide a real-time execution environment alongside a synchronized text editor. To my surprise, I couldn't find any. I thought that it couldn't be too hard to build, so I hacked a Ruby-only prototype together in a weekend.

Once I started using it to interview candidates at Everlane, it seemed pretty obvious to me that I could sell this to other people — it was providing an obvious balm to a stressful experience. I also happened to be casually interviewing at other companies for fun, so I rebuilt the prototype and started seeing if my interviewers liked it, too. They often did, which I took as a sign that it was the right time for the idea.

What went into building the initial product?

CoderPad was initially built on nights and weekends because of my day job. The version I first shipped to customers took about three months to build. This part is hazy in my memory because it was so long ago and also because I think I was just having fun. I was kind of indifferent to the notion of whether the business would succeed or not, so this phase of development seemed like just another side project.

I sort of knew that the business would work, but it didn't feel emotionally real, yet. The company became more "real" once I hit $4,000 in monthly recurring revenue, at which point I quit my job to go full-time on CoderPad.

Make something that other people want more than the money they already have in their wallet. Everything else seems pretty negotiable.

I made the unusually bad decision of building the first prototype of CoderPad's website in Node. I don't normally make terrible development decisions, but this was definitely the worst. I rewrote my mistake in Rails soon after I discovered how slow web development with Node was going to be. Luckily, we have a much more fruitful relationship with Node as an API server for code execution now.

That's sort of the nature of trying to bootstrap a software business, though. You want to go as fast as possible by reinventing as few wheels as possible, but you always have nagging doubts about the library or framework you're using being not quite... right.

For instance, I used the Devise library for user authentication because it seemed to be the de facto standard at the time. I've of course since discovered that it is, in fact, terrible. We would have gained a lot of velocity by choosing a better library at the outset, but now that we've chosen, we'd lose velocity by switching. Such is life.

Initially we outsourced code evaluation to a third-party service, but this was a bit uncomfortable. They offered only rudimentary code evaluation and couldn't provide anything like the real-time REPL interaction I wanted CoderPad to have.

Nowadays, we have a fairly elaborate service built out for sandboxing user code with Docker and a bunch of isolated compute nodes, which lets us do many interesting tricky things. For instance, we let users freeze the state of a MySQL server to run queries against later.

We've also had to learn how to run a couple dozen different programming languages and at least passably debug problems in all of them, which has been edifying. Haskell remains mysterious to me.

How have you attracted users and grown CoderPad?

Our initial users came from me personally selling the idea to people I had met. We did a little bit of online exposure on HN and Product Hunt, but it didn't do much for us. Traffic sort of built up organically after a while.

We perhaps benefit from a bit of natural virality. I've definitely heard stories of candidates introducing other companies to CoderPad because they prefer to be interviewed on our platform instead of, say, Google Docs.

Month Customers 5/13 14679 10/13 2974 5/14 11777 10/14 19013 5/15 42834 10/15 68049 5/16 71185 10/16 95834 5/17 96916 10/17 159596

We also focused on sales early on, so a lot of our leads ended up converting. A high school friend, Darius, began helping me with sales, and one day surprised me by quitting his rather lucrative job to join CoderPad full-time.

Learning about sales was a wild ride and quite a lot of fun. Sales is, in a lot of ways, a modern-day Turing test for humans. You have to communicate clearly, humanize yourself, focus on the customer's needs, and ultimately land the sale. You have a very limited medium for this — usually emails and phone calls. It's one thing to say that you care about customers and another thing entirely to actually pay attention to everything that they say during calls.

It was very useful for us to go over recordings of sales calls we had done and look for moments where we confused the customer or forgot to ask important questions. A recurring problem we had is that customers usually wouldn't flat-out say, "I don't understand." If we answered someone's question badly, they'd usually say, "Okay," and hope that the answer became apparent in the rest of the conversation. So you have to actively think about what the right thing to say is, and it can vary a lot by customer. Different customers are interested in different facets of your value proposition.

Sales is, in a lot of ways, a modern-day Turing test for humans. You have to communicate clearly, humanize yourself, and ultimately land the sale.

More broadly, though, I really don't know exactly how we attracted users. CoderPad is probably unusual compared to a lot of other companies that interview with Indie Hackers. We don't collect user metrics, and we don't do any marketing.

I've experimented with ads and found them generally lacking. I think it would probably benefit the company to focus more on user acquisition. But because we're a B2B SaaS product, we can get away with merely having a good product and decent interpersonal skills. We make a lot of our money off of some very large individual contracts.

I've chosen, as a general philosophy, to apply targeted effort to make individual people happy instead of learning how to navigate fundamentally mysterious ad platforms.

What's your business model, and how have you grown your revenue?

We charge customers subscription fees based on their usage levels, and we generally only do inbound sales. We've grown our revenue, as far as I can tell, by becoming better at sales and also by raising prices. Today, the old adage of "charge more" is as true as ever.

Month Revenue Oct '13 2000 Oct '14 22000 Oct '15 50000 Oct '16 88000 Oct '17 170000

I'd like to digress here and talk about picking good customers. This doesn't get talked about as much, but there is a huge difference between a good and bad customer. I don't just mean based on contract size, though they are correlated; big customers tend to be better.

I mean simply: are they good people? Some customers have investigated their options, are informed, and have decided that your product holds promise. They are typically eager to learn more and adopt changes quickly, because they're actually trying to get something done.

Other customers try to buy your product through a reseller because they're trying to tick some box, or because they think your product does something that it does not. These people will schedule many meetings and take a very long time to decide anything substantial.

Being able to qualify leads based on quality early in the process will help you stay sane and avoid wasting time. As the sole owner of my business, I can and do tell people to fuck off, and I treasure this privilege almost as much as life itself.

Good customers will grow with you, tell their friends about you, and just generally be awesome. I would rather have a few good customers than a lot of mediocre ones — it's a lot less work.

Thinking about good and bad customers also helps prioritize work. For instance, in CoderPad, there are a few ways to abuse our quota system to get more than you paid for. Clamping down on this would require making the product more annoying just to penalize bad customers. Every time someone tells me I should be more strict about this, I ask, "How much effort should we spend trying to extract value from people who clearly don't want to give it to us? Shouldn't we just try to attract better customers?"

What are your goals for the future?

I want to get CoderPad to the point where you can have a whole workspace, spin up your own web server in the cloud, or anything else you might realistically want to do as part of a programming interview.

In general, we want CoderPad to mirror a modern development environment as closely as possible, and we jump through a lot of hoops to make that happen. For instance, we run headless Eclipse in the cloud just to provide Java auto-completion, because I think it's (unfortunately) impossible to write Java in 2017 without the aid of an auto-completing IDE.

However, the truthful answer to the question is underwhelming. We focus on near-term goals that deliver value to our customers. We don't really have long-term plans. I think this is the nice part about bootstrapping: you can realistically claim to not be terribly ambitious.

We don't collect user metrics, and we don't do any marketing.

For instance, I clearly remember the moment when I failed the in-person YC interview. Garry Tan asked me what the eventual value of my company could be. After a bit of thought, I concluded that it was extremely unlikely that CoderPad would ever be a billion dollar business. Naturally, they passed, which was the right decision for them. Luckily it also ended up being a pretty okay path forward for me.

I recommend that other potential bootstrappers have just one goal: to make something that other people want more than the money they already have in their wallet. Everything else seems pretty negotiable. Life is short.

What are the biggest challenges you've faced and obstacles you've overcome?

We had (and still have) a lot of trouble settling on our pricing model. The earliest version of CoderPad featured two self-service plans at $20 and $50 per month, as well as an option to contact us for enterprise pricing should the user exceed the largest plan. We raised those prices to $50 and $100, respectively, but were still having problems.

Large companies would start using the $100/mo plan, eventually hit their cap, and want to upgrade to the enterprise tier. For our business to make sense, we have to be able charge large customers in the thousands of dollars per month because it takes so much time and energy to close those deals. A price jump of over ten times the previous price caused a lot of sticker shock. Customers would look at our self-service pricing and mentally anchor at the $100 mark, and we'd have to put in a lot of energy to get them to cross that gap.

Darius and I fought about the proper course of action. He would argue for raising prices on the self-service plans to make the price jump to enterprise seem less intimidating. But I was often of the opinion that if the value proposition was good enough, price anchoring shouldn't be a huge deal. I also wanted to maintain relatively affordable plans for smaller companies.

In the end, we added a third self-service tier and raised prices on the second, bringing prices to $50, $250, and $750 per month. This ended up both generating more money from the self-service plans and making negotiations with larger corporations easier, since any company who wanted an enterprise plan had already accustomed themselves to paying $750 per month.

The real teachable lesson here ended up being about my own reluctance to tackle the issue. I was afraid of annoying customers and supporting customers on cheaper legacy plans. This turned out to not be a big deal, but my impulse to procrastinate big decisions got the better of me.

I think a lot of founders procrastinate their most existential problems by doing the second-most important thing on their list. Personally, I did a lot of small feature work while mulling over potential changes to the pricing model. I entreat the reader to not fall into the same trap.

Have you found anything particularly helpful or advantageous?

I once snuck into a seminar that Steli Efti hosted for YC founders trying to learn how to do sales. It was very helpful, and I recommend doing something similar if you need to learn to sell.

I imagine you should do likewise for any other important job skill you need to pick up quickly. If you're doing a B2C play (God help you), I would try to get good at marketing fast, and that probably means learning from people who have gone before you.

Having a good sense for product-market fit is also obviously crucial. Building a product for myself made this a lot easier, and I recommend being your own customer as much as possible. Eventually this will stop working, because if you are successful, your customers will begin to have more elaborate needs than you. But at that point you can just talk to them about what they need.

What's your advice for indie hackers who are just starting out?

More than any external threat, I think that founders are their own worst enemies. I've seen a lot of founders fail. Most who fail do so because they care too little or too much.

In the former camp, you see a lot of people fail just because they don't put in enough work. Starting a company from scratch is pretty hard. You need to get a lot done pretty quickly, and you need to be unafraid of doing really boring things.

Be careful if you usually feel that you are right: if you are usually right, a bit more caution won't hurt you. If you're not, then you might avoid being catastrophically wrong.

If you're selling a B2B product, you need to get good at calling people and convincing them of things. This is very dull work, especially given how frequently you get rejected at first. Founders like to focus on work they're already good at, but in the beginning the boring stuff often matters a lot more.

In the latter camp, you see people who become very attached to their idea as part of their ego-identity, and become unable to see their product from the perspective of their actual users. Founders in this category commit to building very... strange things.

If you haven't reached product-market fit, you should ask yourself repeatedly: "Will someone give me money for this?" If you're not sure, you need to ask actual strangers that question until you are sure. You should also welcome the answer of "no."

One striking thing that Paul Graham says is that YC seems to be in the business of giving founders advice that they ignore, typically by twisting that piece of advice's meaning to validate what the founders were already doing. Be careful if you usually feel that you are right: if you are usually right, a bit more caution won't hurt you. If you're not, then you might avoid being catastrophically wrong.

What else in life is important to you?

On the subject of people often believing that they are right, I want to take a moment to talk about housing in San Francisco, and in California more generally.

Right now, the citizens of the Bay Area have grown totally accustomed to the idea that a one-bedroom apartment in San Francisco costs $3,500 per month. We humans are very good at rationalizing why the current state of affairs is "correct," "unavoidable," or "unchangeable." This is unfortunate because the current state of affairs is a monstrous tax on human health and happiness. High rents are crushing working families and pushing people out of the state.

Housing in San Francisco is expensive mostly because of a series of incredibly unfortunate political accidents, in particular the passage of extremely tight local zoning control and Proposition 13. Kim-Mai Cutler lays it out very well in her seminal work, "How Burrowing Owls Lead To Vomiting Anarchists." The gist of it all is that early residents of desirable areas have made it very hard to increase housing density where they live. Over half of San Francisco's land is zoned to permit only single-family homes.

If you live in the Bay Area or San Francisco, I want your help in fixing this mess. The YIMBY (as opposed to NIMBY) movement is dedicated to increasing the supply of housing for everyone. We support high-density housing projects and are running a ballot measure to speed up the production of affordable housing. We'd love your support on our ballot initiative! We need volunteers to gather signatures, or money to pay for people to gather them. And, of course, we need your votes.

Where can we go to learn more?

You can check out my personal website for more of my writing. I also gave a talk at Dropbox that readers of this site may enjoy entitled "Starting a Business Without Quitting Your Day Job." Lastly, you can follow me on Twitter where I am extremely proud to announce that I have exactly one thousand followers.

If you ever want feedback about a business you're starting, feel free to email me. I'll be here to answer any questions you have in the comments, too!