The journey of a London startup, what I learned when my company failed

(Background: Microcosm was a community CMS as a platform and service, a Tumblr for forums. It allowed non-technical people to create and run a community site that would comfortably scale from small groups of 50 people to very active communities of 50k people. No technology knowledge required, if you could set up a Tumblr or use Twitter then you could run a community. We took care of everything so that communities could get on with the business of nerding out over their shared interest.)

When the end came it was the hardest decision, we had failed to raise the capital we needed to continue yet our customers loved the product and our user numbers still improved daily. Critically though, the bank account was nearing empty, and none of our graphs were hinting that a hockey stick growth curve was going to appear any time soon. So with the heaviest of hearts we had to concede in the only metrics that mattered… we had failed.

Getting Started

We had set out in 2012 to fix forums. Despite their resilience in the face of social networks, they had stagnated and were long past their sell-by date.

To run a forum meant getting a hosted machine, installing the forum software (usually phpBB, vBulletin, Simple Machines or Vanilla), and then taking on the responsibility of being a systems administrator and full-stack web developer. To non-technical people this is almost impossible, but if they followed an online guide and maybe mumbled the right magic commands into the command line then they might just have a forum set up by the end of it.

The birth of an online forum is the start of the decline, too few of those who managed to get up and running then updated the software, patched the security issues, made nightly backups. The forums would precariously exist until they by chance grew to the point that a volunteer from the community might save them, or they would self-destruct when the hosting hardware eventually failed.

The technology was both an obstacle and a mess, and we were going to fix that.

And whilst we were there, centralising things on to a platform that could run hundreds (thousands, millions!) of forums, we could fix the other things too. The competitors had all missed the move to mobile, the UIs almost universally insisted on a 10px Verdana font that was barely readable now display devices and resolutions had moved a decade on, and the interfaces reflected the cruft that accumulates from the lack of a coherent design vision.

The design was horrible, and we would fix that.

Then there was the business plan, where was the money? Most of the money in a community goes through classified adverts, small businesses selling to very specific needs, events that the community runs (sometimes ticketed).

In fact, communities had been successfully looted so many times that nearly all of the value of a community was held by external companies who only needed to run the small bit they cared about (eBay for classifieds, Meetup for the events, a media site for reviews). Forums had been turned into cost centres, yet they were also the very glue for the community. The vast majority of forums exist on donations from the community, even though the community itself produces a volume of trade that would easily support all of the costs involved and would produce a profit.

The monetisation of a community was terrible, the money left on the table had been taken by third parties that didn’t care for the communities themselves, and we would fix that.

Our pitch was, we would fix it all.

We raised our friends and family round via Seedrs. It started with a post on a forum, some sketches of an idea of what a future non-vBulletin forum might look like. The plan was to raise £30k just to see if we could get this started. Within 24 hours we had pledges in excess of that from people who wanted to invest in us rather than donate to us, and so we turned to Seedrs for a £50k raise (Seedrs use a nominee share structure to protect both investors and the company, with terms that are not objectionable down the road. They handle all the money and the legals). I quit my day job before the funds had hit the bank.

Version 1 — a pre-MVP

In early 2013 the investment was finally in the bank and I was joined by a former work colleague who became my co-founder, Matt Cottingham. We had a plan that our starting point would be the biggest missing bit, an API. On that foundation we would work upwards to the front-end and then ship an MVP based on that.

Lesson #1: We should have made an initial (bad) API really quickly.
Instead we actually spent a few months making ours, and in hindsight that was way too long. Well crafted APIs take a lot longer to create than one might expect and we aimed at a highly-consistent, documented API from the outset. The sheer number of subtle implementation choices and gotchas with cross-cutting concerns like caching, authentication, consistency of format and arguments is immense. It isn’t constructive to even consider answering most of the questions designing a good API asks of you, just find a good API example and copy their conventions and decisions.

We launched our MVP to a handful of early customers in May 2013. As soon as we did so the feedback arrived… it was great, and just what people wanted. That’s what they told us, but we were being told what we wanted to hear and the truth was plain enough… it was terrible, embarrassing.

It worked well enough from a technical perspective but it looked appalling. We launched with features that we felt would show how we were going to differ, not just that we were a platform and mobile friendly, but we had events!

Yes, an event… in a forum. Not at a global level in an external calendar, but on a site that is a forum such as Islington Cycling Club (one of our first customers) events could be created alongside the conversations within a forum itself. We had seen that forums on a community site always had distinct audiences and that the natural way to start competing against external competitors (Meetup) was to bring events back into the forum itself in a place that had the attention of the users.

We had created the notion that a forum within a site was a bucket of strongly typed things. A conversation (traditionally called a “thread”) was just one thing you could put in a forum, we added events and could then add other types in future: classified adverts, reviews, community wiki pages, blog posts.

Our early customers really loved this, but…

Lesson #2: Solving pains that your target customers don’t yet realise they have won’t help you sell your product.
It is true that every customer that used the feature loved it and felt it made a huge difference to the take-up of events and the overall engagement as finally all of their users saw events and didn’t have to authenticate elsewhere to register participation — but that didn’t help us sell. When selling the response was along the lines of “But we can just use Google Calendar|Facebook|Meetup”, no-one was actually feeling this pain as they had long-adapted to it.

The lesson we actually learned at this time was a different one, and it was also true: our design sucked.

How bad did our design suck? This bad:

As much as our technology succeeded, our design failed.

We had proven we could build something, and we had proven it would work and customers liked the functionality… but we hadn’t proven much more at this point and the live sites we had looked awful, just awful. Our initial £50k wasn’t going to get us a designer, and so we had to down tools and go back onto fund raising.

Lesson #3: When you have the opportunity to get investment, take the whole of that opportunity. You need more than you think you do.
We only raised £50k initially, mostly due to not wanting to raise more than we needed at that time. Once we saw how bad we were in some areas and needed further investment, we had to stop work to put the effort into raising funds. Loss of momentum hurts really badly. We could’ve raised £150k initially, not needed to go back when we did and have carried more momentum with us.
We made this error more than once, we were just about to make it again.

We raised a further £100k in a second friends and family round on Seedrs. This was launched on Seedrs and completed in 15 hours, and as we’d already done due diligence the first time around we knew what to expect and turned that around fast. What is never mentioned is that it takes 4–6 weeks preparation to do a crowd-funding round… socialising it, talking to investors, preparing the pitch, making a video, refining all of the above and synchronising interested investors in the moment that you launch the campaign. In total, this process takes a couple of months in the best case scenario.

With around £100k in the bank we reached out to our network, “Who knows a designer looking to join a startup on a permanent basis?”.

<Silence>

It turns out every designer out there is worth their weight in gold, knows their worth, and either has a well-paid position at an agency or is freelancing. London is not full of great designers who will come and work at your startup for a really low wage and some equity… the rents are too high for that. As we couldn’t afford to compete with the wage expectations we were left with the freelance route.

After an exhaustive search for freelancers, we hired Jim Lee of Height Digital . Chance had placed him in the same co-working space as us (and so we learned about him) and he had already read mention of us on Hacker News. We chose him as his portfolio of work was great and his skills were exactly what we were looking for — a good mix of pure design skills, as well as HTML5, CSS3 and JavaScript with a strong knowledge of template systems like Django.

Version 2 — MVP and Launch

Jim worked for us on a 4 month contract, and at the same time we also hired another developer so that we could respond quickly to the design work. One of the things that can really slow this process down is the designer waiting upon… anything. When Jim needed an API we would make it, when Jim needed customer feedback we got it. We ran focus groups, market research sessions, I laid down the vision and broke the work into logical pieces to attack.

In February 2014 we finally shipped the new design, and the event page now looked… better.

At this point we had a whopping 118 sites on the platform… which is a vanity number as fewer than half were being used. They were not being used much either, an average of 200 comments per day, and only 1,200 users on the platform. An average site had 4 comments per day read by 20 people. The old design had got us thus far and now we needed the new design to help us sell, and to increase engagement on each forum.

We made a decision that we would favour supporting an existing customer and preventing churn over chasing a potential customer, “A bird in the hand is worth two in the bush”.

Throughout the next few months, whilst continuously working on the product, we approached most of the UK cycling clubs, and small organisations like charities, resident groups and so on. What we learned was that we now had a product that the market liked, and that they would just need to talk about it at their next meeting.

Our target market are poor decision makers, by their very nature they are committee based structures.

Lesson #4: Get your potential customers to say “No” as soon as possible.
To sell to a committee you need to de-risk every aspect of your proposition and identify the key committee decision makers (if any!) and work out what will make them say yes. This takes time and costs you, however within some committees you will find a champion for you product and they will do this selling for you.
You need to determine whether or not you have that champion, sell it to them and give them what they need to sell it to others. But you need a “Yes” or a “No”, if they aren’t giving you this then push them harder even if the final decision is “No”. This separates the champions from those that just sound like one.

A minor pivot, from creating market to winning existing market

By May 2014 it had become clear that if we continued on the path we were on, we were going to fail.

The customers we had won were all new communities. This is a bit like being a startup whose entire growth metric was the sum of all other startups… that’s a very slow linear growth line.

Building a community is a slow thing, and we were a platform hosting many small communities each trying to find their first 10 users, to get those people talking, to be indexed on Google and attract their next 10 users. Our growth chart at this point was disappointing, it was barely above a flat-line. The numbers were improving day by day, but too slowly to make a substantial difference to our reality.

We knew that we had runway for another 6 months, and so we had a choice:

  1. Attempt to raise money now, based on a solid product but very poor numbers — a very weak proposition.
  2. Raise money later, and push to dramatically change our numbers in the near term — by working on an import tool and winning a couple of larger customers we’d have a stronger proposition.

We sought advice from some very respected London angels, and came away with the single view of “If you can import some large forums within a couple of months, do it… otherwise raise less money than you need now”.

We believed we knew precisely what you need to migrate a large community, and that it was simple, and that we could produce it within a couple of months. It’s easy right? You just need to export data from vBulletin to some neutral format, and then have some kind of tool to read that data and re-map it into Microcosm.

Much to my profound chagrin the moment we started this process it spiralled out of control.

In part because our Django front-end suddenly decided it would consume all of the RAM on those servers and bring our existing customer sites down. Every day we were not building the export and import tools, we were slipping a day and eating into our runway. To fully solve the Django issue we had to spend more time than we liked building a crazy level of monitoring. New Relic was an easy win, but we also needed to know how other aspects of the infrastructure and network functioned and instrumenting those took time.

When that was under control we discovered the next issue, our PostgreSQL instance (which was fine with all of our existing customer sites) now wasn’t performing well. The move from tens of thousands of comments to millions of comments… break things that once worked in unexpected ways.

We were no longer just writing an import tool, now we were optimising most of the code base to handle the sheer volume of data (whilst running an import our servers go from a new comment every few seconds to being saturated by a constant stream of thousands of comments for several days).

In September 2014 we finally migrated the first large forum from vBulletin, which was London Fixed-gear and Single speed forum . Upon completion it had helped swell the numbers considerably… except now we had another problem… our runway was no longer 6 months, it was barely 2 months.

Hitting the end of the runway

Our plan for the next year was to hire 5 people (two sales, one support, one Android dev, one iOS Dev) and to focus on:

  1. Selling what we have, onboarding existing forums using the tools we’ve built to do so
  2. Build native mobile apps as this was identified as the biggest thing that would differentiate us from competitors
  3. Add some of the other custom types, as many communities clamour for a better way to run classifieds (and there is money there)
  4. Add ticketing to the events, as several communities demand it (and there is money there)
  5. Increase our existing revenue

The revenue we already had came from affiliate links. But we only earned it when people made a purchase as a result of following a recommendation (link) on one of our customer sites. We wanted to improve the conversions of this, and as we already were embedding media (i.e. a YouTube video when someone linked to YouTube) our plan was to embed information about the linked product. Most affiliate networks have product APIs, or we could scrape item pages for Open Graph information, and we would make those links more attractive.

That was our plan, a £500k round which split roughly into 25% on sales, 50% on product dev, and 25% everything else.

Lesson #5: Never try and raise a round on less than 6 months runway.
We all know this, HN tells us again and again, and maybe we just have to learn it for ourselves. It takes more time than this, the people you want to speak to are on holiday, or have a busy schedule. It takes time to reach those people, it takes time to crawl your network. You can’t rush someone into investing today, so you’ll meet more than once, it takes time.
You should raise when you have time to raise, which is all of the time except in the last 6 months of runway.

Despite speaking to many angels, obtaining glowing referrals to others I failed. I failed to put across how much our customers loved our product, our incredibly low churn rate, the fact that we had a vision and plan for the future, that we had some revenue now and over 200 sites on our platform and 45k users.

I failed to obtain enough interest to seriously consider making up the difference with another Seedrs round, and now the reality was that we were staring down the end of the runway.

The next thing to do? Find a buyer! If we could exit we could hope to give our investors a return and we could make a claim that we’d been a success (even if, when measured by our own definition, this would feel empty). I failed here too. Not just in identifying potential purchasers, but our respect for customer data meant that Microcosm did not own the forums we hosted, instead we merely had an agreement to run them in return for a slice of the revenue generated. We had open-sourced most of our tech, and we didn’t own our customers’ data.

The last decision left to make: Was it possible for the company to continue as a zombie based on it’s linear growth, in the hope that it could trigger enough organic growth to turn it around? Could we go get jobs, leave the company ticking over, work on it in the evening and hope to turn it around?

Ultimately we have answered “No” to that question. It feels very much like we would be creating an enormous amount of extreme risk (the foolish kind), and delaying an almost inevitable end that would now be messy because there wasn’t the time to handle it with grace and respect to investors, and customers.

On Wednesday 15th October 2014, 2 years after initially starting on this path, we have instructed the administrators to begin the winding-up process. We hope to trigger the SEIS relief our UK taxpaying investors are eligible for as soon as possible, and to return the last of the money we have in the bank to the shareholders.

This all reads like “Startup 101”, this is everything we’d been told by every site that has anything to say about startups. Our fingers have been burned and we have learned through our own experience.


I’d like to take a moment just to thank, with all my heart, the people who believed in us and who gave us this chance: the investors. My mind was blown by their support and faith, and I really wanted to create a life changing return on their investment. I know people will say no to feeling this, as we all know the risks, but I let them down and I’ll carry that a while. A Seedrs announcement will be made shortly, and Seedrs will contact you to assist you in claiming your SEIS relief.

To customers who believed in us, and continue to do so, we never wanted to fail and leave you in the lurch and the only thing we have left to give is something that we couldn’t find a buyer for… our source code. I always hoped to open-source things when we had built a large platform, so that we could foster growth and new development. I’ll work to ensure it is open-sourced shortly so that you have continuity going forward. Each customer will be contacted individually in the coming weeks about how this impacts them.

To developers interested in the code, it will be available at https://github.com/microcosm-cc in the coming days/weeks.