Inspired again by this post from Fred Wilson at Union Square Ventures, I began thinking of the differences in the capital required to launch something these days. Much ado has been made over Web 2.0, and how much cheaper it is to build technology solutions these todays.
I came across an old proposal that I received from a vendor years ago (in the 1.0 days), and got a good laugh out of it.
We all know that things are cheaper to build these days, but I thought it might be interesting to put together a post illustrating the actual dollar differences in hardware, software, services, and labor costs. And yes, this is my last official post for 2006 – so happy new year in advance (4 hours from now!).
Note: I am using the phrases “Web 1.0” and “Web 2.0” to simply represent the passing of time.
The numbers that I am using to represent the Web 1.0 days are taken from a series of documents from a startup I was working with at the time. I am going to show those vendor dollars (and time components, where possible), and compare them to what my estimate would be if I were building that same system today. The focus, of course, will be on dollars, time, and trends.
The exact specifications of the proposed system are not important. For the purposes of this post, consider the proposed system to be a “typical” B2B/ASP procurement system. The only important criteria here at this point is that there should be a suitable “stage” environment, which would run parallel to the production environment.
These numbers only reflect hardware, software, and outsourced labor costs – they do not reflect internal IT spend (laptops, mobile fees, etc.), and do not reflect salaries of FTEs or other business-related expenses. I think it is safe to say that there were more than a few companies back then spending money on frivilous non-essential items.
Enterprise Software Costs
The original system was built on a stack comprised of ATG’s Dynamo web application server (with the personalization license add-on), and Netscape’s Enterprise Web Server. The backend was facilitated by an high-end Oracle database.
On the application side of things, we were building upon Oracle Exchange, which was Oracle’s attempt at fighting Commerce One and Ariba. It was *supposed* to provide a big pile of transactional and catalog management capabilities – it turned out to be a vaporous pile of ****, but that’s probably a post best left for another day.
Interwoven was the content management system (CMS) of choice, and Verity was selected to provide “search” capabilities.
We implemented a very high-end CRM solution built around Silknet’s product and Aspect’s ACD (call center) solution.
|ATG Personalization License||4||20K||80K|
|ATG Development Seats||5||10K||50K|
|ATG Staging Licenses||4||5K||20K|
|Netscape Enterprise Server||2||1K||2K|
|Silknet Maintenance (1st year)||1||34K||34K|
|Aspect Maintenance (1st year)||1||41K||41K|
Nearly $2M in infrastructure software spend, and we haven’t written any code or hired any employees. As you will see in a moment, for a tiny fraction of this same amount, you could very likely build not only the entire application, but build the entire company around it.
If I were building this same system today (as a startup), it would very likely be built upon the LAMP stack (Linux, Apache, MySQL, PHP). Why? Low cost, high human resource availability, and sufficient scalability. For CRM purposes, I would do a 5 minute download and install of the free version of SugarCRM.
For the CMS, take your pick – there are several dozen very high quality open sourced/GPL’d CMS products out there that are comparable in functionality (PostNUKE, Plone, Joomla/Mambo, Etomite, Apache’s Lenya, etc). Building a CMS framework from scratch is certainly an option as well – very easy to do with current toolkits. Adding search capabilities is just as easy (Apache’s Nutch project, htdig, Sphinx, even Google).
Total cost? $0. Gotta love freely available, open sourced, GPL’d software.
In the original system, the servers were all obtained from Sun, and were broken down as follows:
|Sun Microsystem E250 (1 CPU unit) – front-end web server||2||10K||20K|
|Sun Microsystem E250 (2 CPU unit) – Dynamo hosts||2||20K||40K|
|Sun Microsystem E450 (2 CPU unit) – database server||1||30K||30K|
|50 Gbyte RAID device (back-end storage)||1||40K||40K|
We were eventually going to add some additional hardware, but this was our initial environment (about $130K worth). Obviously hardware is more powerful now, so to support the same number of users, logic tells us that we would need fewer of today’s servers. Of course, web services are more widely adopted now by B2B users, so our number of users would probably go up – in the end, it is probably works out about the same.
The bottom line is that you can obtain a nice 2U or 4U rackmounted server, dual or even quad CPUs, loaded with several gigabytes of RAM, 15K RPM SCSI RAID arrays, for less than 10K each (I’ve recently procured them around the 7-8K point.) If I were building a system comprised of six (6) physical servers, you’d be looking at less than $50K, which would be a savings of $80K.
That of course assumes I am interested in launching with relatively high-end hardware. If you really wanted to pinch pennies, you could slide down the scale a bit – remember, hardware is more powerful these days, so perhaps a dual CPU (or even dual core) unit would suffice in lieu of a quad-CPU rig. You get the idea.
Hosting was one of those things that really became a racket in the 1990s. Now, it is back to being a commodity, where it should be. Hosting providers have to differentiate themselves by tacking on true value-added services (imagine that).
Oracle was charging us $300K/year for hosting their Oracle Exchange. $50K per month! That didn’t count the $100K we spent on routers, switches, and other network equipment (so we could do our own hosting for our core online service – again, imagine that).
In the first year, that represents a $400K spend on hosting.
In today’s market, we could have hosted all of our servers, on a reasonably fast pipe (against a fiber ring) with a reasonable throughput capacity of say, 10Mbps, for less than $5K per month (much less, depending upon the vendor, if we were co-locating the servers, leasing a full rack vs. 1/2 rack, etc.)
If the savings in software, hardware, and hosting hasn’t made a strong enough case, wait until you see the labor savings.
I am reminded of one of the great “de-motivational” posters available at despair.com, which says “Consulting: If you are not part of the solution, there’s good money to be made in prolonging the problem.” I both made, and spent, a small fortune in consulting during the 1990s.
We had a veritable army of people working on this project. We were paying one consulting team (from a typical vendor) a total of about $3.4M over a nine month stretch to build our core product. An additional $840K was budgeted for another four (4) month phase after that.
We had another team working against a $1.4M purchase order to build out our customer care portal. And finally, a third, smaller team consulting with us on “corporate strategy” against a $480K purchase order.
I won’t count the latter (corporate strategy consulting), as no startup in their right mind would pay for that service today. Nevertheless, the total labor bill came to around $5.6M.
With a decent offshoring team (even in India, where the prices have been rising steadily), you could build this entire application for between $500K – $1M (as a reasonable estimate based on my experiences in both worlds.) If you wanted to use one of the cheaper, emerging countries (Vietnam comes to mind), you could probably build it for less than $500K.
For that matter, a dosmestic team in your own office could build it for at least half of the original price. Even cheaper if you “inshored” to a cheaper development shop in a smaller market. Finding a handful of college kids with a penchant for creating things is also an option.
What about scability?
There are some who would scream that PHP isn’t as scalable as J2EE. To those people, I simply say fire up your web browser and go to “yahoo.com.” Is it fast? That’s PHP. People who claim PHP isn’t scalable simply don’t know how to scale a PHP application.
MySQL was certainly not scalable a few years ago, but they have made tremendous strides in bringing their product up to enterprise levels (with the added functionality around replication, transactions, clustering, etc.) These days, I have no problem deploying MySQL 5 in a production environment.
Friendster has scaled to north of 40M users using PHP and MySQL. That represents about 39.9M more users than most startups have right before they crash and burn. :)
Why the big difference?
For starters, I should point out that a great many vendors really pumped up their prices in the 1.0 days. Thankfully, the days of billing out a fresh-faced college graduate as a technical resource for $300/hour are long gone. This clearly played into those inflated costs. Everyone was going along for the ride. The “get big now” pressure from investors also added a “kerosene on the fire” factor as well.
The passing of time has also helped. Time has a great knack for putting downward pressure on costs, especially when the environment becomes hypercompetitive.
Open source/GPL tools have continued to develop. They are at a point now where they are viable at the enterprise level. Additionally, they have matured to the point where they can signficantly reduce the amount of effort required to create something from scratch. There are exponentially more freely available libraries, tools, and canned solutions than was available just a few years ago. Back in those days, you had to either create things from scratch (and hope you could reuse them later for other things), or open your checkbook and pay for the best vendor-peddled solution you could find. No more.
Additionally, the bursting of the bubble forced the “rackets” to shift to being pure commodities, and driven more by corporate consumers. Hosting is the big example of this. The benefit here has been better service and lower costs from hosting providers.
Hardware has evolved to the point where an entire rack of horsepower five years ago can fit into a single 4U space. Pricing has also fallen to the point where even the lowliest startup can afford a serious array of horsepower. Illustrative of this point is that for the price of our original hardware ($130K), you could actually launch many Web 2.0 type plays, at least in an initial beta state!
The continued evolution of Linux has also played a tremendous part in all of this, and it shouldn’t be overlooked. Over the years, I have used OS solutions from Microsoft, IBM (AIX), HP (HPUX), Sun (Solaris, SunOS), etc. None have played such an important role in helping startups watch their bottom line, and put serious firepower online more than Linux. From price (free) to scability to POSIX compliance – you just can’t beat it. If you are a startup, and you are building your solution around costlier platforms, you are simply wasting your money, or worse, the money of your investors – period – end of the story.
The offshoring revolution has certainly played a key role in the lowering of labor costs – no doubt about it. And given that hourly rates from India have gone up dramatically over the years, we are moving into a second wave of offshoring. We are seeing CMMI Level 5 shops popping up in places like Vietnam. The decentralization of the labor market through places like odesk.com and elance.com have also played a hand in things.
Not much to summarize really – it is obviously cheaper to get things done these days, and there are lots of valid reasons as to why that is.
To circle back to Fred Wilson’s original post – the reduced technology-related spend is not a panacea for successful startups. As Fred points out, eventually, the capital requirements to build a sucessful company come full circle. However, you can definitely take advantage of certain trends to substantially lower the slope of the spending curve – which obviously assists you in controlling your burn.
I don’t think anything amazingly profound or prophetic has come out of this post, but it was fun to put together. Hopefully, you enjoyed it and found it of interest.