Get an iOS device
First -- and this may seem obvious, but I'm surprised at how many people haven't done it by the time they're contacting developers about their app idea -- get yourself an iPhone, iPad or iPod-touch and use it for several days. Get your mail, browse the web, message someone. Many people see their friends' iPhone, or they play with one for a few minutes in the store, or maybe they saw one on TV, and they get all excited and full of ideas about all the cool things it could do.
You need to own one! With the iPhone/iPod-touch/iPad, Apple revolutionized the way a lot of things work. There are also many facets of the user interface and "the iPhone way of doing things" that you won't pick up in a few minutes or even a couple of hours' use. Until you've gotten your email several times, visited several web sites, downloaded and played with several apps, etc., you're just not going to "have the hang" of The iOS Way. Even if you're familiar with another smart phone (i.e., an Android device), while that will give you a bit of a head-start, there are still important differences with which you need to be familiar if you are to run an app-selling business.
Look at it this way:
- Scenario #1: You spend a little less than $250 on an iPod-touch and play around with it. You get a cool new toy; you develop a deeper understanding of "what this thing is all about"; you see other apps that give you ideas about how your app can be made better; you share ideas with friends; you solidify your own ideas in your mind, we turn them into a spec, and then produce them in code. In the end, everyone is happy.
- Scenario #2: You decide to save $250. You explain your ideas; I explain how the iPhone doesn't do things that way and suggest different ideas. You explain how you'd like your app to work; I explain that iPhones don't work that way, and suggest alternate ways of doing things. You specify that you'd like your app a certain way; I explain that this is non-standard iPhone behaviour which might get your app rejected from the AppStore, and suggest another approach. Overall, we spend several hours (billable!) going back and forth like this and, in the end, frustrated, you spend $250 on an iPod just to see if I'm pulling your leg about all of this. It turns out I'm not.
The choice is yours, of course -- it's your money! -- I'm just trying to help make sure you end up a happy customer. That's really what it's all about, for me.
Formulate Your Idea
You have an idea for an app, but now it's time to turn that app into a specification. We can work off of a rough idea and a few drawings and detail the various parts as we get to that portion of the development but, sooner or later, we're going to have to nail-down how every detail of the app works. Certainly, if you want an estimate before work begins, we'll need to detail what the work is going to be! The more detailed the spec, the more accurate the estimate.
The Basic Idea
Before you begin, ask yourself these questions:
- What is the main benefit your app brings to the customer? Not a long list of all the great things about your app -- just the one thing that is really "it."
- How is that benefit delivered? What did your customer used to do, and how is their life made better by running your app?
Drafting a Spec
It may be helpful to imagine describing your app to a three year old and that, at every step of the way, they ask "why?" and "...then what?" Creating specifications for a computer program is a little bit like that.
- Is there data? Does your app stand on its own? Is there a "server" with which it must communicate? Does the app talk directly to other devices?
- Does your app save persistent data between runs?
- Is this data saved on the device?
- On a server? ("In the cloud...")
NOTE: You need not provide a full-blown technical engineering specification with presentation-grade artwork. All we really need is the basic idea of what you want the user to see, and what you want to have happen when the user performs various interactions with the controls presented. A simple sketch with hand-written labels, as in the image below, is typically the easiest thing for both developer and client. Accompanying text, such as 'when the user presses the start button on the home-page, go to page 2A', etc. (for each user control) completes the specification for this project.
The key information we need from a spec is this:
- When the user first launches your app, what will they see? What information is presented to the user?
- What options does the user have from this screen?
- How does the user navigate/command the app? What can they do?
- If the user selects the first option, what does the user see on the screen?
- Repeat the steps above each option on each screen.
Below is an example of a client sketch of the first 2 pages of their app. The accompanying email described what each control did, and what happened when the user selected that option (i.e. "When the users presses START, go to screen 2A.") This sort of detail works very well for most iOS apps.
NOTE: I'm a big fan of hand-drawn sketches, but I understand that some people are not comfortable with paper & pencil. I have had clients use the iOS sketch-up product "Balsamiq" with good results. But, really, what tool you use doesn't matter, so long as you convey the critical information.
Initial Developer Contact
If you have the chance, you should contact several developers, and get a sense of what they think about your project in terms of scope, effort to develop, etc. Also ask if they can provide references, which are a good way to learn about how a particular developer handles projects and clients. From ManyFriends.com, the typical initial exchanges go something like this:
After a brief introduction via phone or email and a high-level explanation of the type of app, we forward a Non-Disclosure Agreement which assures that neither of us will share the other's intellectual property inappropriately. At this point, we can begin to discuss the project in detail.
For most of my projects, I work with the client to get a rough specification, then explain what I think we're going to be doing and roughly how much it will cost, which is based on an hourly rate for programming. Then, as the client and I work together to refine the specification, I can offer various options for how to accomplish certain things, and narrow the estimate range. Many of the projects I've done for others have been very small, with the talking about exactly what the program is to do taking nearly as long as the actual programming!
For details about how to create a specification, see the Formulate Your Idea section, above.
Sometimes we are asked if we would be interested in partnering or a revenue-share instead of "normal" payment. While I have done revenue sharing in the past, I'm not currently looking for additional partnerships.
Once we agree to a project scope and schedule, I will forward a software development contract to the client describing the general terms of our agreement (we'll produce software that they describe, they'll pay the invoices, etc.) There will also be an attachment ("Exhibit-A") describing the specific project to be undertaken, with the estimated hours, a maximum number of hours for this project and specific payment terms. This attachment also has a clause allowing the client to request and us to accept additional work (i.e., if you decide to add features, or do another project.) For new clients, there is a small deposit required before work begins which is applied against the first invoice.
Once all the paperwork is done, we begin the early phases of the project.