Tag Archives: launch

LinkPeelr: Wondrous Journey from Weekend Project to 3000+ Users

LinkPeelr has been fine and dandy. So fine, in fact, that I feel a pressing need to tell you about its progress. This is a long post — sit back and enjoy!

When I started on LinkPeelr I thought it was a neat and compact idea, and a small enough project I could actually tackle myself. I ended up launching LinkPeelr after 3 weekends of work, but I never intended for it to evolve far beyond the small project that it was. From day one I viewed it primarily as a “pipecleaner”, an app that could help me test my own ability to go from problem to launch and prepare me for more ambitious things that I’ve had simmering on the back burner.

LinkPeelr was a first in many categories. It may come as a shock but it’s the first “complete” piece of software that I wrote from scratch (all 122 lines of Python and 507 lines of JavaScript). If that’s not shocking enough for you, it’s also the first piece of software that I wrote that now has thousands of users whom I’ve never met and who don’t know me and who voluntarily choose to use this software.

Needless to say LinkPeelr has quickly outgrown its  purely experimental intent, managing for a few weeks to eclipse everything else I was thinking about and working on. This period has been a period of rapid learning, and something that I enjoyed immensely. Although I obviously set out to make LinkPeelr a learning experience of sorts, I never anticipated that this learning would come at this pace and intensity.

What follows is an account of what happened after I launched LinkPeelr, and what I’ve learned in the process. After hitting 1400 words with this post I realized that “what’s next for LinkPeelr” section had better come in its own separate write up.

Continue reading


LinkPeelr: A side project to the side project

LinkPeelr is a URL expander that takes a URL and peels it to show you the URL that you will actually be taken to. It took me a Friday to design the logo (I am a complete Adobe Illustrator noob, so be charitable) and the weekend to layout the one page, test the app and deploy it on Google App engine.

The next two weekends were spent polishing Google Chrome extension that makes peeling possible for any link on any page (shows the resulting URL in a nice-looking tooltip). Altogether I ended up being a rather nice-looking, compact project.

Continue reading

Make your bootstrapped startup work

Note from the author (added 29/9/2010): It seems that some readers found this post a little too opinionated for someone who hasn’t yet launched. I’ve tried to address your legitimate feedback in the comments here and on Hacker News. I’ve also done some toning down on passages below.

Don’t waste your precious pre-launch time like we have has been so well-received that I decided to expand on the topic and bring you a few more tips from the hapless entrepreneurs behind yet-to-be-launched just❤liked.

Get something online fast

It doesn’t matter whether you call it the launch, the beta, the alpha or something else. It’s absolutely critical that you make your app (some version of it), available online as soon as possible, and this is something we didn’t too well. In retrospect it seems that ideally we would have put something up within 1 or 2 weeks after nailing down the principles and definitions between ourselves. I’d be as aggressive as possible about this milestone and hold yourself accountable for missing this first and, in my view, the most important of deadlines before your real launch. We too should have been harsher on ourselves slipping that deadline.

Why do I insist so vehemently on having something online as soon as possible? Well, having something online gives you an entirely new perspective on the app. This may seem totally counterintuitive because development environments often do good enough job of emulating what the online experience will be like.  And yet they are not the real thing, especially if your application is a multi-user one.

Many things (e.g. image pre-loading, web copy and messaging, and analytics) you will never plan for unless you’ve gone through the exercise before, and you would be well-served by giving the task of getting online fast the highest priority possible. The approach is also consistent with “iterate like mad” mantra. You can’t iterate without the first iteration. This actually reminded me of the way mathematical induction works. If you don’t have it proven for N, you can’t prove it for N+1.

Avoid Sophisticated User/Customer Acquisition Schemes

I know how tempting it is to make the alpha, the beta, the theta, etc. exclusive for a select set of users, priming your customer acquisition pipeline and virally spreading the news of your glorious app to the rest of the Internet. Yes, it sounds great, except you are a bootstrapped startup with very limited resources to spare on marketing and promotion. We too got a little carried away entertaining notions of viral growth while we should have focused on getting the app online.

If you are a starry-eye entrepreneur like myself and your user acquisition strategy is based on creating artificial scarcity, STOP!

This is domain of funded startups with connections. Chances are you are not going to be able to pull it off just on your own unless you are incredibly well connected (but then you are probably not bootstrapped). More importantly, if you get carried away with your scarcity generation, you’ll soon find out that you are creating scarcity around vaporware, which is a far worse situation to be in when you are trying to build trust around your name and product.

Keep in mind that scarcity doesn’t need to be generated: it’s inherent in every new product, and it’s the scarcity of user’s attention.  I recommend to just open it up to all. Surely, nobody will come, but solving this problem is much easier when you already whetted it against early adopters and have something to iterate from.

Limit Conceptual Discussions and Long Term Planning

It’s important to agree on the basic principles of the application and to define the important terms that you will be operating with for the duration of the project. This will ensure that all involved operate with the same vocabulary. We’ve been bitten by this couple of times while working on just❤liked. Trust me, redoing things just because you misunderstood your co-founder is not fun.

I don’t believe it’s a wise use of anyone’s time to make plans that stretch beyond  MVP. Sure, you may have a notion of how you want it all to turn out in the end, but it’s best to keep that notion to yourself until it morphs into something else or goes away. Because it most certainly will.

Your primary focus should be on building something crippled and putting it online. Make “crippled” a requirement if you must, just get it done. Anything that distracts you from this task or derails your efforts is counterproductive.  Don’t belabor the evolution of the product until you have the first version and your opinions and speculations about the target market and user acquisition strategy are a little more informed.

Don’t waste your precious pre-launch time like we have

It’s amazing how little you have to know to dispense startup advice, so take this one with a grain of salt. I am only speaking from the position of having worked on just❤liked for about 9 months without much to show for it.

Looking back at these 9 months  it’s patently obvious that we would be in much better shape now if we prioritized some things differently or skipped them altogether. Here is your chance to learn from our mistakes.

Continue reading