How I built a profitable bootstrapped side project.

I often wonder with the amount of creative, talented people on the web, why there aren’t even more startups and software products. Over the last 13 months I’ve managed to build Deckchair on my own from the ground up to profitable, entirely bootstrapped.

I’ve detailed a bit of my advice that I would give to anyone who is considering getting started with a side project of their own and a few bits I learned on the way.

Find the time.

The main complaint I hear from friends more talented than myself is this

I don’t have the time to create something.

Peter Shankman wrote a great article recently on that topic:

We all have the same hours in the day as Beyonce. You have all the time you need. You always have. You simply have to decide how you want to use it.

Personally for me, I made some additional time. I decided to quit some stuff. Tuesday football practise was swapped with some coffee shop working (see part 2). Rubbish TV was replaced with my laptop in lap. I set time aside every night to spend on it. You will have to make sacrifices, but they don’t have to be massive. The journey of a thousand miles begins with a single step, and that thousands miles begins with making a conscious effort to do, rather than a tired excuse on how you don’t have the time. If a soldier deployed in Iraq has the time to code.

So do you.

Get into routine

The more time you make, obviously the faster your progress will be, but don’t be disheartened by only getting small amounts of time each day. Getting your work outside of work into some sort of routine is important. I found it particular useful to get into the zone by going to Starbucks every evening after work. Decent headphones are a must, as even coffee shops can get busy. This old post was representative of some of the playlists I found for concentration. You’ll not get distracted by things you need to do at home for a start, and it also helps you get into the zone quicker.

Buy the skills you lack

When you are starting any new project, its going to look like shit at the beginning. Once you’ve done a few sessions of coding, it’s still going to look like shit. I found it useful to buy in some graphic design bits in the form of templates to get over the initial hurdle of looking at my project and thinking it looked a mess. As Deckchair is built on top of the Bootstrap framework, this was pretty easy as there are loads of marketplaces out there for designs. WrapBootstrapAgileUI and ThemeForest are just a few links and there are a few open source templates out there too for free. I was lucky enough to have the skills to also wack together a logo and adjust a few things in the theme I bought, to change it into something I was happier with. Ultimately going down this road at an early stage allows you to produces something with a level of quality at a price that you wouldn’t ordinarily get without hiring a professional graphic designer. I’ll probably do that at some point, but when you are bootstrapping, every penny counts.

If you are a designer, and not a developer you have the ability to create beautiful interfaces and UI kits for every facet of a web application. That is an amazing skill to have. Whilst that won’t ‘make it work’ it may be enough to create a prototype of some sort to approach a developer to give you a hand with. You have an idea and a look and feel, and that counts for a lot more than ‘just an idea’ as it shows a level of commitment.  Nobody said that a good MVP must be a fully coded, working product, but it must describe your idea well enough to sell it. If Buffer can do it with just 2 simple web pages, then so can you. My point being make use of the skills you have, hussle to fill the gaps.

Validate Your Idea and build a list

Validating your idea before you start building something is smart. I wasn’t so smart and launched straight into writing code. This is something I didn’t do, but wished I had. (Although I had a fair idea there was a market for the product). A landing page setup before shipping would have been a sensible move, just to get people aware of the brand, and interested prior to shipping something. There’s a couple of decent sites for pre-launch products I could have utilised to build a decent email list and have been kicking myself for not going down this road.

  1. – Specialises in pre-launch products and startups
  2. – Accepts pre-launch into their submission list
  3. – Gets early user feedback on what you are building

Rookie mistake for not setting up a landing page, consider solutions like LaunchRock exist to get going super quick.

Use a Framework

So you’ve validated the idea and are ready to knuckle down and start coding. I don’t care how talented a programmer you are. If you want to sit writing boilerplate code for database CRUD – knock yourself out. But in six months, instead of building out the core of your offering, you’ll still be writing the bits and pieces you can up and running with quickly with via a framework. Data Access layers and Utility classes are necessary in pretty much every application, so go find a framework that is going to do that heavy lifting for you.

Stay Motivated

Staying motivated is tough, and self doubt will set in. A few doubts I had when building Deckchair.

Maybe what I’m building just isn’t good enough to compete.
Maybe a one person startup will get crushed by someone else’s marketing budget
Maybe balancing work with a side project is a terrible idea and I’ll burn out
Maybe its unfair to ask for so much time from others to dedicate to this
Maybe there’s not enough features to ship yet

Your doubts will likely be similar, and you’ve probably had problems staying on track and continuing to thrash out the first version of your product. I found it useful to have a checklist of things that I needed to do, and stuff that I’d completed. A simple Kanban board of achievement with Trello is my current way to stay on top of what needs done. Here’s what that looked like:

TODO > Bugs > Improvements > In Progress > Complete


Doesn’t seem like much, but moving stuff to the complete column, and watching the TODO column getting smaller was and continues to be a motivator. I also posted the odd screenshot of the application as it progressed to Instagram, with the hashtag #onemanproduct – this public display of something added a bit of encouragement from others, and also helped to provide some feedback on certain screens.

I point blank refused to register a domain.

Buying a domain is the online equivalent of telling people about your project, so having an idea for what domain you want, and NOT buying it, actually has the inverse effect, in that you’ll be constantly thinking that someone else may purchase that domain. It freaks you out, makes you work faster, and gives you a goal to work towards. Seems counter intuitive, but it worked for me. If the worst comes to the worst, what does it take to rebrand before you launch? A new logo and a fresh domain. Arguably tiny details in the grand scheme of things. A great brand is much more than a fancy domain name.

Beta Test

Somewhere between parts 7 and 8, is the graft. The churning something out every day, and watching your project grow bigger, better and stronger. Eventually, you’ll look at something and think it might just be ready to launch.

Here’s what I did.

Grab some family and friends, and tell them you need some testers, setup some scenarios and try and find out what they like, what they don’t like, where the potential bugs are and overall, whether it is actually ready to launch or not.

Before focusing on customer acquisition, you should collect real-user feedback and ensure your product is bug free, otherwise you’ll end up spending money onboarding people for them to churn pretty quickly. Cross browser testing is a must, as people are going to be using your software on a whole host of devices. Browserstack on the Freelancer package is what I’d recommend. Although CrossBrowser Testing is arguably a quicker solution, Browserstack wins out on cost, which when you are bootstrapping, every penny counts.

Once you are satisfied with that, you can start looking at opening your application up to others. There are a few places around the web dedicated to finding you beta users:

Reddit has a few dedicated subreddits which are relevant to anyone looking for beta users:

/r/startups , /r/imadethis/r/alphaandbetausers/r/betatests/r/shamelessplug

Put together a Marketing strategy

If you haven’t worked out exactly how you are going to successfully distribute your product, then you are pretty much screwed before you begin. I’m going to go out on a limb here, and say if you are relying on Product Hunt and Hacker News to send you all your traffic, you are still screwed.

Distribution is of massive importance. So you have to work out where your customers are online, and where to reach them. The road I went down was to piggy back off other successful startups using integrations as a channel. Slack have a boat load of customers, so why not build something for their application directory? Everyone’s favourite poster boy at the moment is Slack, so I decided to build a simple integration. I mean how cool would it be to get a message via a Slack channel when your holiday request is approved?

When the app directory was launched, I was lucky enough to get approved in time for launch, so straight away there was a PR angle that I was able to capitalise on.  Hello traffic. Not to mention the kudos of being listed alongside some other amazing companies.

I also created a spreadsheet of places to submit Deckchair to, most of them are startup directories, and I worked my way through the list checking them off as I went. Some of them sent good traffic, some not so much, but the ones that didn’t send much in the way of customers are worth having for the SEO boost that you get from it.

Get Your First Paying Customer

There’s nothing quite like the excitement of someone elsewhere in the world using your product, even if they are just in the trial process. My first paying customer came off the back of a reddit thread from someone looking for an HR product. They were aware that it was something I had built out myself, so they were also willing to give good feedback to me directly on how the met or did not meet their needs. You need that feedback direct from paying customers to help shape the features to get to market fit, so the sooner you can launch and gauge whether something is working or not for someone, the better.

Get Feedback quickly

One of the things I would have built out more extensively, with hindsight, would have been my user flow for the on boarding process. I shipped the product with no reminder emails that free trials were going to expire a couple days before, nor did I have any way to use the people who signed up but didn’t buy to get feedback.

When you are getting started, one of the most useful things to know is why people aren’t buying, or what features are missing that they would like, or what you can do to turn a trial customer into a paying customer more quickly. You get that feedback, modify the product and iterate until customers are really happy with the product.

Whilst this is done largely with emails now, I found a good friend in the chat tool – completely free rather than Intercom which is a paid for solution that I couldn’t justify at the start – this allowed users to give feedback within the app directly, when questions were more pertinent to them.

Once I did that, people started to open up with conversations with me directly. Once I started having the odd email conversation, people felt more comfortable to buy.

Trust your gut on product direction

Once you start getting paying customers, the real features you need will start popping up pretty quickly, and they’ll be quick to tell you or ask questions e.g. ‘Does it do this?’.  You have to trust your gut quite a bit at the start to figure out whether the features people ask you for are just for them, or apply to lots of other customers too.  Often a pain point for one person will be the same for someone else, so prioritise those features over everything else.

Don’t give up

If your project is of a significant size progress can be slow, but 1 hour a day over the course of a year = 365 hours. A typical work day is 8 hours, so that will be about 45 man days by the end of year one. That’s more than enough to get a MVP built and out the door. Obviously how much work you put in is up to you, and the above calculation is for illustration but you can see how quickly consistency translates to significant time.

It is also easy to think that all the hard work you are putting in to support a relatively small customer base for relatively little revenue might be a terrible idea. I’m glad that I stuck at it, as things for me started to snowball pretty quickly. Keep your head up, and eyes down and keep coding.


Leave a Reply

Your email address will not be published. Required fields are marked *