So You Have An App Idea…

About once a month, someone will present me with an app idea. In general, I don’t want to hear it, I don’t want to sign an NDA to hear it, I don’t want to work on it for free or for cheap, and if you’re worried about me stealing your idea don’t tell it to me. If you tell me about your app idea, anyway, let’s be clear, this is me providing free consulting, not you doing me a favor. And before you describe your idea to me, or pitch it to anyone else, do some homework. Here are some general resources you should look at:

A quick-start, the book Idea to iPhone, pretty easy to find at your local Barnes and Noble’s, is a great introduction to getting your app realized — from fleshing out your idea to realistically limiting its scope to finding someone to implement it, and finally marketing.

Assuming you’re targeting the iPhone (despite the competitive market shares, it’s always an “iPhone” idea), visit the Apple developer site and see what’s involved in creating an App Store account. Decide whether you’re going to publish the app in someone else’s account or in your own account.

It may be convenient to have the developer you contract publish it in their account, but then you have less control, less branding, and if you switch developers you have to transfer the app to a different account (and there is a mechanism to do that, unlike in the early days of the App Store).

If you publish the app in your own App Store account, you have to decide whether to register an individual account or a company account. Both will cost you $99/year, but a company account requires submitting information about the company, including bank info, and can take a few months for approval, whereas an individual account is usually approved almost immediately. So if you want your app listed on the App Store under a company name, don’t dilly-dally, get this taken care of now.

In case you didn’t know, there is an app approval process, which can take anywhere from a day to infinity, but typically is a couple of weeks, and apps do get rejected. So you should read the App Store Review Guidelines, which are really more like commandments, lest you invest time and money in something that is sure to be rejected. And, contract-wise, make sure your and the developer consider the situation where the app has to go through multiple submissions and even the case where you have to give up on the app.

The tone of the guidelines will also give you an idea of what kind of discourse you may have with Apple in the event of a rejection. Even though this is the kindler and gentler post-Jobsian era, last I checked snobby phrases like “less than very good” permeate the guidelines.

The guidelines are general enough to allow for any verdict, depending on the winds of Apple policy. For example, I had some apps built with certain middleware that was rejected for “not enough functionality” but Apple said they would approve them if I added native functionality, with Apple Maps cited as an example each time. So, reading between the lines, I surmised they didn’t want anyone using that middleware, anymore (not the first time that’s happened), and they really wanted to push Apple Maps.

If this review process is starting to worry you, consider going with an Android app on Google Play, instead, which does have some guidelines but doesn’t have a review process (though they do boot apps off their store).

Also, read the iOS Human Interface Guidelines. Again, you want to keep these guidelines in mind to avoid app rejection, but they are also worth reading as general user interface principles, a legacy dating back to the original Macintosh User Interface Guidelines. Besides, you want Apple to really, really, like your app, even feature it on the App Store and if you hit the jackpot, win an Apple Design Award.

If you’re going with Android, read the Google Design Guidelines.

The Human Interface Guidelines give you an idea what’s in the toolbox of user interface elements provided by iOS. If you just sketch out the pretty user interface designs you have in your head without regard to the user interface elements that actually exist, either the developer will have to replace and probably redesign most of it (maybe in a way that you don’t want), or it will balloon in cost and possibly never get completed as the developer attempts to literally construct what you’ve spec’d, like a runaway defense project.

You’ve come this far, now take a look at the iOS Developer Library. I know, you’re not a programmer, that’s why you’re hiring one, but it doesn’t hurt to learn as much as you can. Think of it like a home renovation project — you’re hiring the experts to do the expert and grunt work, but it behooves you pick up some books at Home Depot and learn the different types of tile and so on, so you know the pros and cons and impossibilities of each option. As an example, one entrepreneur, after meeting me for coffee and asking me to sign an NDA, presented an app idea that involved using the built-in movie player in a manner that the documentation says won’t work. Worst case, you end up paying someone to read the documentation that you could have.

There are some good books on app design, for example William Hecke’s Learning iOS Design.pdf, but app design is fairly faddish, so you should look at a lot of apps, especially those similar to the one you have in mind, and see how they look, the color schemes, the layouts and screen arrangements, the user interface elements used…try to analyze why they are the way they are, and if you have something different in mind, whey they’re not doing it that way.

And if you’re on Medium, you should notice one of the popular topics is app design, so there’s no shortage of material on the latest trends (and debates about the trends). But the web articles I find most useful are those describing completed app projects. If you’re making a game, the postmortem articles on gamasutra are invaluable — they present data on the budgets, team size and duration of real projects. If you expect your project to be better, cheaper, faster than every other, well, that’s a nice fantasy world you’re living in, send me a postcard.

At this point, you might realize you should scale back your ambitions (or maybe at the point the developer gives you an estimate). Especially if this is your first, app, start simple, as simple as you can. In particular, don’t start with an app that requires a server. If you don’t know what that means, you really shouldn’t have an app that requires a server, but here’s a tip — if there’s any kind of user login, there’s a server.

Remember, you can always update the app, so you can schedule additional features that way. In fact, the trend these days is frequent updates — Facebook updates every two weeks, Pinterest updates every three weeks…(they even say so in the update notes), and users have come to expect regular updates. Any app that hasn’t been updated in a few months appears abandoned.

Which means you should think beyond the initial release of the app and plan for the lifetime of the app and how it will be maintained. If you’re not planning any upgrades, new versions of iOS and new devices appear nearly yearly, so the app may require at the last some touchup to look good or even function at all. Make sure if your developer will not be available in the future that you will be able to hand off to another developer. This means having a copy of the source code that can be reliably compiled. You’ll need this if you want to sell your IP to another publisher.

OK, I’ve just listed the high-level steps on getting an app done and on the App Store. I haven’t gone into the various devices, screen sizes, graphics that someone will need to provide…but that’s in the reading listed above. And I haven’t gone into marketing or the non-app aspects of apps. For example, a guy in a coffee shop recently told me he wanted to make an Uber-of-X app for $10k. Don’t get me started….Anyway, that’s my free consulting. Time’s up.