And while part of my hesitation had to do with my optimism about iCombat’s potential and my marketing ability, it also had to do with the fact that I rarely buy full versions of games (although I do occasionally). After just launching my lite version yesterday I can say that my concerns about the lite version were misplaced and might have cost me quite a bit in lost income. Below are my main takeaways from having waited on launching the lite version and why I think too many indie iPhone developers wrongly steer clear of lite versions:

1. Know your Apps Core value and its core user: This sounds douchey but it really is harder than it sounds to have the discipline to know the profile of your core user and then choose that feature you think will resonate most.  For example, if you are making a game it is easy to think kids and adults will like it and they will all get hooked on the game play AND the graphics AND the story equally.  Odds are your app will not resonate with everyone, and one salient feature will be the hook so the sooner you figure it out and admit it to yourself the better. You may be wrong, but better to know your target than water down your strategy by pursuing too many angles.  Needless to say once you have your app’s core value outlined it will also be that much easier to design your lite version.
2. The App store is not a lemonade stand: The App store is one of the largest, most seamless content delivery platforms ever and when it comes to pricing most of us fail to understand just how fundamentally different this is from anything we have ever seen.  As a result we apply our personal conceptions of scarcity, value or what it means to transact with someone to something that is totally different.  If you have released an app you will agree that pricing decisions or the debate about a lite version are often more emotional than rational.  I am sure more than one developer has though “I don’t want to give it to someone for free when I worked 3 months on it every night after work while my wife was screaming at me because I was never around.”  That would be okay to think if you toiled on a model airplane or a painting for that period and were selling the one unit you had created, but in the App store you can divide that effort across 40MM+ people so who really cares if 5MM users get your app for free if in the end 250k of them buy it?
3. Be careful about buying into the media hype: I am not going to preach like everyone else about how little is being made on average. I don’t care about that because no one gets into App development to be average – if we didn’t all think we were working on the next Enigmo we probably wouldn’t be doing it.   I am talking more about the marketing angle.  Don’t fool yourself about how hard it is to get noticed, especially as the bigger game makers start to move to the iPhone platform.   It is getting more and more difficult to get blog coverage  so if you don’t have either a major platform to launch from or an existing fan base to leverage, your main form of exposure will be the lite version.
4. The blogosphere is like steroids (but it won’t make you #1): Many developers see Gizmodo or Techcrunch as the definitive tipping point, and it could be for an app but if your app does not deliver the viral hook no blog will save it.  As far as I can tell there haven’t been any cases of a blog breaking an app that then jumped to #1 and stayed there for a long amount of time (please correct me if wrong).  Blogs are like steroids, can help you get from 10th to 1st or from 500th to 400th, but not from 10,000th to 1st.
5. Don’t hide from App store criticism & negative ratings. Tying back to the second point, it is hard to take criticism for something you have worked hard on and so there is a natural hesitation to launching a lite app as users can be much more harsh reviewers. Again the goal is to get die hard fans to buy a copy, so it is OK if tons of people don’t like your game or review it poorly because all you need is some that really love it to spread the word. Maybe not launching a lite version allows for more control over the reviews (as there seems to be a natural bias of paying users to give better reviews) but this helps no one. This only reduces the total amount of people discovering your app and limits your earning potential.

Bottom line developers need to stop pricing their apps and deciding strategy based on vague feelings of what is value or what is deserved.  With frictionless transaction costs and so many users, your worst enemy for getting noticed may just be yourself.  So we should all stop thinking about how our 3 months of work is selling for less than a cup of coffee (or could be given away for free) and start focusing on increasing the amount of people using our apps.

Related articles by Zemanta

• iPhone AIM and Beejive IM Apps With Push Notifications Are Live [IPhone Apps] (gizmodo.com)
• Apple’s New iPhone Pumps Up Battery Life, Graphics [Wwdc] (kotaku.com)
• iPhone: Twittelator Pro Makes Tweet Casting Possible (Audio And Video Now Included) (blogherald.com)
• Tales from Development Hell – Why iPhone Developers Have It Good (cultofmac.com)

Once you have a signed NDA and you have sent out your specs and chosen someone to your liking the next step is drafting a contract.  What worked well for me was to create a contract between the developer and myself outlining, via milestones and detailed specs, what was going to be done at each stage.  While it takes a lot more up front work on your end to know exactly what you are looking for, it pays off in the end by having everything out on the table for everyone involved.  I learned from my experience developing application for The App Farm^tm , that it is worth the trouble to get it right the first time to avoid confusion down the line.

Things to consider in terms of a contract with a developer for an iPhone application:

1. Make sure the developer guarantees that they will have a bug-free working version of the application acceptable to Apple in terms of code quality (there are cases where the code is buggy and Apple rejects your application, so you want to make sure the developer stands by their work at least through this initial approval process)
2. That the developer relinquish and assign all worldwide rights and privileges and code to the contractor
3. That there be some sort of penalty for late delivery (to prevent low-ball time estimates just to get your business)
4. That the code and application created be built with proprietary and non conflicted code (you don’t want a previous contractor to recognize or see that their IP has been copied by the developer – this is a logical shortcut some developers might try to take to leverage past projects)
5. Make sure you have a process established in case something goes wrong in one of the steps of delivery (need to have clear plan for payment after a milestone or proceedings to fix flaws within a certain time frame)
6. Define the method and frequency of payment.  Define this early so there are no delays or discussions later

Obviously not all contracts or projects will be so clearly defined so then an hourly wage would be better.  I recommend using oDesk for this as they allow you to monitor work in progress, pay via credit card on line, and even challenge a payment if you feel the work is not executed as agreed.  Not sure how easy contesting a charge is, but again having the possibility of doing this ensures a minimum level of accountability.  All depends what you are looking for.

With regard to the contract, I would recommend you use an experienced lawyer because you want to be certain you are creating a contract that protects your claim to the idea, the code and its implementation, especially if your application does well.  I think anyone willing to go it without a strong contract is risking getting screwed because there is nothing preventing a developer from claiming ownership or filing in the App store under their own certificate if they so choose.

In terms of other legal issues to consider around your idea, make sure that:

1. The name of your application is not trademarked or otherwise reserved
2. The idea and concept you are using is not copyrighted or patented.  The laws around this are inconsistent, divided and are always changing so best to consult with an attorney or at minimum spend the time to educate yourself if you have any concerns
3. Create a legal entity to shield yourself from any sort of liability.  In case there was a trademark or copyright issue you were not aware of, you want to protect your personal assets from any sort of litigation that might result down the line.  This can be done fairly cheaply, just head to LegalZoom to figure out which structure works best.
4. In terms of any music or images or code you use, make sure that it is not protected or under a general public license.  You do not want to face royalty payments for a certain song playing in the background or be forced to share your code because you used a line of code or an image protected under the GNU General Public Use license.

Related articles by Zemanta

• iPhone application developers struggling for profits (or presence) (crunchgear.com)
• Average iPhone app usage declines rapidly after first download (textually.org)
• Experiences Of A Newbie iPhone Developer (techcrunch.com)
• The keys to App Store success, courtesy of Pinch Media (tuaw.com)

If you want some tips on the contract details and other legal stuff see the Taking Care of the Legal Stuff entry.

Related articles by Zemanta

• OpenTech, Apple clone makers, now selling themselves on eBay (crunchgear.com)
• Do you care what OS powers your mobile phone? (windowsmobilecool.com)
• Stay on Your Toes in 2009 (killerstartups.com)

I still don’t think it is a bad deal to offer a developer: 1) an application idea, 2) a salary, 3) a flexible schedule, and 4) a portion of the returns.  I wasn’t able to find anyone experienced, however, with enough interest and skill to really dive in to the project.  While I am sure this is a symptom of the high demand for iPhone developers and my lack of being able to find / convince anyone locally (I only posted on Craigslist so wasn’t exactly scouring the city), it was still surprising how few serious inquiries I received.  Let me just add, as someone who is learning the iPhone SDK, I was amazed at how little most developers who reached out to me knew about developing with the iPhone SDK.

One thing I knew was that I didn’t want to create an SDK University where I would pay someone to figure out how to develop my game.  So if you are an outsider like I am to programming, just a warning to be careful about who you consider working with.  By no means is someone good because they can throw some jargon your way, and more importantly all programming languages are NOT the same.  True, a talented developer can pick up a language very quickly, but the reality is there are a ton of less talented developers out there so look for proven experience.  For some tips on how to find talented programmers as a non programmer see this post.

When I looked at local companies all of them had quotes that were either too high or too slow.  Again, it felt like most were traditional web developers trying to branch out into iPhone development on my dime.  This was probably because the professional local iPhone outfits were busy charging 25-30k to advertising and other companies to develop their apps so weren’t interested in my less than straightforward app.  I had heard plenty about the quality of outsourcing development to Eastern Europe so I chose to look internationally and post an add on oDesk.  I had found out about oDesk through a friend who was developing an application and when I visited the site I was extremely impressed with the quality of their services.  Clearly quantifying hours worked, developer ratings, even test skills passed as well as displaying links to portfolios made it easy to filter through applicants.

I posted an add and received about 10 responses within the first several days.  Some were developers just spamming me, others had relevant experience but were divided into a range of ratings from 3.5 to 5 out of 5.  I initially contacted the higher rated ones who had positive feedback on past assignments but with one from the Balkans I found that his English proficiency was far below what would be necessary to communicate effectively.  He clearly was very talented but I got the feeling he was using Google translate to answer my e-mails.  Another team from Pakistan spoke great English and they spent quite a bit of time on chat with me getting to understand the project.  I liked them but their estimate came in at 4 man months – roughly 2-3x longer than anybody else!  The process was tedious between getting NDA’s signed and sending out the specs to receive a quote (see Taking Care of the Legal Stuff entry) but I ended up with a few good options that I felt would work.

I decided on a team of developers from the Ukraine whom I had found worked on an application roughly similar to what I wanted to make.  I contacted them and immediately knew they would be easy to work with.  From their English level to experience with similar projects to their extensive list of published apps I knew Injoit could execute on what they promised.  For more about the process of finalizing the specs and signing up with them see the related entry Contract Signed!.  So far working with them has been great, they are timely and easy to communicate with so we will see what happens.

If you are looking for a developer make sure to:

1. Even if you are not a programmer, spend some time reading about what is possible with the SDK – you’d be surprised what developers try to convince you of (for example, Apple makes it very easy to utilize tools like the Accelerometer – matter of hours or a day to set up but I had one guy tell me that it would take a week!)
2. Find someone who has worked on something similar.  If you are developing a game, someone who has no graphics or game engine experience will slow the entire process down
3. Don’t be afraid to ask for a time and cost quote, and once you get the time estimate have them breakdown how long they see each component taking.  When you have a couple of quotes it makes it easier to figure out their skill / bs level.
4. Don’t hesitate to contact previous application users.  In most cases it will be a dude in a basement like you so no harm in dropping him / her an e-mail asking about their experience.  I actually almost signed with one team before I spoke with someone who had worked with them who told me to steer clear!
5. Think carefully about hourly versus by project.  Both have their benefits and it will largely come down to how specific your plans are.
6. Know exactly what you are looking for.  This was hard for me, but sit down and map the whole damn idea out as well as what will be required before contacting people.  Don’t expect anyone you speak to to have really creative solutions to your important application design questions (i.e. application purpose, business model, pricing, etc).  If they did, they wouldn’t need your ass and if they did have your answers they would cost way way more than you can afford.  If you need someone to figure out the other half of the puzzle then look for a partner, not contracted development.
7. Be realistic about the costs, although outsourcing development is cheaper than doing it in the U.S., it is not going to be free to develop something of quality.  If you are developing the next iFart then maybe, but honestly why bother?  Besides, in my opinion the real opportunity in the App store seems to be the tween category of 2$ to 3$ apps, not the $10 Spore’s of the world and not the $0.99 crap gimmicks that are drowning the App store.

Related articles by Zemanta

• The keys to App Store success, courtesy of Pinch Media (tuaw.com)
• Izatt offers new iPhone Gaming Course in Utah (themactrack.com)
• VixML: A Revolutionary New iPhone Development Platform For The Masses (techcrunch.com)
• So you wanna be an iPhone developer? (crunchgear.com)