Bootstrapping Elgg

In my twenties, as part of a two-person team, I co-founded and bootstrapped a social networking platform that would end up being used by organizations like Oxfam, the World Bank, the Australian government, the United Nations and NASA.

We did this with a budget of $0; I don’t remember ever buying advertising, and for the first few years the web presence piggybacked on my personal web server that was paid for (just) by other projects. We bootstrapped a business to support it, starting from scratch and eventually acquiring enough investment to hire a small number of other people to work on it with us. We were flown around the world to speak and support, and there are hundreds of companies today that make part of their income by selling Elgg services. I’m a proud benevolent dictator.

It only occurred to me years later that we took a very lean startup approach. The first thing we launched was a white paper for elearning professionals, that tied my social web experience with Dave’s elearning background. A classic minimum viable product. (The genesis of Elgg was as a platform for eportfolios – what we might now refer to as “profiles”, albeit designed to showcase skills and learning.) The response was so great – over 60,000 downloads for an academic paper! – that we released another, more specific paper. Same response. And so, fueled by a comment by an educator that “it’s one thing to write about it, it’s another thing to build it”, we made it happen.

Two early prototypes were built: one by Dave, in ColdFusion, and one by me in PHP. We went with the latter; PHP at the time was the world’s most popular web scripting language, and it was important to us that people could use commodity shared hosting to upload their communities.

At the core was a hosted version at elgg.net (long since gone), which we released six months before the source code. This turned out to be important: a central, hosted community made it much easier to test features, just as the open source community would make it easier to test APIs later on. Each time we tested a feature based on unfounded assumptions, we faltered. Each time we responded intelligently to our users’ actions and intentions, we saw growth. The key was that most features took a day to write. While some took a few days, or even a week, in the early days we released as early as we could. This was as much to do with limited resources as user feedback.

Example: there were no defined collaboration groups in Elgg, because we hadn’t included them in our original papers. It was only when users continually asked for them, and we spoke to sample users to figure out what they needed, that they were added.

The downside to this approach was that the code architecture developed in a very organic way. Which is to say that, three years later, it was a mess. So when we did acquire some investment capital, we took the validated assumptions and learnings from our initial growth period and rewrote the system in a more planned way. There’s a lot of advice out there that tells you to not to do this, and it’s fair to say that we took too long. But the result is a framework that continues to this day.

I miss working on Elgg sometimes. It was a vibrant open source community, and a very visible project. Bootstrapping the company was a rollercoaster, full of incredible peaks and troughs – emotional low points and high points mixed together in a way that was both stressful and exhilarating.

However, the current Elgg team – led by Brett Profitt – have arguably taken the project to a new level. It’s awesome to tune in now and then to see what they’re doing. It’s very much theirs now, and I’m very content knowing that it’s in such safe hands.