Don’t be ashamed if you are creatively or technically challenged. Because you’ve focused on the ideas and concept of your app, you’ll be in a much better position if you need to hire or outsource its design or development. Because the app market is booming, there will be no shortage of people and companies ready to “help” you. Your job will be to separate those who are merely following the app gold rush from those who can successfully bring your concept into the App Store.
In this chapter, you’ll explore:
Skills needed to bring an app into the App Store
Your role in the development process
How to estimate costs to develop your app
Places to look for help and how to evaluate resources
Although some people reading this book have the creative or technical abilities to build an app without help, others do not; this chapter is focused on those in the second category. If you fall into this second category, you are already in a much better situation because of what you’ve been doing, including becoming a connoisseur of apps and engaging the iOS development community (part of Phase 1 of your marketing crescendo from Chapter 8). Your next step is to find those with the expertise you are lacking.
If you are developing your app yourself or you already have resources to build it, you don’t necessarily need to read this entire chapter. The interviews, however, are particularly insightful, and I encourage you to read them. Also, the chapter contains some good nuggets about scheduling and where not to cut corners with your team members.
Before I start pointing you to places to look for software developers or designers—in the form of independent contractors, small app development firms, or agencies—to help you build your team, I want to equip you with three pieces of information:
The types of skills that are required to build apps
How to vet those who claim they can help you
An understanding of the costs involved to build apps
In terms of the third point, although you won’t receive any cost estimates until you begin interacting with designers or developers, it’s important to go into these conversations with the right expectations and background on the talent market.
Because building an app is fundamentally a software development effort, the same types of skills are required. I’ll break these skills down into three broad categories: product management, design, and software development.
Product management is what you’ve been doing and will continue to do throughout the remainder of your app’s existence. It entails a number of responsibilities, including strategizing, managing customer interactions, testing, and marketing. The product manager is the person who owns the product, not in the sense of legal ownership (although that could be the case), but in terms of ensuring that the app’s vision becomes its reality.
This last point is worth spending a moment to explore further. By being the visionary of your app, you will be the product (app) expert. This expertise derives from your understanding of the App Store and what you are learning from your customers. The firmer you are with the strategy and direction the app should take, the fewer questions your team members will have.
With more details, especially details that are documented (rather than just floating around in your head), you’ll have a larger pool of talent you can choose to work with and will, in most cases, reduce what it costs you to build your app. Consider the difference between giving a detailed written description of the house you’d want a builder to create for you and just loosely describing it. Even though the builder knows how to build homes, he won’t necessarily create one you like without clear input and direction from you. The same is true in the development process for your app.
More tactically, the product manager acts as a project manager, tester for quality assurance (QA), marketer, and customer support representative. These responsibilities can include scheduling meetings, taking notes, ensuring that tasks are being completed on time, keeping a team talking, writing marketing copy, rigorously testing the in-progress app, and regularly interacting with customers through all marketing and support channels. Since your other team members may have little interaction with customers (although you should do your best to directly expose the team to them), you will need to aggressively represent your customers and be a proxy for them internally.
I wrote most of this book to help you perform the functions of the product manager. So, in a sense, you can view not having to hire a product manager and executing these duties yourself as a way to save money. I do, however, want to offer you a word of caution about operating under this mindset. These responsibilities are extremely important, and if you decide to assume them, you need to consider yourself a full-time member of your team. Failing to do so can result in your app getting off-schedule, miscommunication (or no communication) among team members, and launching an app that has no real chance of success. If you have the financial resources, or if your strengths are in design or development, you should consider having an actual product manager oversee your app for you.
The interviews at the end of this chapter also provide some helpful perspectives on the various roles required in developing an iPhone app.
The designer for your app will lead all its creative direction. This includes choosing the colors and fonts and creating the logo, app icon, any required artwork, and actual screens. The product manager will collaborate with the designer to ensure that these elements match the app’s vision and strategy. As the designer completes the design assets, she will give them to the developer to incorporate into the app.
Although you will want a designer with app experience, it’s good to work with designers who are comfortable with other forms of media. For example, as part of the marketing process, you’ll need to build a website. The branding aspects of your app (colors, typography, and logo) are also more general design tasks.
Great design is extremely important in the App Store. In the next chapter, you’ll also learn that great design does not focus on visuals alone.
I’ve been using the word “development” to describe the entire process of building your app and “developer” to generally refer to those involved in creating an app. The software developer, however, is the person who will actually code and program the application and drive your app’s development. Development, in this context, includes the technical architecture, programming, integration with any external data sources, and optimization for your app. I describe each of these items in detail in the next chapter. For now, it suffices for you to know that your developer is responsible for making your app functional, as well as integrating the design assets created by your designer.
Of all the roles on your team, the developer has the least leeway in terms of not having direct experience building Mac or iPhone apps. In the past, I’ve worked with designers who had not designed an iOS app and picked it up fairly quickly. But I’ve had disastrous results with people trying to learn iOS development on the fly. That’s somewhat dependent on the talent of the person you use, but let my experience be a lesson for you and go with someone who has at least basic (and demonstrable) Mac or iPhone programming knowledge.
Compared to your designer, your developer is going to be doing more work and be more heavily involved in your app’s progress, especially in the long term. Once an app is launched, unless there’s a major redesign—which does not occur very often, and sometimes does not occur at all—most of the ongoing effort will be development-related. In most cases, after your app is in the App Store, your developer will probably be able to use the existing design assets in future versions of the app.
Due to how hot the market is for building apps, and especially iPhone and iPad apps, there will be no shortage of people willing to “help” you. You can avoid those types of inquiries by beginning your search the right way and then knowing how to better vet potential team members. Trust your instincts and judgment throughout this process. If you have a bad feeling about a person or a company, don’t proceed.
If possible, try to work with people you know or who are in your larger network. Making that happen may include asking friends or family to make introductions for you, or hitting LinkedIn and Twitter to ask your colleagues and peers to do the same. It’s better to work with people you have done business with in the past or who come with a referral from a contact. Getting a referral can help you avoid this search entirely.
With referrals or with people you find outside your immediate network, always ask for client references. Talk with these references about their apps and App Store experiences. If someone doesn’t have any client references because he is just starting out, don’t be completely scared away. If he can demonstrate a reasonable amount of competency, use his lack of references as a negotiating point to lower costs.
Portfolios are a great means to understand a designer’s or developer’s skills. A portfolio showcases the apps or the parts of the apps that someone previously built.
At first glance, a portfolio may seem relevant only to a designer, since it’s easy to visually inspect the work. The nice thing about the App Store, however, is that you can download any portfolio app (see Figure 4-1) and try it yourself. That allows you to experience a developer’s work too by seeing how responsive an app is and whether it seems stable or crashes.
The other use of the portfolio is that you can discuss the apps with the designer or developer. Ask why her app looks or functions the way it does, what some of the tough decisions were, and what she considers the best and worst parts of the app (especially what she believes needs to be improved). I find the best way to do that is to focus on two or three screens. Try to really dig into the details beyond what’s obvious. Another reason this step is important—and you might be surprised by this fact—is that some people will misrepresent apps as part of their portfolio when they really are not. That won’t be possible if you have these types of discussions.
If their apps are fairly different from what you want to build, ask them how they’ll approach designing or developing your app. Guide them to be more specific and ask what they see as the big challenges with your app compared to what they previously built. A good approach is to point them to one or two apps that are similar to yours and then follow the same exercise as with their portfolio apps by focusing on two or three screens and then discussing with them.
Aside from making sure your team members have the right skills and talent, you will want to make sure you find people who are willing to agree to some basic rules regarding confidentiality and protection of your idea and application. This includes maintaining your rights to your idea and the assets your team develops for your app.
This protection is often accomplished through a nondisclosure agreement (NDA) and a standard contractor agreement between you and any of your team members. The purpose of the NDA is to define the terms under which you and your contractors will disclose confidential information to each other during the course of the engagement. It may provide protection of that information for some period of time (as specified in the agreement) so that it cannot be shared with third parties.
The main goal of the contractor agreement is to establish your rights to the assets your contractors develop. It may also include a description of what tasks or milestones your contractors must accomplish to receive payment.
These guidelines are for informational purposes only and should not be construed as legal advice. Although NDAs, contractor forms, and related resources are available for free on some websites, such as LegalZoom.com, Nolo.com, and Docstoc (http://www.docstoc.com/), they may not fit your specific situation. I strongly recommend that you consult an attorney to ensure that your agreements are accurately drafted and enforceable.
In Chapter 1, I mentioned that $10,000 was a fair number to use for the cost of a well-built app. Sure, it is possible to pay less than that (and much more!), but in general, as that price goes down, so will the quality of the app. To quote Davide Di Cillo, an iPhone app developer and the founder of GetAppsDone.com, who is interviewed at the end of this chapter:
...keep in mind that a $20 per hour developer isn’t always cheaper than a $100 per hour developer. I’ve worked with developers that even if more expensive, were saving me money by being faster and more responsive.
For some background on why that number is in some ways a conservative estimate, note that many apps will take between four and eight weeks to build, with the average being six weeks. With a full-time developer (40 hours per week) and a part-time designer (20 hours per week), the average man-hours per week is around 60. Six weeks multiplied by 60 hours per week equals 360 hours. Solid designers and developers will charge around $100 per hour, with top talent peaking at around $150 per hour and lower-end U.S.-based contractors charging around $65 per hour. Using the $100-per-hour rate yields a total of $36,000 (360 hours × $100 per hour). That number can quickly fluctuate: if your app took four weeks to build (240 hours) and the average was instead $75 per hour, the total would be $18,000 (240 hours × $75 per hour).
For games, the number of total hours is much higher, and ranges between 700 and 2,000 hours. This equates to three to six months of work, depending on the number of developers working on the game simultaneously.
It may astound you to know that depending on complexity, the cost of developing an app can range from less than $5,000 to more than $100,000. That lower boundary typically involves working with offshore or independent developers, whereas the higher number is from hiring professional companies or agencies. Looking at the median cost from TheyMakeApps.com (see Figure 4-2), a resource for finding app developers, you can see that development cost lies within the $10,000 to $15,000 range. Contractors have also requested that TheyMakeApps.com add a $50,000+ category to assign to their listing.
One last note about these costs: on the lower end, they largely assume that you are acting as the product manager for your app, performing the roles described earlier. This implies that your “services” are free. To perform a more rigorous cost analysis, you might consider including your hours in these estimates. Assign yourself an hourly rate—perhaps what you could make if you were consulting, based on what you make at your job, or by actually paying yourself some sort of salary—and multiply that by the number of hours you plan to spend on your app per week. Add that to the previous numbers to get another perspective on costs.
Hopefully, you didn’t damage this book or your screen too badly after reading the preceding paragraphs. The reality of the situation is that you are in a hot market in which people with the skills to build apps are scarce resources. You’ll find that the best designers and developers won’t haggle with cost estimates or their rates because others will gladly pay them.
To reconcile these costs, start with the quantification of your app as performed in Chapter 1. You should understand the larger purpose of this effort (e.g., it’s the start of a long-term investment in the mobile space) and, if you are pursuing a paid app, have some sense of what the financial returns should be.
Although I’ll show you some practical ways to lower costs, you need to be able to reconcile them with the motivation behind your app. Mentally you must be “all in” with your app, equally committed to it and prepared to lose anything you’ve invested. That’s a telling yet truthful statement about the nature of the App Store.
Remember that if you continue to update your app once it is launched, each update will also come with a cost. Depending on what the updates include, they typically will equate to a fraction of what it costs to build the entire app. Not accounting for them, however, can give you a false sense of out-of-pocket costs.
Ensuring that your product assets (e.g., initial research and wireframes) are as detailed as possible is a smart way to reduce your costs. If you have little or no experience building software, some of these items will not be more fully completed until your team is in place. Even before then, however, do your best to think through the biggest challenges of your app. Bringing more information to your potential resources will help them better estimate costs and build your app more efficiently. Both of these will impact the bottom line of what it costs to build your app.
Second, try to keep the first version of your app as simple as possible. That means scaling the app back to its key features, choosing what has proven to be most important to your customers. This approach not only is helpful from a cost perspective, but also is a strategic decision for your app. Many apps try to do many things at once, and as a result, they do nothing well. Thus, by focusing your first release in this way, you’ll reduce the risk of overinvestment while also developing a better app.
The experience, quality, and location of those you contract can drastically impact costs, but not necessarily the way you’d think. For example, working with offshore or less experienced resources (such as students or recent graduates) can put your app cost more in the range of several thousand dollars. Yet, this usually can be accomplished successfully only by people who know how to collaborate with these types of designers and developers to achieve the results they want. Those who are less seasoned or have no experience in this area often choose the cheaper option, only to spend thousands of dollars with an unsatisfactory outcome, or worse, with nothing to show for it. The investment, in this case, becomes considerably higher than initially agreeing to a more costly estimate or hourly rate from more experienced or proven resources.
There are additional challenges with offshore or overseas resources, including language barriers and adjusting for time zone differences. Again, it’s possible to overcome these problems, but few have gotten the formula just right; the benefits are numerous to those who have.
A lesser-known way to reduce the cost of building your app is to find developers who are willing to reuse code from their other apps or client projects. The reason is that the actual development usually represents the largest portion of the cost. You might even consider working with a developer who has developed an app that is similar to your idea.
The caution for this approach is that you’ll need to ensure that you have the full rights to these assets—through a written agreement—in case you sever your relationship with the developer or your app is acquired. In the first case, you wouldn’t want the developer to keep the code if he is no longer involved in the app. In the second case, you wouldn’t want the developer to claim that your app couldn’t be sold or that a portion of the proceeds were owed to him.
On this point, I want to conclude this section by addressing the use of partnerships and revenue sharing (referred to collectively as “partnerships”) as a way to lower costs. It’s possible that instead of paying for help, you might convince people to lend their skills or assets for free in exchange for partial ownership of your app, a share of the app’s proceeds, or recognition (if you have a free app).
In most cases, I find that one or more parties in partnerships become disillusioned by the perception that another party is not as committed or is not doing as much work as other members. This causes frustration, distrust, and often a dissolving of the partnership before the app even makes it to the App Store.
One remedy to this situation, which does not make a partnership foolproof, is to have a written agreement that stipulates how the equity is divided beforehand. This solution also has its problems, because it may not be clear what each effort is worth. For instance, since the main value you might bring to your team is your idea and your understanding of your app’s landscape, doing “less work” in terms of building your app shouldn’t necessarily imply that your share of the app should be lower than others’.
Another major issue with partnerships is that disappointment and frustration can occur if the app does not immediately meet expectations when launched into the App Store. Part of the underpinnings of a partnership is the promise of the app. If it appears to have no promise through its download count or sales numbers, your partners may be unwilling to continue to invest their time in it. This can leave you in an unsettling predicament.
If you are absolutely determined to build your app using a partnership, at least do so with people you’ve worked with in the past or have known for some time. And still be sure to put the terms of your partnership in a written, signed document. My overall recommendation is that if your idea is worth pursuing, consider some of the options to reduce your costs, but be willing to invest money in it. Doing so will simplify legal paperwork, and ultimately will allow you to drive and own the direction of your app.
Visit http://kenyarmosh.com/appsavvy to help estimate the cost to build your app. You’ll also find information about how to create a reusable template to solicit contractors, as discussed in the next section.
Now that you understand the types of skills needed to build your app, know ways you can vet your team members, and have some sort of expectation regarding costs, you are ready to begin engaging those who can help you. You can find these people through several outlets, and your choice will be based on your needs and preferences. Since most of these will be online, however, it’s helpful to have a reusable template to solicit inquiries. You’ll collect standard information from these contractors so that you can judge them against each other. I’ll cover how to do that first, and then I’ll highlight some of the places you can look for your potential team members.
To expedite the process of soliciting contractors, you’ll create a reusable template focused on getting the same information from all interested parties. After you receive this information, you’ll share more details and any app assets you have as you learn more about each contractor. Depending on how unique you consider your idea to be, few to no substantial details about your app need to be shared until you feel comfortable or have received a signed NDA (or comparable documentation).
The best way to think about the template you create is that each part of it should require some response from a potential contractor. By approaching it in this way, you will ensure that it is kept concise and actionable, while screening those who might not be right for you.
The template should include a brief description of what the app is about, the skills required, a request for the contractor’s portfolio (preferably links to the App Store), additional information about the contractor (e.g., other creative or technology skills), when you are looking to start and complete the project, your plans for compensation (e.g., paid or partnership), and how to get in touch with you. This last item is often dictated by the outlet you are using to post your solicitation.
Don’t worry about including the budget for the app at this point, unless it is required wherever you are advertising. Those who see an actual budget number for your app will be motivated by that number alone, meaning they will be motivated for the wrong reason. Any smart contractor should evaluate your solicitation based on the information you provided. It will communicate that you are serious and thoughtful.
After you have completed your recruiting template, you are ready to find help. The outlets you choose to target will be based in part on your budget and time constraints. Pursue as many or as few of these outlets as you want, but don’t settle until you are satisfied with the number of options you have to sort through to help you build your app.
Those who are slightly more cash-strapped will need to be more proactive and creative in their search. In these cases, independent contractors (also referred to as “indie developers” or “freelancers”) are the best options. Independent contractors are people who moonlight their services, create their own apps but use contracting to supplement their income, or have a very small development firm (one to three people). Offshore or overseas options also fall into this category.
There are a handful of great ways to find this type of help. The first is to get involved in the local tech community. NSCoder Night (http://nscodernight.com/) and CocoaHeads (http://cocoaheads.org/) provide extremely targeted options. You can also check out Meetup.com and find mobile or app-focused groups. Attend these groups and meetups or post to the message boards inquiring for help. In these situations, it’s best to initially introduce yourself and ask those who are interested to get in touch with you before sharing your template or questionnaire.
You can also use Craigslist to stay local by posting a “gig” that solicits contractors (e.g., http://washingtondc.craigslist.org/cpg/). In this case, it’s fine to make your advertisement short and link to your questionnaire (if you created one) or simply use your template. If you do have a questionnaire, you need not include a “reply to” address when creating the listing. Although I firmly believe in the ability to work with remote resources, it is nice to be able to occasionally get together with your team. That makes Meetup.com and Craigslist especially valuable outlets, since they are geographically targeted.
It’s likely that many of the apps you either admire on the App Store or think have functionality that could be useful to yours have been built by indie developers. As mentioned earlier, consider reaching out to these people, because you will be able to evaluate their skills and experience. Remember that the App Store listing shows the website link for all developers.
These developers also may offer the best opportunity to help you reduce costs by leveraging their existing code assets. Besides checking out the App Store, you can browse sites such as the Behance Network (http://www.behance.net/), Ember (http://emberapp.com/), Dribbble (http://dribbble.com/; see Figure 4-4), or Forrst (http://forrst.com/) to find inspiration and potential resources through the portfolios of designers, in particular.
A great app-specific resource to use is GetAppsDone.com (its founder is interviewed at the end of this chapter). GetAppsDone.com provides a targeted outlet for you to advertise your opportunity. Once your listing is created, it can automatically be shared on Twitter and Facebook.
Although I caution you against doing this—unless you have previous software development experience—you can also pursue low-cost offshore resources. In fact, it’s likely that your Craigslist posting will generate some of these inquiries. To find these types of options, browse to oDesk (http://www.odesk.com/), Elance (http://www.elance.com/), or vWorker (http://www.vworker.com/).
If your app is fairly complex or you have a budget of more than $10,000, you might want to consider working with an agency rather than an independent contractor. The first benefit of an agency is that it typically will have all the resources you need to build your app, including a product manager, along with well-defined processes and tools (e.g., automated development builds). Second, an agency usually, but not always, can build an app more quickly because it has more resources at its disposal. These advantages will generally cost you significantly more, but you should feel the difference in the service you receive and the quality of the app (depending on the agency!).
One warning I want to provide you on this front is that many creative and web agencies added iPhone and iPad development to their roster of services only in the past couple of years. Although there are some crossover skills, as you’ve already begun to see, there are unique elements to building apps for these devices. Thus, my guidance to you is to find an agency that is dedicated to mobile development or that has a group that is focused in this area.
Finding mobile agencies is considerably easier since TheyMakeApps.com opened. Although you can also find independent contractors on this site, TheyMakeApps.com (see Figure 4-5) is probably the closest thing there is to a mobile agency directory. After designating that you want to build an app on the Apple platform, you can specify a location for your vendor/agency as well as the budget range for your app. The results will show you the available agencies, along with their websites and portfolios.
As you begin receiving replies from interested parties, be sure to follow the advice in this chapter on how to vet these resources. You should already have the portfolio from their initial response. For those you follow up with, you’ll want to ask questions about the apps in the portfolio, talk with client references, and execute any legal documentation.
Once you have evaluated a contractor’s work, verified that she can meet your timetable, signed any needed legal documentation, and had at least two substantial email exchanges or phone conversations, you should request a cost estimate in writing. To give yourself some options, try to get cost estimates from at least two contractors for each skill type (i.e., designer or developer) you need.
Ensure that you understand their process and workflow and how they came to their cost estimate. Clarify whether their estimate is a fixed bid or is based on the number of hours they think it will take; be sure to find out what happens if they go over these hours. Ask if they see any other ways to reduce costs. Don’t forget to inquire about what it typically costs to perform app updates and what, if any, updates are included as part of the estimate (e.g., bug fixes).
When you’ve finally decided whom you want to work with, execute your contractor agreement (see the Agreements and protection section), ensuring that it includes a description of services and stipulates the payment terms. The description of services will flow directly from the contractor solicitation template and product assets. For the payment terms, some contractors will let you know what they require while others are flexible. Most contractor agreements include “exhibits” at the end of them to address each item specifically.
Be fair, but don’t pay more than half of the cost estimate up front. If your contractors are working on an hourly basis, require them to provide you weekly updates on their hours and written confirmation from you for them to exceed their original cost estimate. Make sure additional payments are based on major accomplishments, such as submitting the app to the App Store, or better yet, having the app approved into the App Store.
As part of your agreement, request that your contractors provide you real-time access to the assets they create or have in progress. If the relationship dissolves (not desirable, but possible), you want to ensure that you can take any creative or code assets with you.
Background: Over the past two years, Davide’s company, 39 inc., has been continually contacted by those needing assistance in building their iPhone applications. Realizing there wasn’t a streamlined process for connecting iPhone developers with potential clients, Davide created GetAppsDone.com, a place where companies and iPhone developers can connect with each other.
Ken: Once someone has an iPhone app idea and has validated it’s a good idea to pursue, what do you consider to be the next steps in building the app?
Davide: They should write down on a piece of paper (that white thing some people still use) all the features they came up with for their application, and cross out at least half of them because I’m sure they won’t need them. People still confuse iPhone applications with desktop applications. For instance, for the Get Apps Done iPhone application, it could make sense to send out a resume, but the question is, would you send out the resume that could help you find your next job from a phone, or would you rather do it from a desktop or laptop where you could make sure everything is perfect?
Once you nail down the list of features you need, then it’s time to find the right developer for it. I talk about developer, but in my opinion, working with teams (designer plus developer) is always better than working with a single person. The designer will help you create the right user experience while the developer can help you refine the features of your app.
Ken: Some individuals and companies don’t have access to those who know how to build iPhone apps. Where are the best places to start looking for help? How does GetAppsDone.com assist with that and how does this differ from other options available?
Davide: Posting a (free) ad on GetAppsDone.com is a good way to start, but there are many other ways, like looking for a local developer group on sites like Meetup.com or openly asking on Twitter.
GetAppsDone.com differs from all those “rent-a-coder” sites because we don’t have a bidding system. In our case, not having that feature adds a lot of value, because we don’t create a race to the bottom for the prices that usually favor lower-quality work. Often, whoever is looking for resources doesn’t understand how it is possible to receive bids from $1,000 to $10,000 for the same project, so they just go for the cheapest. With GetAppsDone.com, we let the developer contact the solicitor directly, giving them the opportunity to present themselves as they desire.
Ken: Since iPhone design and development is a hot space, these skills are now listed on everyone’s resume. How do you filter and vet those who are accomplished versus those who are just looking to monetize on someone’s inexperience?
Davide: A good idea is to ask for work examples and previous clients’ references. Other than that, it is really hard to judge the real knowledge of a developer without being technical.
A trick that I have is never to hire “yes” people. You want your developer to be honest with you and you want them to say “no” when they see something wrong in your idea. Starting with the assumption that there’s always something wrong or not cost-effective in an idea, your developer should help point out some problematic feature request at least once.
Ken: From what you’ve seen, how long does it usually take to build an iPhone app once the right resources are in place? What areas do first-time app publishers under- or overestimate?
Davide: Time frames are all over the place. Usually, those looking for help underestimate the number of changes they will request during the process. No matter how little and simple they look from the outside, sometimes they require a lot of work “under the hood.” I always try to underpromise so that I have room for those changes, and no client will ever complain if we deliver an application earlier than estimated.
Ken: What aspects of creating an app can be done in parallel? What can’t? Are there ways to get apps done faster besides having more resources available?
Davide: Design and development. We usually prepare a wireframe of how the application should work, including areas and spaces for different elements, so that we can work on the development and the polished design elements at the same time. Then, we just need to swap the less-finished elements with the final ones.
As far as the best way to get apps done faster and in a cost-effective way, my suggestion can be condensed to three words: keep it simple. Don’t try to squeeze every feature you see in your favorite apps; just pick the one or two features your application really needs and try to make those perfect.
Ken: Although it can vary greatly, what guidance or framework can you provide to those trying to evaluate the cost of developing an app? What ranges are you seeing in the market? How can costs be reduced? Where should costs not be reduced?
Davide: Again, costs are all over the place. If we look at the U.S. market, I would say for an application that uses custom design and a few API calls, the range could be between $5,000 and $10,000.
My suggestion is to try to use developers who already built apps similar to yours and ask them if they can reuse any of the code they already wrote. I always try to help our clients to save money, not undervaluing our service but offering smarter solutions. And keep in mind that a $20-per-hour developer isn’t always cheaper than a $100-per-hour developer. I’ve worked with developers who, even though they are more expensive, were saving me money by being faster and more responsive.
Position: Executive chairman
Background: AppStoreHQ is a leading smartphone discovery platform.
Ken: What sorts of skills are needed to build an app? What does an ideal team look like?
Chris: Apart from platform-specific knowledge about the unique capabilities of the device (e.g., using the camera or accelerometer, or delivering push messages), the core skills are the same as for any software development project. The following are skill areas, not head-count requirements, but on bigger projects they often fall to specialists with experience in each discipline:
Understanding customer needs, defining user scenarios, keeping the team on track
Creating logical and concise user flows, integrating visual and other creative assets (artwork, audio, video, animation) to create an engaging experience
Creating the logic and process layers required to deliver the envisioned experience: authenticating users; capturing, accessing, and presenting data; performing logic functions; integrating with other phone- and web-based systems, and so on
Systematically performing all the intended functions of the applications to identify any software or design errors; testing supporting infrastructure for scalability, load, and potential errors caused by dependencies on third-party systems
Chris: Literally thousands of firms are scattered around the world that develop apps for hire, but the capabilities of these firms, and the [resultant] quality of the applications they develop, can vary widely. The best place to start your search is among developers who have already successfully published apps of the type and quality you have in mind. The best-known publishers of top-selling apps rarely work on contract, but there are hundreds of lesser-known but extremely skilled developers who do. Look for existing apps in the category you’re focused on that deliver the quality of experience you’d like to achieve, and get in touch with the developers directly (a directory of published developers, with filters for category, number of published apps, and average rating, can be found at http://www.appstorehq.com/developers).
Ken: From what you’ve seen, how long does it usually take to build an app once the right resources are in place? What areas do first-time app creators under- or overestimate?
Chris: The answer obviously varies widely, based both on the complexity of the app and on the skills and capabilities of the team, but a typical project will take between two and three months from start to submission for approval, with that last step requiring another two weeks (if you’re lucky) or longer (if you’re not), or resulting in outright rejection (if you’re pushing the boundaries of what Apple has decided to allow that week).
Ken: What aspects of creating an app can be done in parallel? What can’t? Are there ways to get apps done faster besides having more resources available?
Chris: Projects don’t often get bogged down at the handoffs between functions like design and development; the greatest enemies of on-time delivery are poor upfront planning and mid-project changes in direction. The best way to ensure a smooth and rapid development process is to come into the engagement with a clear set of goals for your application and provide key assets like content, artwork, and legal approvals well in advance. You can also remove friction from the development process along the way by providing clear and timely guidance on strategic decisions as the app development process unfolds (just make sure your mid-stream guidance is consistent with your original goals and vision).
Ken: Although it can vary greatly, what guidance or framework can you provide to those trying to evaluate the cost of developing an app? What ranges are you seeing in the market? How can costs be reduced? Where should costs not be reduced?
Chris: App development is like any other complex project: time, cost, and quality are fundamental constraints, and making changes on any one of these vectors will necessarily impact the other two. Want your app built in a hurry? Expect to pay more and get less functionality and polish than you would if you allowed more time. Working with a tight budget? Plan to limit scope and allow extra time if you’d still like to deliver a quality experience. Based on recent market data, $5,000 is the minimum you should expect to pay for a basic app delivered with reasonable quality, but it’s not uncommon for budgets to run an order of magnitude higher.
Ken: On the flip side, how should app designers and developers think about pricing their services? Where do they typically under- or overestimate costs? How can they best promote themselves in a hot but increasingly competitive market?
Chris: The best way for app development firms to command a premium price is to consistently deliver great work for clients with recognizable brand names. This is even more effective if you specialize in a particular domain, whether it’s games or utilities. Deliver a great shopping app for a well-known brand and every product manager that competes with or aspires to emulate that brand will come knocking, asking you to do the same for them. If you haven’t yet built a noteworthy app, consider building one at reduced rates for a marquee client. If the app you deliver is good, the lost revenue from that project will pay for itself several times over in referrals and new-client inquiries. And if you constantly find yourself going over budget, look hardest at your customer communication and project management practices—the root cause is most often here (and not in functional disciplines like design or development).
Here’s what you learned in this chapter:
Your team will consist of a product manager, designer, and developer. Most likely you will take on the critical role of product manager, overseeing the vision for your app, being the primary point of contact for your customers, ensuring that your app is bug-free, and performing the marketing responsibilities.
Understanding how to vet help will make you more effective when you actually begin interacting with interested parties. Use client references, portfolios, and a willingness to execute legal documents as ways to filter your options.
Coming to terms with the costs for your app should help you realize the seriousness of your investment in it. Although there are some ways to reduce those costs, as with any venture, pursuing your app is a risk and you should be mentally prepared to lose your entire investment in the app.
Partnerships are an especially complicated approach to building apps. In theory, they seem like good options, but in practice, even the best partnerships require exceptional trust, additional paperwork, and ongoing reevaluation.
Depending on your budget and time constraints, you can work with independent contractors or an agency. The trade-offs will usually include cost, speed of development, and sometimes quality.