David Gary Wood

Planning as an indie developer

August 5, 2016

Erik Person blogged here about planning:

As an indie for two months now, I realize I’m not taking my opportunities to plan like I should. This is a reminder to myself to spend a little extra time planning before tackling a new feature. I don’t need to write down the plan or show it to anyone, but the act of planning will be a significant boost over what I’ve been doing lately.

I am two months into my own indie journey also, and I can relate to this very much.

I plan. I have plans for where I am going and what I am doing… But. A lot of this remains in my head. It stays there until eventually I’ll end up knee deep in too much work. At this point I usually remember to take a step back and go into planning mode.

When I was juggling a full-time job I had to have a proper plan written down. Stepping through it bit by bit was part of how I managed to get my own things shipped in evenings/weekends.

Erik’s post is a timely reminder for me. I have a project I want to get shipped as soon as possible. Whilst I know I’m making good progress, sketching out the key stepping stones and blocks between now and launch is something I really need to sit down and do.

I will probably fall back on the method I’ve used for GoVJ and HoloVid .

This consists of:

With a pad and pen:

Write down all the key features and functionality for V1.0.
Write down how I want to market and launch it.
Write down plans for key beta testing milestones.
Type these lists into a spreadsheet and put each list into order of key milestones on the path to release. If something can’t be done before something else, then that dictates whether its comes first or not.
Estimate time in days or hours for each item on the spreadsheet, along with which week each item is - being completed in.
Look for concurrency within the marketing list and the development list activities.
I think concurrency can be important to getting things done solo. What I mean by this is that marketing activities should not be happening after the app is made available in the app store. They should be planned at the start of the project, and begun ahead of the release date.

Some marketing activities can be done in small segments at times where I may not be at my best for coding. For example: I drafted copy for the App Store and my mailing lists whilst on lunch-breaks in my old job and saved them to Evernote. Whilst also saving me time, this has given me a nice browsable copy of everything I did for launch (and beyond) for these things.

As the lists are worked through, I keep a separate spreadsheet tab for logging bugs and crossing them off. Closer to release this list needs to be as close to complete as possible. It’s important to keep in mind whether a bug is really show-stopping or not. If it affects the user, then yes it is. If it only affects my desire for the app to be perfect then it may wait for the next release.

So why haven’t I done this yet?

I’ve been procrastinating on doing this for this project. I suspect my main reason has been that I haven’t had to do it. Being obviously time-poor in my old life pretty much dictated some level of organisation just to get anything done.

So now I know what I’ll be up to this weekend. Cheers for the reminder Erik!

Let's get in touch

Drop me a line.