I'm becoming an increasingly big fan of infrastructure services like Amazon's EC2 and S3. The reason is simple: You pay for what you need at around the time that you need it. This is the point I made when recently interviewed by Erica Naoone of MIT Technology Review in an article aptly and succinctly titled "Cheap Infrastructure".
In the interview I was my usual, highly opinionated self, but this particular statement that made it into the article jumped out at me: "There's no correlation between the amount of money an entrepreneur actually needs and the money a venture capitalist puts into the business." Of course, there are some qualifiers here: I'm talking about software companies and I'm talking about the Series A investment (first institutional money). Also, if I had done the interview in writing, I likely would have said there's little correlation instead of no correlation. But, my larger point still stands. The way the system works, you often don't raise what you need, you raise what you can.
But lets shift gears just a little bit, before we get deeper into the VC funding stuff.
In the early stages of an internet startup, one thing that's always difficult is predicting the level of infrastructure that is needed to support the volume of users/customers. Entrepreneurs often overestimate how popular their software is going to be. There's also the notion that too much infrastructure is better than to little because "you only have one chance to make a first impression." Finally, there's that whole nagging thing about reliability and uptime.
The net result, before EC2/S3 and similar services, there were few options. Costs were relatively high and somewhat "spiky" (you bought a few servers, threw them into a co-lo, bought more servers, etc.). There wasn't a good way to handle this common situation: "Hey, we only have X users right now, and we expect to grow by Y%, but we need to make sure we can handle Z users just in case we get written up on TechCrunch or get on the front page of digg." You ended up compromising somewhere. Either you spent little (and dealt with spikes if/when they came as best you could) or spent too much, resulting in a fair amount of "unused capacity".
Now, back to the VC funding part. When my co-founder, Brian Halligan first kicked off HubSpot, we thought a lot about the capital needs of the company. I funded the seed round. We later successfully raised some angel funding -- about $1 million. We felt that was enough to get us to the next "milestone" (product launch). The rationale we had was reasonable: Raise a little money early, raise more money later. By raising money "closer to when we needed it", we felt we could continue to reduce the risk, increase the value of the company, and ultimately dilute less. And in fact, this is how the VC process sort of works. You raise a Series A, Series B, etc. and each round is targeted at getting a company to the next "milestone". The problem is, it's awfully "spiky" . This led us to ponder the other side of this spectrum. In theory, the "optimal" path would be for us to sell just enough shares every month based on the cash needs of the company at whatever the right "price" is at that time.
In a way, the Y Combinator folks do this as the first step. They give founders just enough to get through the first few months and build a prototype. Many of the YC startups then go on to raise follow-on funding from VCs. But at that point, the funding process looks like the usual -- it becomes "spiky" again. We don't have a pure incrementally scaling model for startup funding anywhere.
Of course this scalable funding model probably only works in theory -- and even then, it's a stretch. There are lots of reasons why this doesn't work in practice. Here are just a few:
1. There's no efficient way to appropriately "price" the shares that frequently.
2. Entrepreneurs don't want to worry about whether they'll have the cash they need next month.
3. There's likely not going to be agreement on how much cash should be burned month-to-month.
4. There'd likely be some friction and transaction costs.
There are ways to mitigate some of these challenges, but I still don't think it's practical and would work. My VC friends (and yes, I do have those), would likely agree.
But, the geeky and analytical side of me still finds the purity of this model appealing for the same reason I like Amazon's EC2. You get what you need and grow incrementally instead of spikily (yeah, I made the word up).
What do you think? Yes, the idea is crazy and wouldn't work, but just how crazy is it?