The story of a startup that wasn’t

Put together on January 10, 2013 3:12 pm by Dimitris
What do you think?

Today the domain for a startup that we started back in 2009 expires – and I’ll let it do so.


CobaltBox started off with great ambition and a vision to become something significant – only it didn’t turn out as planned.

The idea was that we could use the web as a platform and include additional information on it – all in a relevant and contextual manner. Essentially, we aimed to allow web users would see the usual content of the webpage augmented by additional, personalised information brought to them with the help of other services.

So for example if you were reading an article on the economic crisis you would be able to see relevant Amazon book suggestions, similar Wikipedia article suggestions, YouTube video links and so on in a way that would enrich your browsing experience without leaving the website. Sounds pretty interesting right? Well, at least for 2009.

Plus, over time a user profile would be build so the information displayed would be even better targeted to the individual web user.

 On top of that we thought that we should open the project so that third-party developers would be able to use popular services’ APIs and write their own layers of information – web apps essentially – meant to run on our platform.  That way further user personalisation could be achieved: users would select which web app layers to see when browsing.


We went on to release the first such app – Parallel Links – a Firefox plugin (the architecture was such that at least initally web apps would be in the form of browser addons), which embedded additional links on top of a page.

Surely an ambitious plan with multiple (even if somewhat sketchy at first) revenue possibilities: affiliate links, ads, apps’ monetisation to name a few, all could be a part of it – plus a couple which were bound to come up down the road.

Although we spent nearly a year on developing both the backend and the frontend at the end of that period we realised that we wouldn’t get very far and gradually decided to abandon the project. So the least I can do is share some of the lessons learned in the process.

1. When you start you should be sure you can build – product-wise – at least 80% if not 95% of what you’re trying to make. Otherwise you’ll spend way too much time learning the tools and solving otherwise trivial problems. That time is something you simply don’t have especially if you’re like us where we didn’t have any revenue while developing.

2. Speaking of revenue, unless you’re super confident you can make it – preferably with proof for that, i.e. a previous successful effort – don’t postpone putting in place a way to monetise your efforts. In other words, it is vital to structure your progress from day 1 in a financially viable way.

3. Stealth mode is probably not that much worth it. Were we more vocal about our efforts maybe we would save ourselves of wasting some time or picked better tools or steered the entire project to a better direction altogether. Or we would be just taking instead of making and learning from our mistakes – which would also be wasting our time. Nobody can really tell but I think next time I will be trying the more open approach.

4. Build something that works as quickly as possible – the famous minimum viable product but at an even more simple scale. Namely, it doesn’t have to start paying for itself, it just needs to do something. In other words make something that works and can be shown to people – even if it’s buggy and half-baked. That helps a ton in getting actual feedback and boosting your morale you’ve actually delivered something.

5. There are many ways to do things wrong and only a few things to do them right. When it comes to technology the wrong ways are generally more obvious than the right ways. So if you’re not sure which is the right way of doing things (which tool to use, which architecture, which library, etc) at least avoid doing it in one of the wrong ways. If it looks like too much effort, if no one else is doing it that way, if you think it’s unlikely to work, if there seem to be steps missing (to be figured out later), then it’s most likely wrong and you should find another way.

These all are sensible advice you can probably read all over the web. The reason these tips are offered again and again is that it’s actually quite hard to follow. Maybe we’ll be wiser to follow it and other minor things that definitely went wrong.

Until the next time, then.

If someone is interested to have a look at our efforts, feel free to contact me and we can share how we approached the whole project.

Enhanced by Zemanta
tags: lessons



Leave a Reply - in English Please