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.

Hidden jobs in indie development

If you are an indie developer working on your own, it's easy to get stuck in the mindset that you have one main role "Software Developer". While this may take up a large portion of what you do and you may be a professional in your field, it does not mean you will be successful. To be a successful indie developer you need to recognize all roles you are responsible for. 

Marketing and Sales

It's not enough these days to throw a product down there and see who comes. You need to be "always closing" as it is called in the world of sales. Not all developers are good salesmen, you either need to become one or get one. When someone wants to talk to you about your apps you need the best way to sell your idea, to make the audience believe your product is worth buying. This is fundamental and important and should not be taken lightly. 

Marketing should not be an after thought that you pursue within the week Apple take to approve your product. It should begin at concept, you need to plan from day one how you will promote this product and even get people in the industry involved with the key functionality design of the product.

I cannot stress how important it is to build your marketing while your build your product.

Accountant

It is inevitable at some point you will need to pay taxes for the products you sell, having done a lot of work with financial data before I tried to do this myself. What you should be aware of though is this puts a lot of risk on yourself, you are a developer not a registered tax accountant. You don't watch for changes in Tax Law, you don't look for every single deduction, you have no idea how to handle your financial records and that is perfectly normal.

I highly recommend outsourcing to a Tax Professional and just getting them to show you the basics of what you need to do, how to register your business and keep records and let them worry about the rest. 

Project Planner

On your first project it isn't unusual to get an idea, sit down and start coding. Doing this will almost always set you up to fail. 

You need it to be clear in your head what this project is, what your minimum viable product is and how long it will take to reach that stage. There are many ways to plan each project, find one that works for you. 

Understand that your time is not free. The time you spend on your products could be time spent doing contract work at an hourly rate. You need to apply those same rates to your time to make sure the project will be viable in the long run. 

and the rest... 

The point is, you need to be prepared to step outside of your comfort zone, to do things outside of the scope of just programming. If you can't do that, find someone who can and employ them.  Good luck starting your indie software business.