Apple’s App Store and the Google Play Store have completely transformed the way companies can find a “shop front” for their product. Having said that, the competition is beyond fierce. Pocket Gamer maintain a record of how many apps are submitted to Apple’s store, and the figures make fascinating reading.
Typically, the number of apps submitted daily ranges between 2500 and 3000. In September 2016 over 160,000 apps were submitted in one month alone. As such, there’s always some work to do to get your client’s apps found – let alone noticed on a serious scale. With that in mind, here are five app store optimization tips to give those apps the best chance of success:
Concentrate on presentation
It seems incredibly obvious, but there are thousands of app developers and agencies who, in their hurry to push an app live, allow their apps to look extremely lackluster once they hit the stores.
For far too many people the crucial details – the screenshots, app logos and description texts – are little more than an afterthought once the hard work of actually creating the app nears its end. This is a really short-sighted approach.
To increase your clients’ chance of success, make sure they understand how important this presentation is. Producing the app description, for example, should be treated as a serious task in itself. It should never be something that’s quickly thrown together and highlights endless features instead of benefits.
The combination of graphical elements, screenshots and descriptions will often be the first a potential customer sees of an app, and has a huge bearing on the number of downloads. It’s up to you to ensure your customers understand this, and place sufficient importance on the related tasks.
Ensure apps have a Unique Selling Point
Again, an obvious one on the surface, but something many people forget. With millions of apps to choose from, there’s simply no point in copying what’s been before – every app that stands a chance of being successful needs a way to stand out.
This is something to bear in mind at the early stages of app development. If a client is proposing an app that’s been “done” dozens (or more) times, they need to understand that it needs an edge over the competition – otherwise obscurity beckons.
Remember testing and quality control
App testing is time consuming and repetitive, but this should never be used as a reason to take shortcuts. Customers will soon catch on if an app doesn’t do what it says on the tin, and Apple might too.
This quality control focus must be maintained long beyond version 1.0 and the Minimum Viable Product stage. Even a well-established app can be dealt the kiss of death if you push out a poorly tested update. One minute you can have a great looking listing, then before you know it the App Store is showing a one-star rating under “latest version” because someone forgot to make absolutely sure the new version worked properly on (for example) an iPhone 6 Plus.
Effective quality control requires constant co-operation and dialogue between all the developers, the agency and the client. Most importantly, these parties should learn the importance of slowing down and not rushing either products or updates to market.
Remember also that you just to test more than just the app. A/B test your app store listing to see which keywords users are looking for – not just the words you THINK they’re looking for.
It’s a tad clichéd but it’s better to do it right than do it fast.
Apps with poor review scores often get completely ignored. Add to this the fact that end users can often prove unfairly savage (even when they’re only paying pennies), and you have the potential for the all-important review section to destroy the success of your app.
However, if you time things right, you can encourage people to give credit where it’s due. Perhaps consider a “give feedback” prompt when users have clearly been using the app as it’s intended without problems. In-app analytics can help with this.
Another thing you can do is encourage people to leave reviews during other interactions with them – perhaps via clients’ websites and social media. It’s also worth working on building a good relationship with frank, honest and informative update notes when bugs are fixed. Some well-known companies including Slack really excel at this.
Don’t forget other means of marketing
Finally, don’t allow your clients to think that the app stores aren’t the only places to showcase their apps. The stores should be just one part of a combined marketing effort than can include promotion on company websites, social media work (including paid targeting) and PR efforts to have apps featured in external reviews and “best app” roundups.
Sometimes the bug successes and download surges come from these exercises, and not because of how the app’s been presented for the stores.
So your business builds mobile apps for a range of business clients. That’s a great place to be right now. Lots of opportunities. Lots of potential projects coming your way. When we talk to busy mobile app development businesses they tell us one of their biggest challenges is getting the mobile app build project properly scoped. Too many times projects become too organic with new requirements emerging through the life of the project, sometimes too many ideas on what the app should do and they find it difficult to really define what success looks like. What we’ve found is that if you can get good insight into the project by getting answers to these 20 questions right at the start of the project, its more likely to be a success, both for the client, and for the mobile app agency.
Firstly, it usually starts with your new client coming to you with a great idea for a mobile app that will help revolutionize their business and reach out to existing customers and a whole new set of customers. That’s awesome!
A project that starts off in the right direction has more chance of ending up in the right place, so here’s 20 questions you need answers to before you start that mobile app build.
Can you summarize the Mobile App to me in just a few sentences?
This isn’t to catch the customer out, it’s to really see how well they understand the “essence” of the app. The better they understand it, the more confident you can be that they will be very exact and focused about what the app needs to do, who its focused at, how they will use it etc.
Who are the target users?
What problem is your app going to solve for them? Why is a mobile app the best way to solve this? Could a mobile responsive website be just as good, or an even better way to solve the problem? What devices or platforms are they most likely to use, there are real demographic differences between android and iOS platforms that need to be thought through.
What’s the real deadline?
Is it linked to any other activity (a big product launch) or tied into a seasonal campaign? So its usually the case that the project should have started yesterday. But at least you can work out what’s possible with the time you have. Work back through AppStore submission, multi-platform testing, development, and creative, ideation to set the expectation early on what’s practical and what’s not in the time you’ve been given.
What risks are there with the mobile app build?
What are the outside dependencies that could affect the timescales? Addressing this up front will save you a lot of problems further down the track. Building a risk register as part of the project kick-off and being disciplined to keep this up to date is a good idea, even for what seems to be a simple app product. Make sure that for each risk there are actions and owners responsible for managing down the risk of this affecting your successful app delivery.
What’s the budget?
So the game usually is, we don’t have a fixed idea of a budget, we want as much as we can get for as little as we need to pay. Mobile projects are really difficult to budget estimate, but for you to scope the project you need at least to work to a range. Defining the scope of work is also really important. It not just about the physical build. Is there budget for researching the app, competitors, key functions that users will highly value that will guide you on what the first release (or minimum viable product) NEEDS to have for the app to be market ready. If it’s a new client it could become a tricky game of poker, neither side wanting to show their hand, but unless you get to a range pretty quickly, expectation management is going to be tricky. If the client can’t give you a range, that could be a red flag, it may not be a serious project but just a vague idea they are trying to flesh out.
You should also agree what the ongoing budget is going to be once the app is live. There will probably be hosting costs, ongoing optimization of the app, on-boarding and in app use, discovery optimization, push notification services you should be offering – as well as managing scaling out back-end systems as app user grows. Knowing how much ongoing work the app will require could also influence how much you charge in the initial build phase. You could decide to scale back costs on the initial build and get the app to market quicker, then work with the app owner to continually improve the app over time. They get an awesome app that’s just getting better and better. You build long term income streams for your business and long term relationships with your clients.
Who are the key Stakeholders?
Is this who you are working with, or are their others that you need to know about? Who is the budget holder? Who is the Project Owner? Your contact, or someone else. What are the decision making stages? Who need to be consulted at what stage to move from Ideation, to prototype, to build, to test, to release? Who are you going to work with post launch? Is there a formal process here (you should hope there is), or is this a more organic process, and if so its point 1 on your Risk Register, in big, bold, black ink capitals.
What does success look like at each stage of the process?
Building this into a number of smaller phases, with approval “gates” you need to go through may sound bureaucratic and feels like it could show you down, but it will, without doubt, save you time, money and a lot of anxiety through the mobile app build.
What are the business objectives for the mobile app?
Is the mobile app an internal app to increase workforce efficiency? Is it there to open the product or service up to a new profile of user? Will it increase sales from existing customers? All good, worthy reasons to build an app. Answers to this question will have a huge influence on how you build the app, what the core features and functions of the app, what platforms it needs to run on and what analytics and Key Performance Indicators (KPIs) you need to track once the app goes live.
Who will the app compete with?
Has the client done a detailed evaluation of competitors in the space that you can work from? Don’t accept the response – “We don’t have any competitors here, we are the first to do this?” It’s a common response, but one that’s usually not true. There may be no direct competitors doing EXACTLY the same thing, but that doesn’t mean that there aren’t other ways that people are solving the problem that they have. This shouldn’t be an App to App comparison. So ask the question “how do the future users of your app currently solve this problem?” that way you’ll probably get a more insightful answer.
What design considerations/constraints does the Mobile App have to work within?
Are there corporate guidelines that the mobile app layout and screen designs need to conform to? Will this work on a mobile format? Are there constraints on how it can appear in the app store. Will this tell you how the icons in the app store need to look? Will this limit how the app will pop-out at someone browsing the store? What scope is there to push back on the branding police to get some design latitude to let you do an awesome job?
Is there scope to have multiple releases?
This is both in terms of what native platforms you need to build on as well as functionality. Is it possible to focus on a minimum viable product (MVP) as version 1 release, with a feature roadmap? Does it have to be big bang with all features on all platforms day 1. This may be desired, but is it REALLY a necessity. Even if you need to go Big Bang, its still good to work with the client to define and agree what the minimum viable product (MVP) NEEDS to be. That will help focus discussions around the budget and timescales for launch.
What is the backlog of functions for the app?
Even if you’re not using an agile software development approach to building the app, getting your clients to build a backlog of (non MVP features) is a very powerful way to get them to prioritize between the essential functions of the app and those that are non-core for version 1 release. This has the other benefit of helping you plan future releases for the app, important for App Store discovery optimization (ASO) and managing your future project work (and cash flow).
What are the underlying assumptions?
Is it to work across tablets and mobiles? Can this be one version that resizes or do you need a build for both? How back compatible does it have to be , iOS8 and later, Android 5.0? Android 4.0?. Does the app need to work offline? Will it have to connect with wearables or Internet of Things devices? What languages is the app going to be built in? The answers you get to “Who are the target use of the app?” will obviously have an influence here.
How is it going to be hosted?
Is there an existing infrastructure it needs to plug into? What are the security protocols? Are there any upstream micro-services that need (or would be good to) plug into the app? Is there going to be a website (mobile responsive of course) that will sit along-side the app and have to share user profile information etc.? Are there any other vendors that the app needs to integrate with (salesforce, SharePoint etc). How are you going to manage user generated content and what’s the expected upload/download shape of that content? Take the complexity away from building and managing the server side of your app with an industry leading mBaaS tool.
What are the data points that your client will need to get from the app?
Baking the measures, metrics and benchmark objectives into the mobile app at the design stage will help make sure that the mobile app build phase delivers against the key measures of success. If you don’t define the key metrics, that underpin the tangible measures of success for the app at outset, how will you focus the decision on MVP features? Also mapping out the analytics and metrics during the build will save the agony of trying to retro-fit these late in the day, or worse be duped into judging the success of the app based on what’s easy to measure, rather than what are actually the true measures of success. Core to this should be measures of recency, frequency, duration & lifespan.
Clients want to know
How many downloads?
On what platforms?
Ratio of push notifications activated?
How many that download are actually fully installing?
How many active users you have (is this growing)?
What features are being used the most?
Where are the dead areas of the app that need re-thought?
How frequently is the app being used?
For how long (use session length)?
How many transactions (sales) have completed?
Mapping the actual against expected, looking at the variance then working a plan to close the gap between actual and plan is what it’s all about. As long as these are defined up front of course. You’ve got a huge role to play here, and a huge opportunity to generate on going monthly recurring revenue from the initial app project to help the owner of the app optimize and improve the commercial performance of the app.
What is the monetization strategy for the app?
If it’s a B2E app, solving internal problems for a business to improve staff productivity, then there is still a money angle and a Return on Investment business case. If it’s designed to increase revenue for the business, how is it going to do that? in app purchases?, subscription model?, will features be unlocked with staged payment?, is a physical or virtual product being delivered after payment (so do you need logistic tracking)?, will there be in app advertising to monetize traffic through the app? Knowing this and building the app around the business goal will keep the client focused. Agreeing the MVP and building the Backlog of features acid testing each feature and function against the business goal will mean you’re focused on doing the important things in priority order.
How will they buy?
Different from monetization. How do they physically pay for the product or service within the app, credit card, biometric payment (ApplePay and the like). Depending on the answer, you need to be thinking about security/encryption and device compatibility the app must work on. So testing regimes, influence that Native vs Hybrid decision, security & data encryption etc.
Are there other apps that the client likes that can be used as inspiration for how this new app should look?
This isn’t about copying or plagiarizing someone else’s design, this is about using completely unrelated apps to help get you into the head of your client and understand how they are thinking. It’s easier if your following an already predefined UI/UX design and corporate guidelines, but it’s still important to do this, if only to help you decide how essential it is to build a native app so it accesses all the rich handset functionality.
How is the app going to be found when it’s ready to go live?
If it’s a B2E app, this may not be that important, but for B2B and B2C apps getting found in GooglePlay and the AppStore is going to be important to draw users to the app. Don’t think this is an afterthought. Its not. You have to think of this at the design and development stage. Make sure it conforms to design guidelines of each store it’s listing in, if it doesn’t follow the rules its going to be tricky to get it listed. You’ll also need a good app store optimization tool to ensure you’re targeting the right keywords. Carefully think about future releases, as this has a huge influence on discovery. An App that’s continually being developed will rank better in the store. Also make the icon impactful so it communicates the value and purpose of the app is really important. And don’t discount video. Including a short video demonstration of your app will have a huge impact on driving download conversions from your app store listing page.
What about post launch? What’s the ongoing plan to learn & improve?
There needs to be one, right?
No matter how awesome you are as a mobile app development agency you’re just not going to get everything right first time. You’re also probably not going to be able to deliver all the features your client wants, within the budget they have to spend and the timescale you’re presented with. The clients going to be very very focused on the first delivery point, getting the mobile app live. That’s natural. But your job is to coach them to think longer term. Get them to think about the MVP, and getting them to build the backlog creates the mind-set that this is an ongoing project. The first phase is version 1. This means you get them thinking early about the ongoing phases of releases as well as the promotion of the app.
Making sure that there is good data coming from the app is also critical. In addition to crash reporting & diagnostics, using data & analytics to know how the app is performing particularly focusing on recency, frequency, duration and lifespan. Getting your client to predict up front what is the expected “Norm” and tracking variance from that will help your and your client prioritize the remedial work that will be needed to get the app downloaded, used, and reused frequently.
Bonus Question – Question 21
So lastly, and consider this as a bonus question, given we are through the 20 questions promised in the title.
What dependencies are there, that we need to consider before we can get started with your new app?
Its good if you can get the client to clearly tell you what needs to happen before they sign the work order and kick the project off. Do you need to run an ideation workshop (to make sure an app is actually what they need)? Does a purchase order need to be signed off by the budget-holder? Are you both covered by a Confidentiality & Non-Disclosure agreement? In short, what are the barriers to starting this project in the next hour?
20 Questions to Ask your Clients to make your app project a success
Of course, no set of questions will be the same for every project and every client and every mobile app use case. Hopefully this gives you good coverage of the main points. If you would like a handy reference guide, why not download the Guide with 20 questions you need answers to – before you build your client’s mobile app. Asking the questions, documenting the answers and playing these back to the client in the format of “You Told Us This… so we will therefore do that” will make sure you are both on the same page. Better this than stumbling in to bear-pits through the project.
OK, so we’ve given you a bunch of questions to ask your client, but what about when you have questions about your mobile app business? No worries – we’re here to help. That’s why we’ve started a FREE business webinar series that addresses many of the questions that app development agencies have in mind.
The webinars are intended for Business Owners, CEO’s, Sales & Marketing VP’s and Commercially minded CTO’s. They’re 100% business focused, so they’ll give you ideas on how to drive more retainer based income for your Mobile App Development Business.
The Kumulos platform started life as a hosting and API management system to help build and manage the server side of the mobile app. It’s now evolved into the most comprehensive mobile app management platform for mobile app agencies with Push Notifications, App Store Optimization, App Analytics, Crash Reporting & API Endpoint Monitoring, Document sharing & Collaboration and Content Editing all in one place. Why not take a look at who uses Kumulos?
But that’s not all. It comes with a number of unique, turn-key features, custom built to help busy mobile app agencies offer services to their client. Services that help keep the dialogue flowing, so they stay close and win regular follow up client work. And the best bit, services that the agency charges monthly for, so they get more app projects on monthly retainer, once the app goes live.
We don’t care whether you’re building native apps on iOS and Android, or using your preferred hybrid platform, or a low-code / no-code platform, you can use Kumulos to help you deliver greater commercial success. We partner with a range of technology providers so you can have it your way.
A while back we got really interested in what makes one mobile app success and other mobile projects flop. This got us thinking. Sure the idea could be the thing, but we’ve all seen apps ideas that should have been a run away viral success but just didn’t catch on. This led us to think that it had to be more than the idea (and the market fit for the idea), there had to be other things, things that the app developer/app owner can do to increase the chances of success. So we locked a couple of our smartest developer brains away in our “idea-incubator” and they built Karma.
From the hundreds of app projects that have been put through the Karma check and balance tool, its clear there are a lot of app development businesses and app owners that are missing a trick or two. Some simple things, thought about up front, that could make a huge difference to ensuring the ultimate success of the app.
So what does Karma tell us about overall trends and the areas that look most out of balance.
1. Think, Think, Do… could be a better approach
It looks like more time could be spent defining the purpose and the clear business benefit of the app, right at the start of the project. It seems that many projects should spend more time mapping out the strategy, clear objectives and measures of success of the app before the project kicks off. Its tempting to get on and build something, but its often the first steps that define the ultimate outcome being a success or not. So spending just a little more time at the start, working closely with key stake holder on what its critical for the app to do well, could give a much much better outcome at the end.
For example, a clear understanding of the critical functions and purpose of the app will help define the minimum viable product (MVP). Focusing on delivering a MVP App 1.0 not only gets your app in use faster it also ensures that your app offers the most value for the least development effort. It also gives the app a good start point to learn, adapt and evolve what it does. Nothing better than real users to teach you what’s good and what could be done better.
2. Data Driven Development is unusual
Data at the heart of development doesn’t seem to be as important as it should be. We see less time spent at the design phase mapping out analytics metrics and even less time post launch interpreting and building insights from actual users during on-boarding and in app behaviour. This means some are missing a trick here. Baking the measures, metrics and benchmark objectives into development of the app at the design stage and making sure the build phase delivers these is a key measure of success. Also ensuring that effort is focused in post launch follow on activities to drive results against those metrics is equally key. The concept is simple, if you don’t set out the clear tangible objectives and measures of success for the app at outset then how can you be sure your on a successful track.
One example could be cadence of the app – how frequently the app is being accessed and used. Its going to be different for different types of apps, of course. But knowing at outset how often your most engaged app users will be in and using your app is important. Making sure that the app is built with the optimum cadence in mind and then setting success metrics on monthly, daily, hourly use of the app, makes sure you have a closed loop view of how well the app is performing. If you don’t get the user cadence you expect when you go live, you’ll have an early flag that remedial work in the app is needed to get users more highly engaged.
3. Iterate and learn… and improve
Third, and the biggest surprise was time spent post launch. Its almost like “job done” once the app is born. But in reality that’s just when the hard work begins. We see huge variations in the amount of time different app projects dedicate efforts to grow adoption and engagement within the app. It could be that most just don’t see that as their remit. It could be, if you are an app development business building apps for other businesses, that you are leaving a huge amount of money on the table. Recurring monthly income that could provide a highly stable income stream to smooth out lumpy project revenue. When we speak to app owners we hear time and time again that they look to their app development partners for help not just in the build, but in the full life-cycle of the app.
Also if you are an app owner working with an App Development team you need to make sure those working on your app have the right shape and balance to the project, after-all you carry the can if things go wrong.
We are not saying that just get these three areas right and you’re guaranteed to have a roaring success on your hands. What we do see is that paying more attention to these areas will reduce the risk of failure. That’s got to be a good thing, surely.
What is Karma?
Karma is free not-for-profit venture that’s completely confidential and anonymous. Using it could mean better apps, so what’s not to like. Check it out here https://karma.kumulos.com/
All the data in Karma is completely anonymous by design, so those completing it can be confident to input the information openly.
Karma measures the 19 most important elements of a mobile app build. Grouping these under 5 main headings that broadly follow a typical app life-cycle; Design, Build, Test, Release, Optimise, looking at the amount of time each project spend on each phase. It then maps these against the 4 most important areas that drive app success; Strategy, Risk Management, Deliverables, and Billables.
Karma takes these 19 data points and 9 measures, plots the effort in days of each project against all the other project entries, showing how the shape and balance of this particular project compares. For the individual project it shows where focus may be heavy (spending too much time or too many dollars perhaps) or where focus could be too light, skipping over important areas, things that could threatening the success of the project. Of course, no two app projects are exactly the same, but mapping the shape and balance against “the norm” and understanding why there should be variance, provides real insight into where effort and money is being spent.
With Adobe’s tooling such as Edge Reflow and their PhoneGap Build service, designing, building, and deploying hybrid apps has never been easier. However, there’s still something that can be hard to get right: typography.
When building mobile apps using web technologies, font faces and text sizes are set through the CSS styling language. This allows for great flexibility in terms of design, but can make it tricky to ensure a consistent and usable experience across all platforms and devices. There are some great examples, but it does remain a challenge for the following reasons.
There are so many devices that offer different screen resolutions with different pixel densities, making interface elements adapt to fit the screen can be challenging with web technologies. The user’s “viewport” is the visible rectangle of content that is displayed on screen. This may be a crop of a larger content area, or define how to scale up content to fit a screen.
Native app development approaches transparently handle scaling all elements and fonts to suit the user’s screen resolution and density, making sure your app will still be usable. When using CSS as part of a hybrid approach however, we end up with less reliable results. The rendering engine used to deliver your hybrid app relies on font sizing in one of CSS’s units, that don’t get scaled to match the target device density.
CSS has long units that allow relatively scaled sizes for various properties of elements such as font size, but traditionally none of these were relative to the viewport’s dimensions. CSS3 introduces a new unit to combat this problem: the viewport unit.
This unit allows you to specify fonts in terms of 1% increments of either the viewport’s width or height. The implications are that if you specify your fonts in viewport units, they will be scaled proportionally to your user’s screen density thus solving the problem of making sure text is readable across the plethora of available mobile devices.
There’s one caveat with this though, and sadly that’s the lack of support by current mobile operating systems (notably Android has no support). iOS brought support in version 6 but it’s still not perfect at the time of writing.
So in the meantime, what can you do? Well, there are a few options:
Stick to using more traditional percentage-based or em-based units (do read about the tradeoffs)
If you want to know more about mobile typography, or if you just need a Mobile Backend you can rely on, talk to us here at Kumulos. We’ve got a Mobile Backend as a Service that’s been made from the ground up by app developers, for app developers and we guarantee it will make your app development life much, much easier.
Likelyhood is that you have at some point, it’s certainly not an uncommon occurrence. Many question why this happens, and many theories and even books have been written on this subject (from our own experience, it’s because you were too chicken to make a move, just saying). The fact of the matter is that ultimately, friendzoning comes from the other person liking you enough to want to hang out, but finds you too boring to want to sleep with you. You might not actually be boring, but it’s all about how you come across. If you’re just going to sit passively and expect them to do all the work to come to you then to the friendzone you shall go.
The interesting thing is that this is the exact same problem that many app developers face with their customers.
Many developers will make a good app, but only a handful will have any success. Why is that? Is it the zeitgiest not wanting what they’re selling? Is it that the app isn’t to the majority’s taste? Or is it that they didn’t put any effort into showing people why they should buy the app?
Whilst the first two will probably have a certain impact, it’s the third one that is the most likely candidate for your app’s seeming non-starting. If people don’t know about your app, don’t know how good it can be for them, and if you don’t put the effort into essentially charming them into buying what you’re selling, it’s very likely it won’t sell.
There was a study done later last year that said that 91% of app developers think marketing is important. That’s good! But that also over half of developer don’t put any budget into marketing at all. That’s bad.
That second reason is why 80% of app developers don’t make enough money to operate as a standalone business.
If you don’t put any effort into selling your app to your customers, letting them know what they an potentially get from it, they’ll get bored quickly and move on without ever actually buying your app. In other words, they’ll friendzone you. After that, unless you release something drastically different and exciting, customers will keep not only your app, but your development studio in the “meh” category.
So if you want to avoid that, get marketing. We know it takes effort, and if you put all that effort in and your app still doesn’t do that well then it redoubles the failure, because you actually tried to make it work. But the statistics don’t lie, if you don’t make any effort, you’re not going to make an impact all, regardless.
It’s been 10 years now since the original release of the first iPhone and the app store that swiftly followed in its wake. The app development market grew at an unbelieveable rate, with the App Store recording 1 Billion downloads in less than 9 months and then doubling that number in half the time. Other mobile OS quickly adopted a similar concept and now there are an estimated 1.5 million apps in circulation around the mobile world.
Some people are still asking how something as small as the apps that we use on our phones, essentially truncated computer programs that usually only serve one relatively simple purpose, became the driver of a massive global industry.
people want apps
It’s easy to see; any mobile OS that doesn’t have a substantial app library will always have a harder time attracting customers than a well matured app ecosystem on another OS will and retailers who have a mobile offering to their store see up to 26% more business simply because people can shop on their phones. Then there’re the frequent stories of appillionaires who, through the success of one app alone, have made millions of dollars and are now set for life; case and point, Rovio and their Angry Birds franchise. The addictive game about indignant avians and their swine enemies is on nearly every handset worldwide and has made tens of millions of dollars for the company.
So no wonder then that everyone still wants a piece of the action, but many people and companies are put off of app development by what they assume to be high development costs and the fact that it seems like an incredibly complex thing to make an app.
Well, we at Kumulos are here to tell you that neither of these things has to be true at all for a new app development project and over the course of 3 blogs we’re going to look at just why that is.
In this blog we’ll break down roughly the process of getting an app created from the creative production side, then we’ll go into design, and then finish with costing it out.
So first things first, when making your app, you should think about what it is first and foremost you want the app to do. What is its core function? It’s raison d’etre? What problem or problems does it solve or services does it provide and how does it do that?
Once you’ve got that initial groundwork, then you can look at the common types of app out there that suit different types of function and choose the best one for you and your app.
Common App Types
Basic Table – Think an email or simple note taking app. No splashscreen, no bells and whistles, just the information you want your app to display in a simple and easy to understand format. Definitely the easiest to create.
Database driven with UI – This is a much more freeform label and it essentially is best applied to apps that want to display a lot of information, such as a list of people, places etc (think Facebook) in an interesting way that’s different and recognisable but also, again, easy to navigate. This is the kind of project many retailers will want to take on as it provides a distinctive design element to the app; this type of app is also, however, the most prone to silver plating and scope creep so be aware.
Games – Anything from Pong to full 3-d with near console graphics and everything between. This is likely to be the most expensive form of app to make if you’re going for the cutting edge graphics, but it’s also where they highest profit margins are. Risk vs reward, as always
Mods – Apps that change or enhance the function of something the device can already do. For example the Flashlight app, or one of the many camera apps that change the ability of the camera in some way (Instagram etc)
Dynamic – “Always On” apps. These apps rely almost entirely on being connected to outside data sources (i.e. the internet) to work. Usually include weather and news apps and other frequently updated features.
And then there’s a whole mess of everything else in there to boot, but these are definitely the most likely and most seen types of app in the app stores at the moment.
So that should get your thinking caps on and get you starting to plan out where you app idea fits in. In our next article in this series, we’ll talk about the stages of app development.