Top mistakes made by indie developers

For most businesses there is often a wealth of knowledge and constants out there to outline exactly what resources you need to achieve certain business goals. When someone choses to become an indie developer, they often don't have a detailed business model in front of them nor have done sufficient research to make great business decisions, in fact most don't change a thing in their work pattern form when they were just learning.

So what should a coder, designer, artist or all-rounder consider before going from enthusiast to full blown indie developer?

1. Plan projects based on your restraints and abilities - We often plan projects based on the desired outcomes we would like but this isn't always realistic. As an indie developer you need to consider the amount of time you have to commit to each project, your skill and how much that will slow you down or prohibit you from succeeding and the impact these restraints have on the game.
   
   A great example of this is "Flappy Bird", the developer said he didn't have a lot of time so he had to make a small, short, simple game. He also said he didn't have time to keep adding content so the way this impacted the game was he had to make it really difficult to generate longevity for the limited amount of content.
    
2. Set deadlines and milestone targets - If you were working in a big business you would have set timelines for all your projects and not meeting a timeline would have a negative effect on the business. It's easy as an indie to say "I have no real need to get it out by any specific date" or "It's done when it's done" but the impact can be big. You could be reducing your productivity by over 50% by not committing to a timeline. It also comes with other benefits such as knowing when you have to have the dialog ready to give to translators in order to get them back in time for release, plus producing localised marketing material. Reviewers will take you a lot more seriously if you can give them a date and you actually meet that date.
    
3. Plan your monetisation strategy from day one - Research business models and marketing strategies well enough to have a good plan to move forward with. Make a quick list of your products and services you can offer then start putting rough numbers next to them of how many you think you can sell based on marketing demand and do a quick calculation of your annual income. If it isn't what you expect to be making then rethink your strategy.
    
4. Plan to make money - In addition to the above, i know it is nice to give away software for free and get feedback but if you plan to have a business then eventually that business should be making money. Think of it this way, if you make enough money that you can quite your day job then you can spend more time making software and updating it and make your customers more happy. It's better for everyone if you are running a profitable business!
    
5. Be realistic - Rovio made over 50 games before they produced "Angry Birds", if you expect to get it right in the first year you will probably be very disappointed. If you expect to be rolling in cash in 2 years then (if you are good) you might be earning enough to get more equipment / software and produce better products but I wouldn't quit your day job. We are all learning, even the people who know everything about coding are learning, even the people who write programming languages cannot comprehend all the things it can be used for. Be patient. 
    
6. Be proud of your accomplishments - This tip is just from me, if you love what you do and love what you create, that love is often infectious and the community will get behind you and help support your products. You should also support your peers in the same way, some of the best developer friends I have are just people I've cold messaged saying "Hey, I tried your app you advertised on <forum name>, I really liked what you created because of <A B C D> and think you can improve on <E F G> but otherwise it was a great experience and I left you a review". People really appreciate community support and will most likely look at your apps and do the same for you.

Hope you find these comments helpful and as always leave a comment if you have anything you think I should add. I'd love to hear from you!

Peer review and beta testing is essential to all software businesses

I'm an indie developer in every aspect of the term 'indie', I'm not against working in a team, I love it in my day job but unfortunately there aren't many software developers in this town and even less available to sit down with me and let me bounce ideas off of them.

Sometimes being clever isn't enough, software is a marketplace where perspectives matter and getting as many perspectives on your product before dropping your MVP (minimum viable product) on the public is what can make or break your product releases.

So what can you do if you are like me and don't have people who can sit down and talk about your products readily available?

Beta testing!

It's not uncommon to perform beta tests within your small development group and yourself following good TDR (Test Driven Development) but there is so much more to a good product release than finding bugs, you need to find issues with your UX (User Experience).

How do I do a closed / public beta?

1. Pick a distribution platform - iOS has limited ways to you can beta test but if you have a way to collect UDIDs from potential participants then adhoc distributions are not that difficult and don't put too much stress on the participant. You can give them this website to make instructions easier. Look at other options as well, Test Flight has received good praise.
2. Get analytics - You can't rely on your beta testers to give you feedback, especially if you have never met them. Use a service like parse to feed back useful data such as how many levels were completed in your game, how many retries, how many error screens were presented, etc. 
3. Add a dummy payment system - In-app purchases need to be tested too, when designing your store kit classes be sure to implement a way to set a boolean switch for test mode where it can allow purchases separate to the actual store kit. Use compiler #if statements to make sure the code can't be manipulated in release.
4. Let the participants give you feedback - What I like to do is set up a form in google documents stored on my google drive. You can make fairly detailed forms, make them public and then see all the background data collected in a nice neat spreadsheet without spending a cent. Then pick a logical point in your game (such as at the end of the final level or after 20 attempts to then ask them if they would like to provide feedback and send them to the form. This is important as you are narrowing down the feedback to people who actually played the game to a specific point.
5. Ask for more feedback - In addition to the above, have a separate form for bad experiences. Measure the number of memory warnings, error screens, crashes, levels failed and then ask them if they would like to submit a bug / issue report. You will see this data in your analytics but its important to get the direct opinion of the user as well.

Hope you find this useful and is enough to get you started. Don't fall in to the "I know everything" trap.