Buy-vs-build for an early stage startup

If you start an early stage tech company today, it's kind of crazy how many hosted services there are out there, trying to help you build your product for a monthly fee. You can get a service for support tickets, and hosted outgoing email, and error logging, and managed Wordpress hosting, and private IRC servers, and continuous integration, and reporting dashboards, and automated billing, and almost everything else. Of course, if you whip out your credit card and sign up for twenty different services right off the bat, you've set yourself down the path of paying a meaningful chunk of cash every month. You might be reluctant to do that. But I think, if anything, you should err on the side of spending a little too much money on hosted services to help you focus on your product.

For a lot of good programmers, these kinds of decisions aren't really natural. They got into the business in part because they love building, and they pride themselves on being able to handle whatever technical challenge they come across. The last thing they want to do is morph into some middle manager who's so out of touch that he only knows how to throw money at problems.

But here's the thing: If you're an early stage startup, you absolutely do not have the time to solve most problems well. As the saying goes: Startups don't starve, they drown. In a typical day you'll have to take care of 20 things, and you'll only be able to do one or two pretty well. So pick which ones are the most important, and for the other things, you should seriously consider paying a hosted service. Even if the solution isn't exactly what you would've built. Even if it's a bit more expensive than seems reasonable.

The only reason that an early stage company has for existing is to prove that customers want the product that it's building. That's what investors will be looking at when you try to raise--not whether you saved $100 a month by managing your own brochure site. If you pay a little too much for a customer tracking service, that's not going to kill your startup. But you know what will kill your startup? Being too busy fiddling around with half-assed DIY solutions to figure out what your customers want in the first place.

And, in a related note: You will never be able to hire all the programmers you need. The hiring arms race marches on, and will probably only get worse, for, say, the next decade or two? Yeah, there may be little bubble burstings here and there, but generally speaking you should thank the heavens for every great programmer you can get to be an employee of your company. You should know that you might not get to hire another person that great for a long time.

So--to compare programmers to servers--try to scale your team up, not out. Meaning, it's actually going to be very hard to just turn on a switch and hire more engineers of the same caliber. It's easier to make the same engineers more productive by enhancing their work. One way to do that is with a judicious mix of the right hosted services--which are just a complicated way of paying the other engineers who work for those services. (Often living in cheaper cities, so you get some nice wage arbitrage too.)

By now you might be saying "that sounds nice, but I just don't have the cash." If that's the case, repeat after me, about a thousand times: The biggest expense for a startup is your time. Not your laptop, not your hosting bill, not your office, but the hours in your day. Even if you're living on ramen and not taking any wages, your time is still expensive in terms of the wages you are giving up from another company. It is also expensive in terms of the giant ticking alarm clock floating over your head. Because if you fuck around for too long, one day that alarm is going to go off and you're going to realize you're sick of living in poverty, and you're going to go back to working full-time for somebody else.

Of course, this isn't to say that every hosted service is a slam-dunk. There are many times when you should build it yourself. Some hosted services are actually way too expensive, and some products do actually suck. There's the non-trivial problem of startup SaaS vendors going bankrupt or getting talent-acquired. Some business logic is so core that you need to change it all the time, or it's so specific that nobody else will ever build a product that does what you need.

But there are many times when you're going to have to look at somebody's product, and think "I would've built a better product and charged less for it, but I don't have the time to prove that. So instead I'm going to pay you money for doing it worse than I would've done it." And when that happens, it's your responsibility to hold your nose and pull out your credit card.

I'm starting to think that building an early-stage product is an exercise in intentional, selective perfectionism. You have to pick the 1% of the problem that will make your product stand out from the competition, and then polish it until it positively gleams. But if you look one inch to the left of that, you'll see some substandard ticketing system or error reporting system, and maybe it'll drive you absolutely up the wall. And I guess the best you can do in those times and to take a deep breath and tell yourself that you'll get to that one day.

And to some extent, even our own inspirations can be a bit misleading. It's easy to walk into the Apple store and see how beautifully they designed everything, and then think that the way to be the next Apple is to be completely perfectionistic about everything all the time. But Apple is a 35-year-old company. For a very long time, they had to put up with their beautiful products being sold in other people's crappy stores.

Hiring techies at startups: Go narrow

Jesse Chan-Norris on writing a techie job description for Indaba Music:

... what I realized was that we needed a job description that spent much more time explaining who we are, as a team, and as a company, and by extension, the kind of person you should want to be if you want to join that team and work with us. I wanted to construct a posting that would attract the right kind of people and get them interested in us, that would sell our company as much as the candidates were selling themselves to us.

So this time around, instead of talking about years of ruby experience and a working knowledge of mongodb, we tell people that “Every member of our team is involved in the product development process. We challenge our developers, and we expect people to contribute at every step along the way” and we talk about how “We are a small team, and everyone is expected to exhibit a fair amount of autonomy.” And more than anything else, we lead with our core philosophy, which is that we believe that “the music industry is more alive than ever.” Forget all of those people who think that this industry is in the shitter – we’re just getting started.

I'd sharpen this even more. There's that piece of pitch-deck wisdom about how you never say "this is a $10 billion market so if we only capture 1% of it that'll be $100 million!" -- instead, you say "this is how we're segmenting this $10 billion market into a more precise $100 million market, and we're going to shoot for getting 100% of it". The idea being that nobody ever sold a new product by being a tiny bit better than the other guys to everybody in the whole world.

Well, I think it makes sense to think of hiring programmers that way too. You should define what sort of a place your company is to work at, and then really emphasize that differentiation as you write job descriptions, hang out at meetups, etc. No good programmer ever switched jobs because the next job sounded 1% better than their current situation. (Well, some programmers do that, because some of us are seriously brain-dead when it comes to making career choices, but that's another topic.)

To take an example: When Profitably started looking to hire engineers, we explicitly positioned ourselves as not another social media site. We talked about "complex analytical problems" in our job description, and sometimes I'd send out job emails actually making fun of the idea of working in social media.

That might seem unnecessarily negative, but keep in mind that the NYC startup scene is full of social media companies, and I was willing to bet that I wasn't the only techie in town who was a little fatigued by that emphasis. And I figured the most important thing was this: Above all else, break through the noise.

And, hey, you know what? If you really love working in social media, you probably wouldn't want to work at a company like Profitably anyway. But in the meantime, those little jabs at social media serve as a cue to the small minority of people who are tired of that scene, and maybe they'll read more about the company, and maybe even get in touch.

The nice thing about being a small company is that your hiring needs are small, and you can craft a job description that's that precise. Maybe it excludes everyone but ten programmers in town--if you're only hiring three programmers this year, you're good. Until the day when your massive prowess at tech hiring, combined with some real product-market fit, makes you so big that you've got Google-size hiring problems, at which point, congratulations.

What we mean when we say disruption

Chris Dixon:

It is true that new technologies often lead, in the short term, to lower wages and fewer jobs. Craigslist, for example, has about 30 employees yet, by replacing the classified ad industry, eliminated many thousands of jobs (local newspaper reporters, classified ad salespeople, etc). The same could be said for almost every popular website.

On the flip side, new technologies have driven down prices (Walmart and Amazon), led to massive increases in information productivity (Google and Wikipedia), and created new income sources (eBay and Craigslist). Greater productivity and lower prices at least partly compensate for part-time jobs and lower wages.

A few thoughts on this:

Continue reading “What we mean when we say disruption” »

Next steps

So, I've left Profitably, as of last week. Early-stage startups involve as many subjective decisions as objective decisions, and if the gut instincts among the team are strongly out of sync, sometimes you won't be able to find a workable consensus no matter how long you try to talk it out. That's the situation we were finding ourselves in, and ultimately we decided that the best option was for me to move on.

It's been an amicable process, and everybody involved, from the other team members to our investors, has been extremely fair, understanding, and supportive. Not that they even have to be that supportive, really: I'm excited about the future, both for Profitably and for myself. The Profitably team is off to a solid start on offering strategic financial insights to small businesses, and I wish them all continued success in the future.

As for me? Now's as good a time as any to take a breather, so I'll be doing some of that. I may even find time to sit on a beach somewhere, so if you see me at some meetup with a wicked sunburn, that'll be why. But it won't be long before some other role piques my interest. I continue to love the challenges of managing top-notch programmers, of working closely on an evolving product vision, and of playing a bridging role between the techies and everyone else.

And, you know, this field never stops being interesting. There's a lot of talk about whether or not the tech scene is in a bubble: I'm happy to leave that question to the VCs. That cycle plays out over months or years, but in the truly macro sense, every time I see the problems that people are trying to solve, and the problems that people aren't even close to yet, I think to myself that we're just getting started. Line by line, we build the future. We're lucky to be paid for the privilege.

So, just so I've got this straight, you're saying you're NOT dumb.

As seen on the General Assembly chalkboard.

And as far as that education goes, it really looks like you got your money’s worth, kid.