Tag Archives: bootstrapping

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.


Startup – the anxious business of business building


There are many possible motivators for starting your own business. Whatever they may be it’s still a viable business that you are after. It’s not a hobby or a diversion or a side project, it’s building a business that is the ultimate goal behind starting a startup. The other goal, one that is no less important, is to learn as much as you can about business building itself.

It should come as no surprise that when you set up on your startup journey, you set off with a set of proposed assumptions and inherent biases that you then work to prove.  I claim that proving existing assumptions wrong and finding new patterns that have no prior assumptions attached to them have different emotional implications for the founders. Even though “customer development” and “validate everything early and often” are all the rage, we still tend to hold our assumptions and biases as something deeply personal.

Well, last week brought a sobering of sorts. The assumptions that my co-founder and I have considered provable have come under harsh scrutiny of an outside expert, someone I trust and someone who has a solid track record of success and beyond-doubt credibility in this space. You may call it a watershed event, a cold shower – as my cofounder called it, but it was certainly, in its immediate aftermath, a source of great anxiety, concern and new doubts.

We heard the feedback, but we decided to keep going because we still believe we are working on something worthwhile. Expert opinions are expert opinions, but they lead to no revelations. Learning leads to insights, and if it takes another couple months for our users to second the expert opinion it would carry that much more weight in our minds. I think the users should be the ultimate judges of our undertaking. Also, it is my sincere hope that engaging with users will lead to more insights than a simple thumbs up or thumbs down from an expert.

Are we as surefooted as we were a couple of weeks ago? No, of course not. We always had very little surefootedness to speak of. Are we ready to throw in the towel and turn the project that we thought was a business into a hobby? No, that’s not what we intend to do either. We still feel that justliked was worth starting both for the sake of the learning experience it affords and as a business we believe in.

Keeping it frugal (or running a startup on less than 25c a day)


Ok, this is how frugal we are. Consider it a part of the overall leanness assessment.

Currently our total monthly bill is $6.30.  This goes to assembla.com for hosting of our project code base, tickets, release plans and time tracking (Disclaimer: I am not affiliated with them in any way, but no complaints so far).

Other things we use:

  • Fee App Hosting – Google App Engine
  • Free Document storage and sharing – Google Docs
  • Free voice calls and video conferences – Skype
  • Free blogging – WordPress

The next “big” expenses will be the domain name(s) and a real Google Apps account.

Getting to alpha will cost a total of $200-300 excluding the cost of labor. :)

Building a Chevy


I think it’s a pretty intuitive and natural idea to start small. My first real boss used to say: first build a Chevy, then build a Cadillac.

We are still firmly in pre-alpha era, building our Chevy, but during the first couple of rounds of discussion there were may be 50-100 tempting features that just sneaked onto the product backlog. Writing them down then was perfectly fine, as long as we didn’t also try to cram them all into alpha (or even beta).

I think the key has been finding the minimum subset of functionality that could be demoed to other people not familiar with the idea. This subset is probably half of what you think it should be, and it takes a certain objectivity and discipline to throw out all the bells and whistles. We settled on getting the basic flow of the application and a few main screens in place. The main requirement was to capture the idea , and not even try to build a prototype (that’s beta). This would be all there is in scope for alpha, and that would be locked until after we show it to a few people. So far we managed to stick to the plan pretty well.

The rule is “once we get the first round of feedback, we can unlock the scope”. And then it’s iterate, iterate, iterate.