Building a company in 42 days with 40 dollars

Introduction

I worked on DevTest on a total of 42 seperate days, over a period of around 6 months. This was all in my spare time during evenings and weekends, with the exception of a week of vacation to finish everything up and finally launch. And the only money I've spent so far has been $40 on hosting charges. A lot of those 42 days I only did a small amount of work; I think that if I'd been working on it full time, without taking long breaks between pieces of work, I'd have been able to do it in 2 months.

In this series of blog posts I'm going to explain some tips and tricks I used to make this possible. A large part of being able to pull off a feat like this is experience and practice, and having been programming for around 20 years in one form or another has made me able to get things done quickly, and a sense of what will work and what won't. But here I will try to share some of that knowledge and hopefully some will be useful for others.

Micro agile

In the past I've worked almost entirely in agile development environments with a focus on SCRUM. I'm wouldn't say I'm a "true agile believer", but it's a good tool to know and understand. For this project, I've been using what I call micro-agile. It's based on SCRUM development but cuts out almost everything because it's irrelevant when you're working solo. Doing this has helped me to keep focussed and stick the minimum viable product.

Trello

I've used Trello to manage my todo list, it's amazing and free and above all simple. Before finding this tool I'd have said anything more than a pen and paper was overkill. Pen and paper is still fine, but Trello is simple enough to not get in the way and slightly more convenient than carrying around your list everywhere with you.

Planning a sprint

You should have one "product backlog" board. Use this as a dumping ground for new ideas. I had three columns, "Essential", "Post Launch" and "Inbox". New ideas go into the inbox. Simple.

Example product backlog

Now you need to plan your first sprint, this is what you'll need to do every 2 weeks or so:

1. Brain dump into the inbox. Just put every little thing you can think of in there.
2. Sort into Essential and Post Launch.
3. Prioritize the "Essential" column by what's most important.
4. Create a new board for your first sprint, with these columns: "Sprint backlog", "Specced", "In progress", "Done". Call this board "Sprint 1"
5. Move an item from the top of the prioritized "Essential" column into the "Sprint Backlog" column of your sprint 1 board column. Repeat until you've got as much work as you think can be done in 2 weeks.

Example sprint board

Executing a sprint

Now you have a prioritized, realistic list of tasks that you can plug on with one by one. Recall you have 4 columns on your sprint board, "Sprint backlog", "Specced", "In progress", "Done". At the moment everything should be in the backlog column. Now it's time to spec it out. Add a checklist to the first card in your sprint backlog, and try to flesh it out in more detail. Here's an example of a checklist for the candidate login feature:

You can move that card into the "Specced" column when you're happy with the requirements. You should try to think of all the requirements for this part up front, although this isn't always possible. The idea is that once you've specced an item, actually building it is just automatically following a list of checkboxes.

Not rocket surgery right? It's just common sense. But it really helps to have a simple process. One of the problems I find as a developer is that I easily get distracted and procrastinate. Having a mechanical process to get myself back on track when I've lost focus is essential.

Standups

Standups in a full size development team are great for getting everyone on track. I found I missed this on my own, so I faked it. Whenever I had a block of time to work on DevTest, I'd start by looking at the current sprint board, and doing it in a different location I was working, and looking at what the next task to do was. Usually this would be downstairs in my living room. I'd do this until I got excited about building the next feature and couldn't wait to get programming, and found this helped again with motivation.

What not to build

The most important thing I can tell you is that you must be really, really ruthless in throwing out ideas, or at least pushing to post launch. There's so many more features, countless enhancements that I really want to add, and wanted to add before I launched. You have to ask yourself if it really matters. Really? Are you sure? I threw out a tonne of features that I though I needed. Not just big ideas but simple, basic things.

Do you really need to implement pagination in your backend? Not until you have customers with unwieldy lists of stuff, and that's not going to be for a while after launch most likely! Do you need an admin backend for yourself? Not if you're a programmer, just use the database console. If it starts to piss you off you can write something at that point to fix it. All of the assumptions that you have if you've been building software for other people for most of your career are now open to questioning.