For however much you may know about a particular subject, there’s likely to always be more. What you don’t know, can help you. When setting out to create a mobile app, utility or game, you likely have a vision of how the completed app will work, how it will look, and all of the things it can do. It is worth taking some time to go even deeper.
One of my recent projects involved creating a scenario for The Falkland Islands War between England and Argentina in 1982. That’s a very small project in comparison to my World War II “War in Europe” projects. The Falkland Islands was a small war, lasting only about two months with each country fielding only about 2 brigades each. Yet, for its small size, it includes all of the complexity of much larger conflicts.
In games like this, typically only a few things are really needed – the map, the units involved (Order of Battle), the equipment in the units (Tables of Organization and Equipment), when using a game platform like The Operational Art of War. With this collection of information, one can roughly recreate any type of battle from Alexander the Great to Napoleon to modern warfare engagements.
But a wide range of other factors can be taken into account. Nevertheless, even considering all of the things that you can apply to a game’s design or an app’s functionality, there are a lot of things that are easily overlooked. It is safest to presume from the outset that will be the case.
Asking for help is not a sign of weakness. Turning to other professionals to get their insight can transform an average app or game into an excellent one simply by listening to what they have to say. This can work for any number of social and professional networking platforms such as LinkedIn, Quora, MosaicHub, and others. Most especially, sign up to groups relevant to what you are working on. Explain what you are aiming to do and ask if anyone has anything they would like to see included.
The devil is always in the details and it can be that extra little complexity that makes your app unique enough to stand out against so many other apps, utilities and games. You might be making a utility app for medical students, but getting the input of doctors, nurses, insurance processors, possibly pharmacists, can broaden your potential list of functions. Ultimately, you decide which functions you will include but without reviewing the input from each user segment can mean not implementing some really easy things that will help your app shine.
Enough people are happy to lend their expertise to more than justify the effort. The level of professional input I received on this particular game project exceeded my expectations several times over. Most of it was easily implemented and essentially “makes the game complete”.
A recent survey by PerfectoMobile.com involving over 900 users indicated 44% of mobile app defects are found by the end-user impacting the app’s functionality or even rendering it inoperable. This pinpoints the obvious need for more testing across a broader range of mobile devices. This is not easy even for big companies. So, the focus here is what you can do to entice a robust beta test team without having to hire them.
1. Internship or Apprenticeship Program – Starting on the high end, this requires some work on your part, but it can offset substantial overhead when it comes to payroll. I’m a big fan of both types of programs as they stand as solid alternatives to the traditional college and university systems in countries where tuition can be exorbitant. Virtual internships (telecommuting environment) are also becoming popular.
Per Wikipedia – An internship is a method of on-the-job training for white-collar and professional careers. Internships for professional careers are similar in some ways to apprenticeships for trade and vocational jobs, but the lack of standardization and oversight leaves the term open to broad interpretation. Interns may be college or university students, high school students, or post-graduate adults. These positions may be paid or unpaid and are usually temporary.
Both approaches require setting up a training program, providing oversight and feedback to the student or apprentice. You can also aim for an accredited program by working with specific colleges and universities which can pave the way for finding interns every year. Accredited programs involve developing a formal work-study program, basically an outline of what the intern will do and what the value of doing that is.
This is experience that they can put on their resume which you can back up with a formal letter of appreciation. If your growth permits, this also provides you with candidates already familiar with your company who may fit in better.
Considerable thought should go into this. Interns could even be tasked with managing other parts of your beta testing, thus some practical managerial experience complementing the technical components of their work.
2. Localization plus Revenue Share – Another high end component is to look for potential partners who are in markets where platforms and devices outside your normal prevue prevail. Just as an example, if you were looking to have your app available for Blackberries, you would likely want to look at South Africa – the one country where Blackberry still flourishes.
You will need to negotiate with any prospective partner the scope of work, share of revenue and all the things that go with it. One approach is that in exchange for beta testing and quality assurance of your app for a platform and/or range of devices, that they receive a distribution license of their own good for their local market, a
However, this approach provides an opportunity to have specialists in specific platforms and devices do the testing which should result in lower defects.
In exchange for their beta testing and quality assurance of your app for a platform or range of devices, you can offer them a limited distribution license of their own. This would probably include authorization to localize your app into their local languages. It would also be appropriate to require their localized apps to indicate they are the result of a joint effort between your company and theirs. There are different ways this can be handled.
3. Advocates – Easier to arrange, this involves working with specific people who want to be associated with your company for reasons other than employment. They might be friends, they might love your app, they have a high profile in the niche serviced by your app, etc. These might be players, they might be “guild masters”, they might have blogs or web sites of their own. These are good people to have on your side and it helps them look good by having you on their side. In exchange for their beta testing efforts, you can reward them with free apps, giving them tickets to “exclusive public previews”, a guest article on their blog, interviews, and inside news of what’s coming next. These can be your most loyal, die-hard supporters – keep them happy and they will go out of their way to make you happy and not just on the beta testing.
4. Company beta-testing – Another approach for utility-based apps is to try to work with companies that would benefit from your app. This can be a bit harder to swing, but if your app stands to be particularly useful to certain professionals – it is something they need and want to make their job easier, they will likely be willing to invest some time to help you iron out the wrinkles. It will likely require networking with their programming or technical managers, CTO, or perhaps CIO. You can sweeten the pot by assuring them that they will receive a nice placement in your credits.
5. Bounty Hunters –This will require you to actively maintain a web page listing all of the feedback as it comes in. A typical forum like phpBB would likely be sufficient. The basic idea here is to award a nominal cash prize via Paypal to the first person who finds and reports a bug – perhaps $3-5 each. Alternatively, if your app involves in-app currency or prizes, those can be used as substitutes. This probably works best with games.
6. End Users – Most companies tend to rely upon end users for almost all of their beta testing, so this isn’t included in the “point count” or why this post isn’t “Six Ways to Build your Beta Team.” End users can be really good for getting a volume of beta testers, but many will be dead-weight, simply wanting free access to your app without providing you feedback. Still, that can be good if they ultimately really like their game as it paves the way for word of mouth referrals.
Crowdsourcing via the various crowdsourcing boards, or simply outsourcing your QA on a device or platform basis are also good altneratives. They are not “new” either.
You are not limited to one method, and really given the follow-on benefits of each, it can be worth aiming to include all of these methods for a true, high quality public release.
Apps on Opera Mobile Store are downloaded in 230 countries and territories. Make your app available to millions of customers around the world – Free, Fast and Easy, Sign-up here!
If you are needing to bootstrap your mobile apps, the following articles can provide you additional tips and perspectives to help you maximize your efforts:
There is a tool for everything. There are so many tools for so many different purposes that it is difficult to keep track of them. Here is one that tool that works well for a variety of analytical purposes, especially in helping to define and isolate problems to their root cause. This is called the Ishikawa Diagram, Fishbone Diagram and/or Cause-Effect Diagram. It can be easier to use a tool than describe how it is used, so interested readers might refer to Wikipedia for more details.
The function of this tool is to show the causes of an event or problem. The intention is to go beyond that and to identify “the fewest causes responsible for the most problems” – following the Pareto Principle. The consideration is that you also want to prioritize the tackling of problems according to how strongly they impact your business and profitability.
Simply, the idea is to define the major contributing parts of a “Cause” – which as Wikipedia shows, can vary according to the type of work you are doing. Customize this to your project. As it shows, the major parts associated with marketing are known as the 7 P’s – Product (or Service), Price, Place, Promotion, People, Positioning and Packaging.
Details are then added to each Cause. Where the type of machine being used by the end user can be a “cause for a problem” – you might have a long list of mobile devices. The extent of your testing could be a factor, suffice that your focus is on the devices in which your app is not working as intended. Listing all of those out might help define a common issue.
The Root-Cause Diagram itself should help you get pretty close to the problem, but is best used with The Five Why’s. The aim of asking, Why? Why? Why? Why? Why? Is to break a problem down until it cannot be broken down any further. The answer to those five why’s should help explain how the root cause of a problem can be effectively solved.
Wikipedia points out here that “people do not fail, processes do.” Perfect the process and you will get good results.
These tools and techniques work even better when part of a broader quality control and process improvement program – whether Lean, TQM, Six Sigma, or otherwise. Each has its nuances and their effectiveness is debated. Everything does not need to apply to the rigors of a full-fledged Black Belt project. Many of these things can be done on the fly, based upon priority, deadlines, budget, etc. When you apply to “the process” long enough on a variety of different projects, many problems are resolved before they ever happen.
As we’ve looked at many of the different expenses associated with app development, we should be able to define a pretty good breakeven point. As long as you are breaking even, you can do whatever you want to do for as long as you want. Unfortunately, defining our costs is only half of the equation. It is the easiest half, but is frequently ignored for the second half, i.e. actually trying to break even. If you don’t know your breakeven point, in most cases you won’t really know if you are making a profit. [Editor: About 60% of mobile developers are not breaking even – see this PCMag article and app-promo.com infographic.]
If you have a day job that more than meets your cost of living requirements, you have far more latitude in defining your breakeven point than if you are completely reliant upon your app development for your livelihood. A good day job offsets the need to include your labor, your computer and mobile devices that you already have, probably your utilities, rent and insurance, too. However, if you are looking to switch to mobile app development on a fulltime basis, you will want to track your relative performance on a reliable basis (say 3 to 6 months of your app-based income) before making a transition. That is, you may have a day job but develop apps in the evenings as a sort of second job.
Several surveys indicate that the cost of developing a relatively basic app runs up to $10,000 over 3 months. As mentioned previously, you don’t want to be in a position of relying upon a single idea for a mobile app. You want several apps to evaluate – examining each relative to your means (programming skills, graphics, marketing capabilities, time, possible difficulties, etc.) and the app’s potential (what others think of the idea, compatibility, target market demographics, etc.).
Before we get into defining your marketing budget, you need to define your revenue model/s. Will your app be free to play and rely upon in-app advertising? Maybe freemium with in-app purchases and upgrades? Premium? Subscription model? Do you have any B2B components or sponsors? Will your app have other possibilities for monetization (i.e. survey capabilities, promotion of other apps, prominently focus on email and newsletter marketing)?
We also want to take exceptional care in defining your target market. There are two parts to your target market. The first part is the largest and includes your end users, the people who will play your game, use your utility, etc. The second part considers what businesses, products and services your end-users will be interested in – thereby opening doors for business to business possibilities, as referenced above. If you are able to reach people specifically interested in one thing, your app will be of interest to others trying to reach those end users, too.
This deserves an entire article (or five) unto itself. Your app pricing ties into both your target market/s and your revenue model/s. Of particular interest on defining price for your target market, if you are marketing on an international basis, you will want to include price segmentation for end users in different countries with widely varying incomes.
Your earnings are based on the number of downloads your apps receive compared to total number of downloads relative to total subscription revenue per pay period.
This is the one model where you don’t need to budget any advertising costs unless you want to reinforce this program, probably focusing on social networking methods.
With this, I will cut it short and aim to provide some specific examples on Wednesday drawing upon the points here. It seems worthwhile to go through the full breakeven analysis process, too – so we may do that on Friday. The most important components here are delineating approaches to doing the critical thinking on your own to apply to your own apps.
About 60-65% of developers are not breaking even with their mobile apps. Congratulations if you are! [Editor: About 60% of mobile developers are not breaking even – see this PCMag article and app-promo.com infographic. ]
What is “breaking even”? That depends upon whether you are expecting to see money for your time, or not. You might be a first time app developer not expecting to make money. You might be donating your time for a cause, or engaging a particular app as a “labor of love”. In these cases, it’s reasonable to not expect money for your time.
Otherwise, you are likely expecting to at least meet the costs of developing an app. Understand, too, that as a business, depending upon your countries and laws, your business expenses are deducted from your earnings. Properly managing your expenses can save on your taxes. Even if you are not engaging app development as a business, it probably does have an impact upon your cost of living.
All of the following are expenses:
If you goal is to make a profit on your mobile app, these items and probably more (minus your time) can be used to help define your breakeven point.
If you do plan to make a profit, you do want to include your time. That is especially the case if you have no other form of revenue. The same applies to any employees. Cost of labor is likely to be your #1 expense when it comes to mobile app development.
Wages and salary are significantly influenced by the country, sometimes the state/province, and even the city or neighborhood, in which you live. A programmer in New York City might be earning $100 an hour while the same developer in Ukraine might make $8-10 an hour.
As your own boss, you get to set your own wage/salary expectations. The only question is meeting them. Monthly wage is probably easiest to start with, as you know your monthly expenses – you want to recover those expenses and get ahead some.
The idea is that as long as you make $x per month, you can do what you want to do, indefinitely, for as long as you want. That’s an awesome position to be in. It beats having to do a job you detest, forever. It passes the “Hot Fudge Sundae or Hot Poker in the Eye” test, hands down.
Any extra money you make should stay in your business account or remain allocated to your business. Handling your extra “business” money is a completely separate topic.
Adding your real business expenses with your expected (reasonable) salary provides you a real breakeven point to work with. It provides you the basis of comparing and analyzing your prospects for success with a specific app.
There are a few points to conclude with: