The Inside Story of a Small Startup Acquisition (Part 2)


Photo by psiaki

Why I Bought My Next Startup (Instead of Building It)
This is part 2 in a series covering my acquisition of HitTailpart 1 went to the top of Hacker News last week and I have a slew of questions from that discussion that I will answer next week.

But first I want to address the most common question I hear when I tell someone I acquired a startup:

Why did you buy instead of building?

If you’re a developer you’re probably scratching your head wondering how I could pass up the chance to do the awesome green field development. A new project with no legacy baggage…this is the stuff we live for!

But I did indeed opt to plunk down my hard earned cash instead of hunkering down for 6 months in my dev cave, and what follows are my reasons for doing so.

Reason #1: Saved 12-18 months
I have a little theory that a v1.0 should take 4-6 months from inception to launch. This includes time for marketing (which should start before you write a line of code), planning, development, launch, etc…

And if you have the luxury of working on it full-time then by all means you should get it out the door faster. Almost without exception, the sooner you get in front of real customers the better off you’ll be.

But in general, this is “Rob’s Theory of Time to 1.0″: 4-6 months, 300-600 hours.

But there’s another time frame, and I call it the “time to flywheel.”

A flywheel is a large, heavy wheel that requires an incredible amount of effort to get moving, but once it’s moving it can continue to do so under its own momentum for quite some time, without additional effort. The time it takes to get your business to “flywheel” will vary, but I’ve found that it’s typically 6-12 months after launch.

“Time to flywheel” is not profitability, but an app is typically on a rapid trajectory towards profitability when it hits.

It’s also after you’ve confirmed you’ve built something people need and are willing to pay money for, and have found your market (some would say product-market fit). You’ll also have some marketing channels that are bringing in new customers for less than they pay you during their time as a customer.

This is the point where you have a bit more work to do in order to scale, and when smart founders who are interested in funding begin to seek it out. My typical estimate when asked how long it takes to get there is 12-18 months. Some companies can pull it off in 9, for others it takes 24 if they are ever able to achieve it.

But the sweet spot is around 12-18 months.

Getting to “flywheel” is a slog. It’s painful (and yet also exhilarating). And frankly, I’m not a patient person when it comes to growing a business.

Given the hourly rate at which I value my time, and the value I place on 12-18 months of effort, buying an application like HitTail is a ridiculous bargain. It may be the best deal I receive on anything I buy during the next year.

Reason #2: It Has “Good Bones”
There’s something to be said for acquiring an app that’s already worked out the v1.0 kinks. HitTail has been around since 2006, and although some of the software architecture and code structure leaves something to be desired, a lot of bugs were ironed out in the early days.

Any problems that existed when I took it over had crept in over time due to changing APIs, lack of maintenance, and failed hardware.

In general, the code had been purring away for 3 years without intervention, and that indicated one thing to me: this thing had good bones.

“Good bones” is an expression realtors use about a house to indicate that the major systems like plumbing and electrical are solid, but that the house may need cosmetic upgrades like new paint and flooring. It means the house is pretty solid as it stands, and that with a bit of effort it could be more attractive and more valuable.

It’s an expression I would apply to HitTail, and one of the reasons I decided to acquire it.

Reason #3: Dramatically Reduced Market Risk
When you set out to build and launch a product there are three types of risk: product, market and execution.

  • Product risk looks at whether or not you’ll be able to build the product. These days, most web apps we see have only a small amount of product risk.
  • Market risk looks at whether there will be people willing to buy your product if you build it. This is the risk factor I encourage founders to look at the most, especially before they write a line of code. Market risk is the deadliest of the three because if you build something for which there is no market, it’s nearly impossible to adjust course later and fix it.
  • Execution risk is whether you can pull off the whole package. Can you bring everything together, build and launch the product, and get it in front of the right prospects?

Given these, market risk is the one that scares me the most. Every time.

I have confidence in my ability to execute, but anything I can do to reduce market risk early is a no-brainer. Buying an app with paying customers is one of the best ways to ensure you have something people will pay for.

Reason #4: Better than Outsourcing
I talk a lot about outsourcing. Last year I paid $100 or more to at least 15 contractors ranging from developers to an infographic designer. And I’m a firm believe that you must learn to outsource or hire employees if you want to grow a business.

But I would take a completed product over a spec every time.

Outsourcing works, but avoiding the possibility of hiring a crappy developer, building the wrong feature set, and the enormous amount of time you need to invest to manage a development project is typically well worth the purchase price.

Counter-Reason #1: “If you buy, you’re not a real founder!”
This is from my internal monologue that attempted to talk me out of the acquisition.

At one point I actually stopped to wonder what people would think of the fact that I didn’t build HitTail myself from the ground up.

Are you a real technical founder if you don’t write every single line of code for your v1? Or at least oversee every single line of code as it’s being written by your team?

I’ve built and launched apps from the ground up in the past. Am I still a real founder if I skip it this time?

The conclusion I came to is that it doesn’t matter.

Growing HitTail into a more profitable business is the next phase of my learning (and the next test of my chops). Both personally and career-wise it’s the right decision.

Everything else is semantics.

Conclusion
If you’re interested in hearing more about due diligence, which things I attacked first after the acquisition, thoughts on valuation methods, and answers to other questions from the Hacker News discussion, stick around for part 3.

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.

21 comments ↓

#1 The Inside Story of a Small Startup Acquisition (Part 1) | Software by Rob on 02.02.12 at 6:58 pm

[...] The Inside Story of a Small Startup Acquisition (Part 2) → [...]

#2 Jim on 02.02.12 at 9:39 pm

The key point you mentioned for me is “Given the hourly rate at which I value my time, and the value I place on 12-18 months of effort, buying an application like HitTail is a ridiculous bargain. ” It is so true because I’m in the 3-4 month slog now and I’m thinking it will ultimately cost more by doing most of the work myself. Great post, I’ll be looking for Part 3. I also bought your book and it changed my thinking. Thanks,
Jim

Sachin Reply:

Cost more? Yes. Easier to fix when it breaks? Definitely.

Rob Reply:

I’ll say that it’s surprising how easy it is to learn a piece of software when your back is to the wall. You can go from 0 knowledge to fixing complex bugs in a matter of hours once you own an app and know that you’re going to live with it for the foreseeable future.

As developers we think everyone else’s code sucks. I’ve done 25+ acquisitions to date and I have always managed to fix things that need it. And the overall package is still substantially less “expensive” than if I had built it myself.

#3 Chris Haueter on 02.03.12 at 12:49 am

Rob, I’ve loved these first two blog posts about acquiring small web applications. Excited to read the third in the series!

#4 You Can’t Replace Experience With Methodology | Whitetail Software on 02.03.12 at 12:50 am

[...] me get those experiences with less commitment and more focus. This is all one reason why I support Rob’s thinking behind acquisition. I’m planning to do a bit of that on a small scale myself. It’s a (hopefully?) great [...]

#5 nAG on 02.03.12 at 2:25 am

its nice post…but how you identified hittail..it is interesting story for many. Can you share that..

Rob Reply:

I’ll cover it in part 3.

nAG Reply:

Thanks

#6 Justin on 02.03.12 at 3:08 am

Hey Rob, this and the previous blog post in the series have been very inspiring. Congrats on your acquisition.

Can you say, or are you going to include it in the next entry, how long you estimated it would take, given your purchase costs and ongoing expenses, to make the acquisition profitable?

Looking forward to the next part.

Rob Reply:

Sure, I’ll try to cover that in part 3.

#7 matt on 02.04.12 at 11:04 pm

no your not a real founder your a business man now!! :) i agree with what you said:)

#8 Marco Demaio on 02.05.12 at 6:47 pm

I really appreciated the smart forensic analisys that describes the reasons of why “to buy” instead of “to code”. But beside all the smart reasons you made, don’t you feel unconfortable not to have the full control on the entire web app code as you probably would have if you re-coded/re-designed it yourself? Don’t you feel scared that if something does not work in the web app and a customer complains you might not be able to fix it unless going through the frustrating path of reverse engineer the app in order to find the bugs?! And what about if in future you want to add new features? Wouldn’t you have to deeply understand the app almost to the point as if you re-developed it yourself?!

Rob Reply:

Good questions! Here are my thoughts:

>>don’t you feel unconfortable not to have the full control on the entire web app code as you probably would have if you re-coded/re-designed it yourself?

Nope. It took me somewhere around 2 weeks of hard-core bug fixing to feel like I knew 80% of the app. 30 days in I could tell you what to modify to add any feature you need. It helps I was elbow deep in the code for 40+ hours a week during this time, totally focused on fixing and learning.

>>Don’t you feel scared that if something does not work in the web app and a customer complains you might not be able to fix it unless going through the frustrating path of reverse engineer the app in order to find the bugs?!

So much had been broken before I bought it that no one expected much in terms of fixes. The fact that I was fixing anything was a huge win in the eyes of the existing customers. And I didn’t start bringing new ones into the fold until I was confident I knew the app pretty well. I didn’t blog about it until 4 months after the acquisition for precisely this reason.

>>And what about if in future you want to add new features? Wouldn’t you have to deeply understand the app almost to the point as if you re-developed it yourself?!

I’ve been adding new features already. If I had developed it myself I would have spent around 1000 hours. I spent maybe 120-150 (with customers paying to use it during this time) and I know it pretty much as if I had written it myself. I don’t agree with all of the architectural decisions and a lot of the code structure, but I do know it well enough to hack on it.

#9 Anonymous on 02.05.12 at 7:03 pm

As a developer, how did you convince yourself that other people code does not suck? It’s so hard to trust it. It’s also frustrating to go through code written by others, it’s more fun wriring it yourself. I thought deeply understand an app by walking into its code would take the same time of writing it from scratch. Considering your many success stories, I think i should overcome my ‘write from scratch’ way of thinking, but it’s hard. I’m wondering if you used to be tempted by the ‘write from scratch’ too, and how did you overcome it?

Rob Reply:

My thoughts:

>>As a developer, how did you convince yourself that other people code does not suck?

Everyone’s code sucks. Even my own. Legacy code is always a drag to work with.

>>It’s also frustrating to go through code written by others, it’s more fun wriring it yourself.

You’re right. If you want to have fun, though, think about working on an open source project or building a game. This acquisition has been fun, but it’s not 100% fun. A lot of it is hard freaking work. But if it was easy/fun everyone would be doing it :-)

>>I thought deeply understand an app by walking into its code would take the same time of writing it from scratch.

Nope, probably faster by a factor of 10.

>>I’m wondering if you used to be tempted by the ‘write from scratch’ too, and how did you overcome it?

Absolutely. As developers we all are. I got over it after my first acquisition where I bought a product that I estimated would take me 400-500 hours to build for pennies on the dollar. I turned that one around and it has done very well for me over the years. That cured me of the “must be invented by me” syndrome.

Don’t get me wrong – I would prefer to do green field development all the time, using the latest technologies that I choose, and spend as much time as I want building apps. But, of course, I would own 1/10th of the products I do now if I had stuck to that approach.

#10 Christi Johnson on 02.07.12 at 9:51 am

We’re anxiously awaiting the next installment…

:)

#11 Christi Johnson on 02.07.12 at 9:55 am

Now that I think about it…what ARE the issues that you have found hard to fix now that you own an application that you didn’t build from the ground floor. In the last post, I mentioned I would be purchasing asap…but I might want to wait until all is fixed. Should I move forward or wait a bit? Is the app working the way you want it to?

cj

Rob Reply:

I’ve been able to fix every issue to date, except for one that requires a major DB re-work, and that’s to support Chinese and other unicode characters. If you run a site with non-latin characters some of them come through, some do not. It’s going to take a couple months to upgrade that situation.

Other than that everything has been fixed as it arose. I made it a point not to go public with my acquisition announcement until the app was stable and performant once again.

#12 John Polacek on 02.09.12 at 8:04 am

Where are the best places to look for startups available for a potentially low cost acquisition?

I’d love to see a follow up post with advice for how to go about the process of acquiring, from start to close (and maybe even a part 2 on turnaround!) Good topic for a podcast?

Rob Reply:

>>Where are the best places to look for startups available for a potentially low cost acquisition?

No great place right now. Flippa is the best, but you need to invest the time to learn the process. You’re not going to look for 30 minutes and find a HitTail on that site. I spent 20 minutes a day for months before I found my first good deal. I’ve purchased well over 20 websites and web apps on Flippa.

>>I’d love to see a follow up post with advice for how to go about the process of acquiring, from start to close (and maybe even a part 2 on turnaround!) Good topic for a podcast?

Episode 15 of http://www.startupsfortherestofus.com covers this. I also cover it in depth (including turnaround) in Micropreneur.com. I will likely not write a series of posts on this topic since it’s very dense and I’ve already covered it in other places.