This chart covers all phone sales, not just smartphones, and the whole world, not just the U.S.  This teaches a powerful lesson: more marketshare does not mean more money.  Not all customers are created equally.  Android’s marketshare looks impressive, but when you drill down into the details, you discover that one Apple customer can drive as much revenue as 5 or 10 Android customers.

This is just one more reason to focus on iOS as the primary platform for your application.

Adding more people to a late software project makes it later.  – Fred Brooks

In fact, large software teams lead to project stagnation.  Doug Putnam published research from 491 software projects.  His research demonstrates that as a team gets smaller, its overall productivity increases:

And the effort to deliver a software project rises exponentially with the size of the development team:

This seems to be a very nonintuitive result.  How can it be that adding more people to a project makes it worse?

The answer is that software development requires tight communication between all members of the team.  A team of 2 requires only a single communication channel.  But for a team of 7 people, 21 different communication channels are required.  Each member of the team must sync with each other member so that everyone stays on the same page.  As new developers are brought on board, they must be caught up to speed by existing developers who are taking time away from new work to educate others.  Pretty soon, everyone is in meetings, writing documentation, managing wikis, sending e-mails, and trying to communicate with everyone else instead of moving the project forward.  It is not uncommon for members of large teams to spend 80-90% of their time on communicative tasks.  As a result, progress stagnates, and the schedule slips.

A team of just 2 or 3 developers, on the other hand, is a productive team.  With only a few communication channels, each member can spend most of his or her time working on the project instead of answering the questions of other team members.  Meetings can be reduced to just an hour or two per week, and extensive documentation can be replaced with lightweight communication tools.  Small teams appear less impressive, but they ultimately get more done.

At DrewCrawfordApps we deploy small teams on our development projects to deliver quality software quickly and reliably at a pace that outstrips large teams with dozens of developers.  The next time you are thinking about using a large team for a project, consider whether that team will be as productive as a lightweight and agile team without the additional communication overhead.

Higher Productivity and Lower Costs

According to VersionOne’s 2010 study, 66% of agile practitioners report faster time-to-completion for software projects.  More than half of all respondants report that agile has “Significantly Improved” or “Improved” their ability to respond to change, alignment with business objectives,   team morale, time-to-market, productivity, software quality, risk management, engineering disciple, and software maintainability.

But a significant feature of Agile is that developers are less likely to build software that is no longer needed.  When software development iterations are large or are done in a “big bang” fashion, the long lead times between specification and delivery can mean that the features requested are no longer relevant to users.  Shortening the feedback cycle means that engineering resources are spent on delivering features that are actually useful, instead of out-of-date by the time that they are delivered.

VersionOne found that 74% of those surveyed reported that morale was improved through the introduction of agile processes.  Improvement in developer morale not only means higher-quality productivity as developers are motivated to work harder to ship software, but also that the highly mobile top tier of technical talent can be more easily acquired by the organization.

Faster to Market

Rally Software’s in-depth study of agile development showed that Agile practices lead to a 37% faster time-to-market for software projects vs traditional methods.

Salesforce.com reports a +568% increase in features delivered to customers as a direct result of implementing agile methods.

Higher Quality

David Rico’s research on Agile development showed that Agile projects have a median quality improvement of 63% over traditional methods and a minimum quality improvement of 10% in the companies he surveyed.  84% of the VersionOne survey respondants felt that Agile methodologies had reduced the number of bugs by 10% or more.

Improved Client Satisfaction

With all of these improvements, it’s no wonder that these practices lead to higher satisfaction among iPhone project clients.  iPhone development is a fast-changing world that moves even more quickly than other types of web, desktop, or systems development.

Many potential clients make the common mistake of adapting a traditional software development process to the mobile development world, without a true understanding of the assumptions and underlying requirements of the development methodology.

The iOS software market is much  more competitive than the traditional software market, because there is only one primary sales channel–the Apple App Store.  As a result, millions of software products compete for the same real estate.  Even in a “niche” vertical, there are often many software vendors competing for customer dollars.  If a competitor is using a lower-cost development methodology, that competitor will be able to consistently deliver a higher-quality experience to its users, putting you out of business.

Even if you have no competitors, Apple itself dictates a rapid pace for the iPhone and iPad application market.  iOS, the iPhone and iPad operating system, is currently on a yearly release cycle.  Because of Apple’s highly secretive product roadmap, it is very difficult to predict the future in this market.  Apple’s rapid improvements to iOS can obsolete dozens of product lines from individual developers overnight.  Sudden announcements can cause an unforseen shift in development, due to added or removed functionality in the underlying operating system or new hardware capabilities.  In this challenging marketplace, it is more important than ever to adopt an agile software development process for your iPhone projects, both to stay current on the latest Apple development practices and to remain competitive in a marketplace of other agressive software developers.

It should come as no surprise that according to a study at Colorado University, an overwhelming 80% of respondents reported an increase in customer satisfaction after introducing Agile methods.  Agile development methodologies are an important ingredient in our overall strategy at DrewCrawfordApps to deliver the highest quality software at the fastest possible speed.  When selecting a development partner for your iPhone project, make sure you are working with a development team with an understanding of the unique challenges of the iOS marketplace and with a development strategy that will lead to success for your iPhone development project.

#1: An investor has thousands of app investment opportunities right now

Generally speaking, investment markets move much slower than consumer markets.  From an investor’s perspective, they may still be on the fence about whether apps are just a fad or a viable long-term strategy.  Meanwhile, tens of thousands of entrepreneurs see the potential and are searching for investment.  There is an oversupply of entrepreneurs looking to develop apps, and an undersupply of investors willing to get into an “unproven” market.  Therefore only a tiny fraction of entrepreneurs actually get funded.

#2: You need a core skill to be investable

Most investors are in the business of making money for their shareholders.  In our experience, investment is a very cut-throat world.  If the value you are providing is “just” an idea, and merely connecting the money with a contractor like us, the few investors who are interested usually try to cut you out of the deal as “dead weight”.  So in the rare case that an investor is actually interested in funding the project, it will be in their interest to leave you out in the cold.  Essentially you become a middleman in the transaction between the developer and the investor, a middleman who is expendable.

An investor will not sign an NDA with you, so the only way to avoid this scenario is to have some skill that is necessary for project success.  This can be knowledge or industry contacts in the target industry, an existing business or customer base that can be leveraged to sell the new product, or proprietary IP that is required for the project to move forward.  In addition to making it more difficult to be cut out of a deal, these items will help your business to succeed in a competitive marketplace, and thus will also help you attract investment in a crowded market.

#3: No previous experience

Most investors only invest in individuals with previous entrepreneurial experience.  Just like a day job in which unexperienced individuals need not apply, investors and VCs are looking to fund individuals with a track record of successfully running companies.  An investor wants evidence that you know what you’re doing, and without it, you will not be able to stand out in a crowded market.

#4: No tech on the founding team

Investors are skeptical of contractors–and rightly so, there are many sketchy contractors in this market.  Investors generally want someone with technical experience in a prominent leadership role, if not the CEO of the company, to be invested in the product and tied to its success.  Investors are usually OK with using a contractor if the internal tech lead signs off on it–but you have to have that internal tech lead to get funded.  It’s incredibly difficult to hire a strong tech lead right now, investors know this, and so they don’t want to run the risk that you won’t find someone.  If you don’t have a technical co-founder attending the meetings with the VC, you won’t get funded.

#5: No pre-sales

It’s an old adage that investors tend to give the most money to people who need it the least.  Investors tend to look for pre-sales or customers who have already agreed to buy the product before it is even built.  This goes beyond just “market research” or “focus groups”–investors generally want to see Letters of Intent, Purchase Orders, and the like to gauge the real demand for the product.  Without these items, you will be unable to compete with the many entrepreneurs who will acquire them.

So how do I get funded?

One thing you can do is use this blog post as a checklist to fix deficiencies in your pitch.  If you don’t have any sales, go get them.  If you don’t have a technical co-founder, go find one.

Another thing you can do is to start thinking about sourcing funding from friends & family or from your employer.  These individuals already know and trust you, and will be more receptive to your pitch than an outside investor.

Maintenance tasks typically involve:

• Fixing crashes or errors reported by users of the application.  Our automated bug tracking software helps us monitor bugs in the wild.  If the client has done a thorough job reviewing deliverables over the course of development and the developer is a high-quality developer, the number of errors is usually low, if they even exist at all.
• Adding features requested by users after release.  It is difficult to anticipate the cost of feature requests without knowing what they are, and the cost for this depends heavily upon the features requested.
• User support, an ongoing cost that varies depending on the popularity of the application and how easy it is to use.
• Networked applications may require hosting and administrative costs.  For example, a server might need to be rebooted occasionally.
• Scaling costs.  If your application becomes popular and uses a server or shared database, additional servers may be required or code may need to be optimized to scale more effectively to maintain high performance with more users.

Rather than signing lengthy recurring contracts, we generally recommend adding  a short-term (30-day) maintenance contract to handle minor issues after an application’s release, particularly for networked applications.  In our experience, this is usually more than enough to make minor bugfixes and add a few features to an application after release.  Major changes or additions that will not fit in the maintenance contract can be negotiated as a separate project.
Maintenance tasks typically contribute 10% of the total project size for a standalone application, and 30-40% of the project size of a networked or server-based application.

This is a little oversimplified; some of these issues can actually be overcome through Herculean engineering efforts.  For instance, although there is no officially-supported way to record phone calls, we engineered a custom solution to make it work.  But those sorts of endeavors are very high-budget projects, if they can be done at all.

Accessing user data.

Applications have strong restrictions on accessing user data.

• An application cannot read or access a user’s e-mails or SMS messages.
• An application cannot automatically determine a user’s e-mail address or phone number.
• An application cannot read data from other applications or send data to other applications without the explicit cooperation of the developer of the other application.
• An application cannot access a user’s call logs, call history, or listen in on phone conversations.
• An application cannot look at a user’s browsing history.
• An application cannot find out what other apps a user has installed.
• Even if user data can technically be collected, there may still be restrictions on its use.  You cannot just mine user data.

It should cost much less!

Sometimes it does.  Certain applications may simply not need certain components.  Coke or McDonalds may not need a PR campaign to launch an app–their existing brand recognition may be enough.  Highly technical apps designed for engineers may not require much in the way of design work–accurate technical bits may be enough.  Apps that rely heavily on off-the-shelf components may not require much QA.  And so on.

You may elect to learn some of the disciplines and do them yourself.  We’ve had professional graphic designers, marketers, and even other developers as clients, and so in these situations it’s not uncommon for a development firm to back off and have the client take more responsibility for the project–reducing the cost.  But if you’re not a professional, taking on responsibility can be a costly move when measured in terms of lost sales.

Another tactic is to aggressively cut scope to reduce costs.  It may be possible to cut features to get a Client/Server Application into the Standalone category, or to significantly reduce the complexity of the server tier by cutting features.  By reducing an application to a mere prototype, it may be possible to produce something tangible that can be used to acquire funds to develop it further.

There is also a certain amount of variation in developer costs.  For instance, we have no sales team to pay, and since we rely primarily on the strength of our work for business, our marketing budget is close to zero.  So our costs tend to be lower than shops with an army of sales staff and billboards on both sides of the street.  On the other hand, our estimates tend to be more accurate than the competition, and since projects are universally underestimated, sometimes realistic numbers can be higher than what others quote.  These effects can cancel each other out.

But far too often, instead of responsible scope cuts and other cost-cutting measures, corners are cut instead.  Software may be outsourced and developed poorly, QA may be forgotten entirely, design may be sent to the back of the bus, and so on.  In the rush to ship some product, it’s easy to lose track of what the value of that product is.

Suppose you are trying to build a strip mall in a populated area.  You find a plot of land that is next to a high-traffic road, do some research to determine that a strip mall could be reasonably successful, and start talking to architects and contractors.  They tell you that a typical strip mall is constructed for in the neighborhood of $5M.  Unfortunately, you only have $20,000 for the project.  Undeterred, you start trying to cobble together a team of temporarily-unemployed electricians on Craigslist, some freelance architects in India, and since the budget for materials is tight, you decide to construct it from corrugated cardboard.  It does not take a genius to work out that this will not be a successful project.

In fact, there are many successful avenues open to you–with $20,000 you could build a furnished treehouse or shed, you can give your home a new room or a remodel–these are realistic construction projects within your budget.  These projects have the advantage that you are not simply throwing your $20,000 away.

The same common sense does not seem to extend to iOS projects.  Undeterred by the true cost of building that strip mall, many people are trying to piece their apps together out of corrugated cardboard.  But unlike the construction industry, where there may be building codes, inspections, city ordinances, standards of practice, and professional organizations to protect people from scams and swindlers, there is unfortunately no equivalent for software development.  It’s the closest thing there is to a completely deregulated market.  And it’s the perfect condition for a lot of companies to come out of the woodwork to say what people want to hear–that with this industrial strength corrugated cardboard, you too can own a strip mall!  It’s a sales pitch older than Amway.

With good advice from the right developer, you can figure out what is possible within your budget and execute a sensible plan instead of an insensible one.

Wrapping Things Up

I hope this series has shed some light into the time, effort, and cost it takes to launch a successful iPhone or iPad app.  I’ve barely scratched the surface of what goes into project costs, even in a massive three-part blog post!

There are many factors to consider when thinking about any software development project, and every situation is unique.  If you’re interested in talking to a real developer about a realistic way forward for your project, get in touch.

Development

Any iPhone or iPad app is going to involve developers, people who write the software code.  Depending on the firm, these people may be called software developers, programmers, or engineers.

For many apps, the developers are the people who make or break your software.  Good developers can mean applications that run quickly, are powerful, and generally behave as expected.  Bad developers mean buggy, crash-ridden software that’s behind schedule.

An entry-level salary for a software developer in the United States is $50-60k.  Developers with several years of experience are often paid $80-90k, depending on location and workload.  Very simple applications (at the low end of the “Standalone App” category) may require a few weeks of developer time, more complex applications may  require six months and several full-time developers.  Considering an average time of two months and two developers, you’re looking at a cost of $30k in developer time.

It’s important to meet the actual people who will be responsible for developing your application.  Many firms are much larger than we are in sales staff VPs, managers, etc., but have about the same number of developers!  Others may simply be a friendly sales force for a low-quality overseas development shop.  Don’t let anyone pull a bait and switch! It’s not enough just to evaluate the sales guys for compatibility with your project–they’re paid to be compatible.  Make sure that you talk to the people who will actually be responsible for implementing the project, and ensure that they share your vision.

What about outsourcing?  Can’t I cut costs there?

I’ve written about outsourcing in the past.  Like everything in life, you get what you pay for.  There are wonderful overseas development shops that charge rates competitive with US developers.  If you are paying below market, you are asking for trouble.  Far too much of our work is fixing botched outsourcing jobs that could have been done right the first time at much less cost than it will be patch it up, both in terms of development time and effort as well as lost customer trust as a result of a buggy application.

QA

A good QA department can catch bugs and problems in-house before they escape in a test build, or worse, to your customers.  Every project needs a solid second pair of eyes to spot programming problems and squash bugs.  Good QA engineers bill $50-75 an hour, and you probably want one hour of QA for every three hours of development to spot bugs.

Design

In addition to development work, you need designers, people who lay out the user interface, produce artwork, and do other graphical design work.  It’s possible to have a good developer that drifts into some light UX design, or a good designer that drifts into light frontend development, and so you may find slightly different divisions of work across different types of firms, depending on the skillset of the individual people.  Smaller application developers tend to work with outside designers or have a few contractors “on-call”, whereas larger firms can have entire graphics and UX design departments in-house.  Larger corporate clients may already have an in-house design department that they’d like to use, so the background of the development firm and the makeup of their clients can have an impact on the design skill.

Again, it’s important to communicate and share your vision to the design team.  It’s also important for the technical and design team to have good rapport and to get along well.  Animations or dynamic visual effects may have complex technical and design requirements that require both skillsets to move in lockstep, and the last thing you want is for artwork to be produced or a technical solution to be chosen that is incompatible with the other!  It’s usually important to ensure the artists or UX designers have a good track record of designing for mobile software (as opposed to graphic design, web design, etc.)

Senior UX designers with some development experience are typically worth about $80k/year.  Graphic designers with more limited experience generally earn about $55k/year.  With an average figure of a designer with medium experience for a month, you are looking at about $7k for typical design and artwork production.

Management

Someone needs to coordinate and oversee project development.  At small firms like ours, senior developers may take this role and oversee and coordinate development, design, and the other parties in the dance.  At larger firms, project management may be a dedicated department with a sizeable staff.  Software development managers typically make about $120,000/yr, but usually oversee multiple projects at once, so the actual cost of that person for a single project may be closer to $5k-10k for shorter projects.

Marketing

A successful app launch often requires an extensive marketing campaign.  In today’s market, it is difficult to stand out from the crowd.  Retaining a PR firm can run anywhere from $5,000-$25,000/month or more.  Some PR freelancers bill in the neighborhood of $100/hr for basic press release and whitepaper writing if you want more of an “a la carte” public relations approach, but the economics of the app store often dictate doing an all-or-nothing marketing push over an incremental marketing model.

Tools & Technology

In addition to personnel, it takes specialized tools to create mobile applications.  Software has to be tested on a regular basis on every conceivable device, and so many firms stock up on dozens of test devices in multiple configurations.  Professional developers wear out computers far faster than consumers do, and so it’s not uncommon to budget $10k in new computing equipment per developer per year.

Then you need to factor in software licensing and costs.  The advent of open-source software has reduced these somewhat, but custom tools are still a requirement.  Professional-class bug trackers typically run about $5,000/year for a site license.  Source control hosting, testing software, database editing tools, Photoshop, and other tools of the trade have to be licensed.

Then you must factor in custom frameworks or components to be licensed for use in applications.  Because we’re a very focused company with almost all of our work in iOS, we’ve invested in building an incredible volume of pre-built libraries that are more readily adapted for iOS use (see our articles on CrashBuddy and LogBuddy), and so we tend to have a reduced licensing burden than other firms, but this comes at the cost of our developers’ time to write and maintain those libraries.

Then you have your typical overhead: office space and furniture might be $1000/month/person in a midsized city.  IT, servers, backups, infrastructure, hosting, e-mail, and internet access might run another $250/month/person.  Benefits, taxes, and payroll probably add about 15% to the cost of every contract.

The Final Bill

Consider a fairly simple application that is on the books for two months.  The cost structure might look like this:

• Two developer salaries, two months: $25,000
• One designer salary, one month: $7,000
• Tech lead / project manager : $5,000
• QA: $6,000
• Office space, computers, equipment (amortized): $8,000
• Software, licensing (amortized): $1,500
• Benefits, taxes, payroll: $8000

The final cost to develop our simple application (leaving no profit for the firm) in this case is $60,500.
It’s important to emphasize that these are typical figures for an application of arbitrary size.  Some apps have more or less development costs, more or less design costs, etc.  As discussed in the first part of this article, there are many different types of applications that may require more or less responsibilities from each of the necessary disciplines.

Also factoring into the price, different firms tend to emphasize different disciplines.  We are a developer-driven company, where software developers take more of an active role.  There are talented design-run or management-run firms, in which those skill-sets tend to be more emphasized and tend to extend further into territory traditionally controlled by other disciplines.

In addition, however, there are a few operating costs.  Considering a 12-month application life (many applications run shorter or longer), you may be looking at:

• Hosting costs: $500/month for 12 months
• Support contract: $500/month for 12 months
• PR/marketing: $5000/month for 3 months

e.g. an additional $27,000 in the first year.
So how does our $87,500 number for a simple application stack up?  Chockenberry, the developer of the award-winning Twitterific application estimated their total cost at $250,000.  Twitterific is a design-heavy app in the “Pre-existing API” category, which is much more complex than our simple application.  Another data point is the Barack Obama application, which reportedly cost $50-150k, also in basic agreement with our number.

Was this a lot more than you were expecting?  Continue on to Part III!

App Types

iPhone or iPad apps are not all alike.  You have several different kinds of applications.

Each of these application types may require a slightly different skill set, have a different time and cost profile, and require developers with different expertise.  Counterintuitively, it can sometimes be a mistake to try to find developers with experience building applications very similar to yours.  Generally speaking, developers with experience writing very complicated application types will be more effective at simple applications than those that have only developed simple products (Just as mathematicians are generally better at Algebra than high school graduates).  And so it’s important to identify the type of application you’re building in order to assemble the right construction team.

Standalone applications

Standalone applications are self-contained.  These applications can do data processing, display static content that doesn’t change, manipulate documents, and do other types of basic tasks.  Development time and effort varies primarily based on the type of processing required (file format support, etc.) and the complexity of the user interface to design and implement.

P2P applications

Peer-to-peer applications do some light app-to-app networking, like a multiplayer mode for a game.  They generally involve connecting with nearby users over Bluetooth.  This type of networking requires additional debugging and testing involving multiple phones or devices.

Pre-existing API or integration applications

The next tier of complexity are applications that talk to pre-built servers.  For instance, your company may have a database of information to be queried by the app, or you may be accessing data from a third-party data source.  Time must be allocated to learn the quirks of the API or server, to debug problems with communication, and to handle unusual error conditions.

Client/Server applications

Certain applications requires a server for off-phone storage and processing.  For instance, if your application allows users to save reviews, share status updates, search for nearby users, display content that updates on a regular basis, or other nontrivial tasks, a server is required to store and distribute this data to all devices.  Client/Server applications are one of the most common types of applications that people want to build.  Unfortunately, because Client/Server applications require both complete application development and complete development of server software, plus hosting and other ongoing costs, they tend to be both one of the most complicated and most expensive project types.

Multi-platform development

Apps that run well on more than one platform must typically be rewritten largely from scratch for each platform.  So if you are looking for an app that supports iPhone, iPad, Blackberry, Desktop Web, Android, and Windows Phone 7, you are looking at approximately 6x the cost of what that app would be on one platform.  If the platforms communicate in a networked manner, care has to be taken to define standards in an interoperable way.  In addition, most cross-platform projects engage different development teams for each platform, as most developers of quality only know one or two platforms well.  Doing cross-platform development correctly often requires the engagement of multiple firms as well as a “master” firm that writes the general specification.

Specialized technology, research

Some applications, like Augmented Reality applications, indoor location systems, or other technical challenges may require the development of novel methods or intellectual property.  Like any kind of invention, the time required to develop new technology is unbounded.  Many different approaches may need to be tried and combined to achieve the desired result, or the result may not even be achievable within the limitations of the current generation of technology.

Impossible applications

We sometimes get request for applications that are not possible on iOS, at least in the App Store.  These include things like affecting the behavior of other applications, modifying system settings, disabling features of the phone, accessing restricted data such as user e-mails, etc.  Apple has limited what App Store apps can do in order to prevent malicious apps from stealing user data, breaking a phone, or other matters of poor user experience.  If it’s a simple idea that doesn’t already exist in the store, it’s probably because technical or legal restrictions are in place that prevent it from being easy to execute.

Now that we’ve identified the type of application and learned something about the required skillset, it’s time for Part II: assembling the team.

It’s easy to forget in the marketshare battle that Apple’s dominance is much larger than phones.  iOS software runs on three platforms: iPhone, iPad, and iPod Touch, with a combined install base of over 200 million units.  Not to mention Apple’s 11% North America market share in the computer world, which has its own app store.

That’s why we’re focused on delivering native software for Apple platforms.  While we see room for growth in the Android market, we believe that the iPhone and iPad will continue to be the #1 mobile development platforms for the forseeable future.  The iPad is growing so quickly that it’s eclipsing the need for PCs in many situations, but only at the rate that important software can be written and adapted, an important bottleneck.

We’ve written many iPad applications for companies large and small.  Contact us to learn about how the iPad can work for your business today.