A couple of days ago I listened with empathy as a passionate entrepreneur told the story about bootstrapping his business over many years. Like many other entrepreneurs in his situation, he had to repeatedly make micro-optimization decisions that got him to the next month knowing full well that he’d do things differently if he had more resources at his disposal. Short-run vs. long-run trade-offs are the way of life in early stage companies but they also carry consequences. One of the key qualities of great entrepreneurial CEOs is the ability to make these trade-offs in a fast-paced uncertain environment better than their competitors’ leaders.

Sometimes, trading speed and efficiency now for cost and effort later helps startups reach some form of initial scale which buys them either enough capital or time to fix things before the next stage of growth. Other times, the same repeated trade-off puts them farther and farther behind the 8-ball. Nowhere is this more visible then when a product (or site) has to go through a major re-architecture (re-platforming/redesign).

Have you heard about Amazon’s latest re-platforming project? No? Not surprisingly since Amazon hasn’t had one of those… Great products/sites can evolve and take on best-of-breed capabilities/technologies in a way that’s almost transparent to their users. Amazon is a great example. The site is constantly being worked upon by lots of people. WordPress is another great example, showing the power of the open-source community. Good products/sites can be re-architected or re-platformed with relatively benign levels of user disruption. MySpace is a good example. MySpace had to significantly evolve their initial architecture (a web site built on one ColdFusion server) to end up where they are now. Others, say, the first-generation Friendster and many e-commerce sites, make it painfully obvious to their customers that it’s taking them too long to evolve & improve. Some die in the process.

A common pattern I see is that many successful technology companies have figured how to use what I like to call fluid architecture to manage the balance of trade-offs between the present and the future. Fluid architecture is not just about software. The core certainly is about good software architecture but there is also a continuous improvement process component and a cultural component. The cultural element has to do with two things: (a) a mindset of ongoing, explicit, open and honest discussion about the trade-offs that are being made and their future implications and (b) a commitment at all levels of the organization (not just inside the product group) to not end up behind the 8-ball. Companies that embrace this broader concept of fluid architecture can rebuild themselves on the go and move at the pace of today’s business.

My personal experience with fluid architecture has been very positive. For example, every major release of ColdFusion between 2.0 and 7.0 required re-architecting large parts (20-90%) of the server core while preserving 100% backward compatibility. ColdFusion 6.0 (a.k.a ColdFusion MX, which was the first release after the Macromedia acquisition) was a complete, from the ground up re-build on a Java as opposed to C++ codebase. Those were great examples of fluid architecture at both the product and at the company level. Our technology was excellent but we had done a number of things wrong initially–easy to do when you are the first Web application server and have nothing else to compare yourself to and you bootstrapped on $18K. What we did have, however, was a focus on continuous architecture improvement. We had lofty goals for the company and knew that great architecture would be the basis of our ability to evolve ColdFusion both for itself and to serve as a base for other products (anyone remember Allaire Spectra?). We also had the fortitude to break the bitter pill in pieces and take smaller cost/timing hits release after release so that we never had to take the bitter pill all at once.

Which, in a roundabout way, brings me to the second topic of this post. ColdFusion 8 won the Jolt Award for Web Development. I find that pretty impressive for a product that defined the category back in 1995. Remaining relevant–let alone cutting edge–for such a long period of time is something very few products achieve. The reason, I think, is more than a decade of commitment to fluid architecture.

Fluid architecture is ever more important in the Web 2.0 world of quick and cheap experimentation where prototypes overnight become production web sites after your blog post about the private beta makes it on the front page of Digg.

It is fair to say that we are in a Renaissance of the Web Hacker (v2.0). (The main difference with Bubble 1.0 is the the Web 2.0 Hacker listens to KanYe West while the Web 1.0 Hacker listened to 2Pac. Well, there is AJAX, Web services and a few other bits and pieces but they are less important.) One of the issues I consistently find with some of the startups I’m seeing these days is that they are making important trade-offs about technology, product roadmap, user experience and go-to-market implicitly as opposed to explicitly. That is a core violation of fluid architecture principles and, potentially, a recipe for disaster. Invariably, when I start a discussion on this topic, the team tells me that this is not a problem because they are agile. I beg to disagree. Agile development by itself won’t prevent a company from risking its long-term success through a series of convenient short-term decisions. Embracing a fluid architecture approach in addition to all that Web 2.0 technology goodness is one way for startups to better position for success.