Top app design practices – 2019

Every year, mobile design evolves – and so far, 2019 has been big on embracing change. From foldable smartphones and rumors of those that even roll-up, to voice truly making an impact on the IoT.

There’s a lot to keep track of and look out for, with such a rapidly changing digital landscape and app marketplace. From 2015 and up until mid-2018, while devices were advancing, there weren’t too many drastic changes to processing speed and power, display clarity, or network speeds.

2019, has, so far, been the break in that static chain – and we’re only just in the second half of the year.

With faster data transfer speeds, sharper images, and a continued growth in our collective understanding of designing good UI (remember when we thought of UI as menus on a page?) for a medium that’s just now seeing people reach the 20 year mark, it’s imperative to keep up with such a trend-setting year for design.

We covered five mobile design ideas recently, but we wanted to go over even more – mobile app design is a large box to un-package.

Bottom Navigation

Think of how you hold your phone. Usually, it’s held in your dominant hand, using your thumb to scroll through and select content – it’s the overall preferred way we interact with our phones.

Since the beginning of mobile app design, there’s been a trend to position navigation bars at the top of the screen (not all apps, but a significant amount), and this makes sense – before the title “UX designer” came about, there were web designers.

What does a difference in title have to do with where a navigation bar ends up on a screen? Web designers were the first to design for mobile, and as such, brought the design hierarchy of the desktop to apps. When using a desktop, it’s natural for our eyes to gravitate toward the upper two thirds of the screen – and this is even more pronounced on a laptop.

Not to mention most desktop computers have their own navigation menu (usually) located on the bottom of the screen – the task bar for Windows, and the dock for MacOS.

So, when web designers began designing mobile apps, they put the navigation bar where they always had – at the top. And for a while, this wasn’t an issue; screen sizes on mobile devices were small enough that users could just adjust their hand to continue using their one dominant thumb to interact with their phone.

Screen size and resolution have grown dramatically in recent years, however – and it’s brought light to a needed change to the status-quo of mobile design – the practical necessity of bottom navigation.

Bottom navigation doesn’t just mean a permanent menu that lives at the bottom of an app’s screen – it also includes bringing most of the interactive UI elements of your app to the bottom.

Here’s an example:

Notice how content is relegated to the top two thirds of the screen, and interactive elements are located in the bottom third. Once something is selected that requires an extra step, the new menu should come up and in from the bottom of the screen from behind the main bottom navigation bar.

This keeps user’s thumb and hand positioned firmly towards the bottom of the screen – making interacting with your app faster, easier, and with a much better UX than with top navigation.

Deep flat

Flat design has reigned supreme for many years now – and all of its benefits are still present in its newest form – deep flat.

Deep flat is simply the idea of utilizing the same flat design elements we all know and love for their visual simplicity and coherence, with added perspective and motion for additional user clarity. It’s much easier to explain visually than through words:


While deep flat can make use of gradients to give the idea of depth, it doesn’t have to:


But, one quality all deep flat design shares is motion. Technically referred to as dynamic functional design, motion is now being used in apps at a much higher rate. But as we’ve stated before, you’ll want to make sure your app doesn’t move around too much – animations should be as satisfying for a user the first time they see it, and the thousandth time.

A general and easy rule to follow if you want to make sure your app’s animations never get annoying is to keep them shorter than half a second.

Deep flat is good practice to get a hold of now, for two reasons: first, apps that are graphic heavy tend to have higher user retention than those that are less so – and second, in a few years, dev shops will expect UI designers to have a solid grasp of deep flat implementation.

Gradient 2.0

Gradients are still used to portray depth on a screen – and until recently, gradients were only lived on screens as shadows – not any longer, however. Device displays have progressed to the point where colored gradients can be described as “vivid” rather than “muddy.”

It’s why all the new devices make sure to have a colored gradient serving as the background of the home screen – they’re showing off how vibrant their rendition of colors can be. Now, color gradients can be used in backgrounds, icons, logos, and all other forms of graphics that make up an app’s UI.

Getting used to implementing color gradients into your UI design now will give you a head start as users begin to ignore less colorful apps in favor of brighter (and therefore more eye-catching) apps.

Gradient 2.0 goes hand in hand with dark mode, which we’ve gone over previously.


Including voice integration with your app isn’t necessary in 2019 – but it soon will be if you want your user retention to remain stable. Voice AI is becoming more advanced with every passing minute, and soon users will come to appreciate and expect the UX benefits it brings.

Adding voice integration into your app’s UI isn’t very difficult – its functionality is easily indicated with a universal microphone symbol. Implementing this feature into your app’s code base is another story unto itself – a heavy and robust backend architecture is required to support the logic necessary for a voice feature to work properly.

On that note, it’s on to our last top design practice (for this blog, at least):

Learn to code

It isn’t easy – and you don’t have to know everything. But the more you know about the OS you’re designing for, the better of a designer you’ll be. Knowing what the OS you’re designing for is capable of is just as important as knowing how to translate an app’s process into a design users can understand.

If you’d like to learn about the structure of an app made for iOS using Swift, check out: iOS development and Swift code – What you need to know.

For Android, check out: Android development – What you need to know.

We hope you’ve found these ideas helpful, and if you’re looking forward to more app design practices, don’t worry – there’s more coming in the future!

Five mobile app design ideas

Imagine you’re driving down the highway. Ahead of you are two cars, both of the same make and model, traveling down the road side by side – they’re even the same paint color. Despite these shared qualities, they’re easily distinguishable from each other. Why?

The car on the right is ten years older than the car on the left.

Just as the style of cars seems to evolve every five to ten years, so too do popular app design styles and features – albeit in a much tighter timeframe – and app trends tend to expire and evolve every 5 to ten months.

Due to these rapidly changing mobile design styles, maintaining your app’s user retention basically comes down to playing a continuous game of catch-up; whether it’s with newly thought of updates of your own, or as a response to users expecting a newly invented feature or style.

And if only that was all there was to worry about.

There’s a continuous stream of new devices flooding the market – Apple’s iPhone has a regular release cycle, and there are more Android devices than anyone can keep track of. With these new devices come higher screen resolutions, faster processing power, and in general, the ability to do more.

When phones have features, users expect to be able to use those features while engaging with your app. People buy devices because of the functionality they offer – and due to the continual evolution of mobile device design trends as well. If your app doesn’t account for the new features, resolutions, and capabilities of new devices, your users will stop engaging with your app.

No matter what, you’re going to need to update the design of your app during its lifecycle – but coming up with ideas once, twice, or even three (or more) times a year can get tiring. That’s why we’ve decided to write this blog – to give you some jumping-off points when coming up with new design ideas while updating your app.

If you’re looking for ideas on how to design an app from the very beginning, the following blogs are more in-line with what you’re looking for:

1 – Night Mode

If your app doesn’t already have a night mode, it’s time to implement one. The main purpose of night mode is to reduce your user’s eye strain during, well, the night. There are many other tangential benefits to night mode as well, however:

  • Improved legibility
  • Reduced eye fatigue
  • Less screen flicker (this is a very limited-in-scope issue, but can be a huge detractor to your app’s user retention)
  • Less blue light
  • Saves on battery usage

Implementing night mode is a relatively straightforward process – it should begin with your designer, who will play with color combinations for the proposed night mode. It’s not exactly as simple as inverting the colors of your app:

Notice that not all the design elements were perfectly inverted – the background of the night mode isn’t pure black, while the background of the normal mode is pure white. The text of the normal mode is a dark blue – the text in night mode is a very light grey; meanwhile, the button to add another textbox barely changed.

After landing on your color choices, your developers can step in. All that’s left to do is to change the color values already written in the code of your app – a very simple and straightforward process.

There is one more design implementation you need to make in order to ensure the best night mode experience for your users, however; users need an on/off toggle switch they can tap to turn night mode on and off. This is easy for both designers and programmers to implement, so this extra UI improving design feature won’t take too much time to develop.

If your app is for iOS, the code is extremely simple to write. The Swift tag “UISwitch” will provide your app’s users with a ready to use on/off toggle switch – then, it’s just down to placing it in the designer’s desired space.

Perhaps one of the best places to place the on/off toggle switch is in the top right corner of your app – this way, when users engage with your app in a darkened location or time of day, they don’t have to squint at a bright screen in order to find your night mode switch.

You can also consider implementing an auto night mode that enables itself after a certain time of day – this way, users don’t have to worry about pressing an on/off toggle switch.

Night mode is a simple design change that shows your users you care about both their experience using your app, as well as their personal health – implementing is easy and fast, while the improvements to your app’s UX are significant. Due to these factors, night mode is definitely worth the time and money required to implement into your app.

Next, we’re on to…

2 – Bigger, responsive buttons

Much in the same way that website elements (like buttons or image links) became more interactive and graphical as technology advanced (allowing for faster transfer and reading of data), so too are app design elements becoming more visually-oriented as mobile devices (and the introduction of 5G) improve data loading times.

A logical implementation of this is through responsive buttons – just as the header image on this page will respond to you hovering over it, so to are apps beginning to implement this type of responsive design. If you’re an iOS user, the most recognizable implementation of this would be how app icons will shake when you’re in your home screen’s edit mode.

Below, you’ll find a few different options for responsive buttons:

  • Swipe-able buttons
  • Enlarge-on-contact buttons
  • Flippable buttons

Also, why do we recommend making your buttons bigger? Simple – screens are bigger now. Not only do bigger buttons help tie your app’s design together on a bigger screen, they’re also easier for users to tap. If you’re deciding between an intricate and beautiful design, or a simple, easy-to-use and understand design, always go with the latter.

An app that provides easy interaction will beat the beautifully designed app every time – users don’t download apps to marvel at their design (well, we do) – they use your app to help solve a pain point. If a button is easier to tap, you’re helping them solve their pain point faster.

3 – Dynamic functional animation

In the same vein as responsive buttons, you can improve the flow of the entirety of your app by adding dynamic functional animation to its design. The most well-known example of dynamic functional animation would probably be scrolling parallax – which is achievable to implement with newer versions of both iOS and Android.

For an example of scrolling parallax, click here.

Other examples include:

  • Highlighting currently interacted with areas
  • Auto-zoom content
  • Dynamic images
  • Dynamic functional animation is first and foremost subtle. Rather than standing out on its own, dynamic functional animation serves to strengthen the design of an app itself through animations that are logically and strategically implemented.

    Humans are hardwired to acknowledge and respond to movement – it’s what makes it so hard to maintain eye contact during a conversation when something’s moving in the background. Due to this quirk of human nature, design enhanced by animation will usually catch someone’s attention more than a static design.

    In short, dynamic functional animation ensures your users give your app more attention.

    Dynamic functional animation ensures your users feel like they’re interacting with an actual, tangible tool, rather than pixels on a device’s screen. Animations needn’t be hardware intensive, nor utilize 3D graphics – simple motions like a shake, or colors of elements fading as they scroll over the screen add that extra little bit of UX that helps to keep users engaged.

    Even adding a little jiggle when switching between tabs significantly enhances the UX of an app:

    Credit: Behance Gallery

    There are some limitations you should impose upon yourself when implementing dynamic functional design in your app:

    Make sure it’s easy to use

    Your app should first and foremost be easy to use – for the same reason explained above in our section about responsive buttons. It’s named functional design for a reason – its implementation has the purpose of enhancing your user’s experience, not detracting (or distracting) from it.

    Dynamic design should always be able to be described as “simple.”

    Make sure it’s purposeful

    Any animation should fit with the functionality it is enhancing. For example, an image tile in a gallery could flip to reveal the photo’s information on the “back” of the photo – this would fit perfectly, as it gives the impression that the images are 3D and have a physical back that information could be written on. A progress bar that flips as it fills up, unlike our photo gallery, doesn’t make sense – and would probably only serve as a distraction.

    Make sure it’s not annoying

    This is perhaps the most important factor to keep in check – dynamic functional animation can get out of hand very fast.

    Tight, quick animations are fine, and add to the UX of your app. A long, drawn out animation only serves to interrupt the flow of your app, and increase the time it takes users to solve their pain point.

    Keep your animations short, and your users will stay happy. It might be fun to design and code highly detailed animations – your users might even appreciate the animation the first few times. But the purpose behind updating the design of your app is to increase your user retention – and if users are continually using your app, drawn out animations will quickly become stale.

    Make animations that are just as satisfying the thousandth time as the first.

    4 – Simplified UI

    While we’re on the topic of keeping things short and sweet, let’s take a look at the benefits of simplifying your app’s UI.

    We touched on this briefly in the first section of this blog already, but its’ importance warrants a more detailed overview. A simple UI will always be better than a complicated one – no matter how much extra functionality a complicated app’s UI provides its users, the simpler competitor with half the functionality will most likely be more popular.

    This is due to the same reason there’s such thing as a universal remote. There’s nothing more annoying than having to use three different remotes to watch a show on your TV. We tend to get frustrated as we’re presented with barriers such as these; in this example, we want to watch TV. Not play with remotes. For every extra remote we need to use, it’s an extra barrier to watching our show.

    The same goes for apps. For every step a user must take to complete a session in your app, another barrier has essentially been added between where the user is in their session, and the solution to your app’s pain point.

    Designing an app is like creating a sculpture made of marble – it’s a subtractive, rather than additive process. During the ideation stage of any app, it’s important to narrow the scope of your app to its core functionalities – from there, you can add extra features. But remember – for each feature added that’s necessary in the process of using your app, you are creating another barrier between your users and the solution to their pain point.

    Don’t make them use three remotes to finish a session in your app.

    Just as it’s wise to narrow down the scope of an app during its initial ideation, so too is it important to do the same when updating your app. An easy way to ensure practical application of simple UI updates is to treat updating your app as if the update is a MVP.

    The easiest method of implementing simple design updates is to create a list with everything you want your update to include, and then try to connect every bullet on that list to the main pain point of your app. If an item on your app’s update wishlist doesn’t help to solve the pain point, or improve the experience of using your app, it most likely isn’t needed.

    There is something we want to clarify – a simple and concise UI doesn’t always mean simple code, nor quick design. Dynamic functional animation will not be simple to program, just as a simple-to-understand design could take hundreds of hours to achieve.

    A simple implementation of dynamic functional animation is measured by how much (or lack of) interruption it provides in the process of using your app – the more interruption or delay in the flow, the less simple (for the user) it would be.

    5 – Color Palettes

    Circling back to the same vein as night mode, switching up your app’s palette can go a long way toward improving your app’s user retention.

    Picking new color schemes is fun, and the actual implementation of such is fairly easy (and we already covered it in the night mode section of this blog) – but we do want to cover the timing and methods behind putting a fresh coat of paint on your app.

    A/B testing

    A/B testing is switching out one piece of content with another, and then recording the results. In this case, rather than switching out actual content, you’d switch, for example, the color of your header text from blue to red, and then watch and record how your users react.

    In order to successfully run an A/B test, you’ll need to record all of your user data prior to the test for the same duration that the test will run. Then, implement the changes to your app through an update. Record the data that follows, and then compare the two sets of data. If you want to be extra through, you can repeat this process multiple times to ensure your samples aren’t skewed.

    From here, you can permanently implement the color palette that is best for your app’s user retention.

    Situational updates

    When it comes to updates, timing is everything. In order to capitalize on upcoming cultural events or holidays your users celebrate or engage in, you can update your app’s color palette for the duration of that time period.

    For example, a shopping app could update its color scheme to match the next upcoming holiday – changes like these can help put people in the holiday shopping mood. Now, keep in mind that this doesn’t mean this shopping app would change its normal color palette of white, blue, and orange to green, red, and white for Christmas. Rather, small hints of Christmas colors could be interspersed throughout the app.

    There’s an infinite number of app design ideas…

    But that’s all we have for now. We hope you’ve found this blog helpful in serving as a jumping-off point for your app’s new design.

    If you’d like to keep reading about app design, check out our blog on how design impacts the cost of your app.

    We’ll blog about more app design ideas in the future, so stay tuned for more!

Custom app development costs

How much does it cost to develop a custom-made app? This is a question we are asked quite frequently – and the answer is so open ended that we felt it warranted its own blog. Regardless of what type of app you’re developing, there’s one factor that rises above the rest when determining the cost of software development – time.

And when it comes to custom app development, time still holds on as the key determining factor of your app’s total cost. There are, however, a few different aspects, features, and feature sets of custom app development that will take up more of your time (and therefore money) than others.

The time it takes to develop these features, however, is balanced by the fact that these features usually add a significant amount of profitability and robustness to your app. And often, the features are necessary to the key functionality and experience of your app.

Let’s get into those features.


There’s a lot the word “design” can refer to when on the topic of app development – especially so when it’s a custom-made app in question.

When developing a custom app, every aspect of its design must be built out. While both Android and iOS have universal design libraries, custom feature sets require custom layout, custom graphics, and custom flow.

You should expect an app to take 100 to 150 hours to properly design – this estimate can change depending on the complexity of your app. Let’s look into what makes up all those hours:

Custom layout

Every custom app’s layout will be unique – while certain features will undoubtably share some implementation styles and guidelines (like the iOS Human Interface Guidelines), a custom-made app will solve its pain point using a uniquely-implemented feature set.

You can think of your app’s design as the interactive guide that leads users through your app’s feature set. It’s the links in the chain of your user flow – just as it’s the process of visual cues that make up your app’s UX.

I’ve used this example before, but I feel it’s a good one; an app is like a choose-your-own-adventure book, and its design is the language that indicates to users what choices are available to them.

When designing your app’s layout, keep a few things in mind:

  • A user’s location, situation, mood, and method of interaction
  • What the overarching purpose of your app is
  • Your main user story

The most important thing you can do when laying out your app is to ask yourself: “How would I want an app to solve this problem?”

Then, when conducting market research, make sure to ask others the same question. Figure out what scenario users will most likely find themselves in when interacting with your app – that is your main user story. Design your app’s layout to this user story.

Custom graphics

In a similar vein as “design,” the word “graphics” can mean a wide variety of things when used in reference to custom app development. An app’s design is compromised of:

  • Your app’s logo
  • Individual icons, e.g. “home,” “map,” etc.
  • “Furniture,” i.e. reoccurring graphical elements like button styles or border styles
  • Fonts and type treatment

Some other categories that fall under graphics, but aren’t as common as those listed above:

  • 3D graphics
  • Augmented Reality (AR)
  • Virtual Reality (VR)
  • Level design (specific to games)

The real craftsmanship of design is knowing how to make an intuitive, interactive visual experience – and doing so takes time. Uniqueness is a strong suit of custom developed apps, and graphics and other visuals are the most effective method for portraying your app’s individual brand.

Don’t be afraid to take the time necessary to develop your custom app’s design. A picture is worth a thousand words – a well made icon is worth one thousand lines of code.

Application Program Interfaces (APIs)

APIs can be thought of as pre-made feature sets – some are customizable (to a point), and others aren’t. Perhaps the most well-known API is Google Maps – it can integrate with custom apps in order to provide that app with GPS, mapping, and navigation functionalities.

Through the Google Maps API, developers can customize elements of the API’s Javascript to control visual elements, such as map colors. Rather than coding for hundreds of hours, developers can use the Google Maps API to provide the same (if not better) functionality, all without users leaving their custom app.

While APIs most definitely save developers time, they do usually come with at least one type of reoccurring cost: either a subscription fee, or a data usage fee – and sometimes, both.

Due to these reoccurring costs, the inclusion of APIs in your custom app can lead to significant costs down the road – and as your app grows, these costs will more often than not scale up as well. Be careful with your selection of APIs too – if a third party API your custom app utilizes is deemed as unsafe, not secure, or predatory by the App Store, your app will be removed from the App Store until the problem is resolved.

Also, keep in mind that if an API provider’s services are down, so to will that portion of your app’s functionality disappear – so, depending on how crucial that API is to your app’s experience, you could lose most of the functionality of your custom app.

It is worth mentioning that despite the inherent risks and costs associated with API backend integration, using APIs will save you an incredible amount of time during your custom app’s development phase; and let’s face it – Google is going to make a better navigation system than most companies.

Don’t be afraid to utilize APIs – but also balance the risks, and do your research before implementation.

Backend development

Building out the backend of an app will take up (depending on the complexity of your app) a significant portion of your app’s total development time and cost.

Backend development, in a very generalized sense, can be thought of as hooking up the features your app’s users interact with to different programs, servers, or even other apps entirely.

Fun fact: if you’re developing a custom app for both Android and iOS, you’re actually developing two different apps – Android runs on JAVA, and iOS runs on Swift.

For example, in order for an in-app messenger to send messages back-and-forth, it needs to be connected to a server that can take in and send out data.

Let’s get more into some of the most time-consuming aspects of backend architecture and integration:

Backend architecture

We’re not going to go too deep here – this subject could easily be its own blog. In fact, keep a lookout for something about that in the future.

Your backend architecture is, in short, how all of the different systems, infrastructure, and programs that make up your app’s backend fit together. You can think of it as a puzzle – a vast, digital puzzle with pieces made from code, servers, and APIs.

Backend servers

Your backend is hosted on a server – this can either be comprised of a single server, many, or hosted through the Cloud. Servers are used to store and transmit the data that your app needs in order to function – this can range from data tables that keep track of sales numbers in an internal business app to features like interpreting and sending out data through real-time updates for a gaming app.

Your server’s hosting comes with two costs – your costs associated with purchasing or “renting” server space, and the maintenance that comes with along with using a server. Your server’s maintenance will undoubtably be the larger of the two costs, and you should expect it to be a reoccurring one – servers require continual, regular upkeep.

Time, and time again

This is the last time we’ll state it (in this blog, at least) – time is the most significant factor when determining a custom app’s development costs.

The processes and features discussed above are some of the most cost-intensive aspects of app creation – but with every app’s development will come unique situations, and therefore unique budgets.

There’s a lot more to developing a custom app than what we covered here. If you’d like a roadmap to app development, check out our blogs on easy app development and the steps to creating an app.

How to: Build a MVP startup

Sometimes, the only thing stopping a great idea from seeing the light of day (and consumer’s eyes) is a little know-how. If you’ve had a great idea for a MVP app for a while now, and want to start your own business based around it – but have no idea where to begin – we have the answers for you!

Below, you’ll find your roadmap detailing how to build a MVP startup app.

A strong MVP

The stronger the idea behind your MVP, the better your chances are at achieving success. While there’s no strict formula for coming up with a good idea, there are qualities most good ideas have: stickiness, simplicity, and legs.

If none of those words made sense in context, don’t worry. Their explanations (as well as the definition of a MVP, in case you don’t know) are coming right up:

First of all, a MVP, in regards to an app, is an app that focuses on providing an experience through a set of features that play a direct role in solving a user’s pain point. A MVP app has enough design elements to provide a good UI/UX for the user, and is a viable product unto itself. It is, however, a minimal version of said product, and offers little functionality other than that which helps to solve the main pain point.

Good ideas tell a story

So, what about those qualities mentioned earlier? Urban legends, ghost stories, and memes are all perfect examples of ideas with all three of those qualities: stickiness, simplicity, and legs. Let’s look at the idea behind everyone’s favorite supernatural-bathroom-mirror-murderer: the Candyman.

The idea of a man filled with bees, crawling out of your mirror and attempting to grab you with a hooked hand is a pretty difficult image to get out of your head. It’s a simple idea – tempt fate by saying his name three times in a bathroom mirror, and he’ll come to get you.

It’s got legs as well – the story of the Candyman is highly replicable. This is because it uses a well known setting – the bathroom – and uses concrete, reliable, and common features as details to ground the story in reality. All a story teller needs is a little imagination to truly paint their audience a picture; and because audiences are so familiar with the territory of the bathroom, they can fill in details themselves, and tweak the story to their own tastes.

That audience will then go out and spread the idea again – it’s memorable, simple, and replicable.

Now, you’re not here to sell ghost stories – but good brands share these same qualities. For example, let’s look at Nike’s “Just Do It.”

It sticks in your head – it’s a powerful statement, with no room for interpretation; if you’ve got an obstacle in your path, your determination is all you need to surpass it. Their slogan is simple as well – it’s three words, all single syllable, all easy to understand.

Finally, it has legs; “it” is an incredibly diverse word, and because of this, “it” works for any product Nike sells – whether they’re selling shoes or hats – and whether their customers are skateboarding or playing soccer, “it” is getting done.

Sticky apps

Now, let’s take that urban legend example, and do the same thing with a well known app… let’s go with Uber.

First, Uber is a sticky name – it’s fun to say, fast, and carries the wonderful connotation of “great” with it. The idea behind the app is sticky as well; all a user has to do is hail a cab with their phone, and soon enough, a car will be there for them. Most of the time, they don’t even have to talk to anyone – the task is simply completed with a few button presses.

To put it simply, it’s a simple idea: press a button, get a cab.

Due to the idea behind Uber being so simple, the app itself (in regards to UX) is simple as well – over the course of interacting with only a few different screens, a user can get a ride from one side of town to the other.

The simple experience Uber offers is the reason it (and other services like it) are handily beating out traditional taxi services – pressing a button is much easier than searching for, and then hailing a traditional cab.

Finally, Uber most definitely has legs. The app serves two different user groups in a highly replicable way – one user group gives rides, while the other takes rides – and both user groups are likely to return as Uber customers, as drivers’ economic pain point is solved by riders, and riders’ transportation pain point is solved by drivers.

Perhaps the reason for Uber’s market-shattering effects was due to its market viability – because it was the first app to shake up the taxi industry, it was able to gain users with zero competition until other companies could eventually catch up.

This feature set would create a system for raccoons to share advice with each other, as well as a community based around the app.

An untapped market is the perfect opportunity for a MVP app; and because of this, Uber is the perfect example of how to build a startup around a MVP.

It’s essential, however, to make it clear that being the first doesn’t ensure that you will remain in first place – someone can (and often will) come along and do what you do, but better. App users are fickle, and are more likely to abandon an app than they are to continue using it.

Because of this, if a new app does come along and implement even just a single feature better than your app, users will migrate to the new one – in order to combat this, you must always continuously update your app. This means everything from security updates, UI changes, and sweeping, innovative changes to your app’s UX.

Product Validation

There are two different audiences that must deem your app as viable: the marketplace, and your intended users. The purpose behind receiving validation from these audiences is to ensure your app has a place to live, and value to bring.

Let’s get into what being a viable product really means:


There are a few factors that come into play here, but the most important (when it comes to a MVP app’s market viability) is competition.

There’s three reasons to go with MVP app development: lack of budget, proof-of-concept, or speed to market. Sometimes, it’s a mixture of these factors, and other times, it’s all three. But while MVP apps do significantly reduce your development costs, and do serve extremely well as a proof-of-concept for potential investors, a MVP app’s real strength, as stated previously, is due to its speed to market.

If there’s an audience of users deeming a product as viable, and no competition for a share of that audience, you can use a MVP model of app development to ensure you beat anyone else to the punch. When you’re the first brand to provide a solution to an audience’s pain point, you’re more likely to build customer loyalty than the third or fourth contender.

If you are the third or fourth contender, however, you’re also in a perfect position to strike – conduct your own competitor analysis of apps that do what you plan to do with yours. Then, come up with better ways to implement the solution to your pain point. When you’re entering an already tapped market, competitor research isn’t just necessary – it’s your ultimate weapon.

Consumer viability

In order to determine who your niche is, you must first determine where your niche is. This is important to keep in mind, as sometimes, a specific audience might invalidate your product – but this doesn’t mean every group will. If your idea is rejected, it doesn’t mean it’s a bad product. You might just be talking to the wrong people.

To better identify your target audience, you need to know your app’s user journey.

The user journey

If Uber had marketed the driver side of their app to professional taxi drivers, and the user side to suburban, middle-age, middle-income mothers, it probably would have flopped. Taxi drivers have no use for the app, as their customer base flags them down visually. Suburban moms usually have their own transportation, and rather than needing rides to places, they are usually giving rides themselves.

Uber made the splash it did because it understood its user’s journey. While there are multiple Uber customer types, their main base is urban, younger, on-the-move, and lacks one crucial thing: private transportation. They have enough money to be able to afford something more expensive than the subway or bus, but don’t have the funds (or lack the space) for their own car.

That’s a very different audience than suburban moms. The timing of the 2008 recession, and Uber’s 2009 launch were extremely beneficial to its success as well – and the gig economy owes a significant debt of gratitude to Uber.

Uber took advantage of a market overflowing with available labor – if you had a car, you could work. You could set your own hours, and work around another part time job. With so many young people in 2009 either un-or-under-employed, Uber was able to grab hold of a significant amount of users for the driver side of their app.

They were able to make all of these smart decisions because they understood the user journey of their app. The best way to determine your user journey is to ask yourself; “What would I want this app to achieve?”

Then, go out and ask people what they think. Let your intuition guide you to the right audience – and then, let your audience guide you to the true pain point.

Understand your success criteria

This might seem pretty obvious, but knowing what makes your app successful is important – knowing your goals will give you the data you need to measure your success.

You define what a successful MVP app looks like – whether it’s number of downloads, user retention, or a workable proof-of-concept for investors.

Keep it simple

If a MVP app were to be compared to a football play, it’d be a Hail Mary. There’s really only one point to all the plays, picks, and blocks that happen in a game of football – to get the ball to the endzone. A Hail Mary, just like a MVP app, achieves that purpose using the simplest method with the least amount of steps possible.

If you’re building a startup around a MVP app, think of it as a Hail Mary – the faster you release your app, the faster it gets to your audience, and the farther it spreads among them.

Easy app development

How hard can developing an app really be? They’re pretty much just mobile versions of websites anyway – going the route of hybrid or web based apps should save both time and money, right?

On the surface, these assumptions would seem correct – but for many reasons (which we’ll get into below), taking short cuts or going with a route other than native development will actually create more headaches, and ultimately make your app’s development more difficult.

What about going easy on the market research? Surely apps don’t need to include a traditional marketing budget – that’s what the App Store is for.

Things sure would be easier if that were true – apps require fully fledged ASO campaigns in order to survive against their competition.

There’s a lot that goes into developing an app – and we’ve never said it was easy (in fact, we’ve said the opposite in the past), but we’ve put together the info you need to know in order to make sure your app’s development is as easy as possible.

Fish out of water

Who’s the better swimmer – a penguin, or a dolphin? The dolphin will win in the water every time. Now, I’m not trying to take a shot at penguins – they’re way better at swimming than I am – but they exist in a space between land and sea. They’re never truly in their element; they’re clumsy at best on land, and when in the water, they’re hampered by adaptations specific to land animals.

In essence, they’re very similar when compared to both a hybrid or progressive web app. There is no argument that your initial costs will be lower when going the route of hybrid development; but over time, a natively developed app will perform better than a hybrid on many fronts.

When measuring for usability, performance, security, and maintenance, a native app will beat out a hybrid every time – just like, and for the same reasons as, the penguin vs. dolphin match up.

Visit our blog for a more detailed explanation as to the benefits of native over hybrid development.

Before you find a developer

It’s time for the first step in building your app: finding a pain point. Every app helps to solve a problem in someone’s life – mobile games stave off boredom, fitness apps help to solve our issues with laziness, and navigation apps provide the answer to “How do I get around this accident?”

No matter what your app does, when you boil it down to its true essence, it helps people solve pain points they are faced with throughout the day – or if you’re making a sleep tracker app, throughout the night.

But ultimately, your app helps people. If you’re making a mobile game, the formula is pretty simple – build an app that’s entertaining enough to make people want to play it to pass the time during their morning commute on the train.

For more complex concepts (ideas, not apps – mobile games are some of the most technically complex apps out there), the process of ideation becomes much more involved. Unless you’re developing an app based on inspiration that came to you from facing a pain point in your own life, the easiest way to come up with a (good) app idea is to conduct some…

Market Research

Now, in order to know what to research, you’ll need at least some form of an idea of what you want your app to do – but market research will help you narrow down that broad idea into a marketable product.

Let’s pretend we’re making an app for raccoons. We don’t know too much about the raccoon life – but we’re going to go out on a limb, and guess that this app is in some way going to revolve around getting their little paws on some trash.

We honestly don’t know what the raccoons want, however, so we need to go to the source – unfortunately for us, most of the focus groups and field research probably won’t be held in the cleanest venues.

Okay – so, it turns out, according from our totally real research, that raccoons do indeed face a pain point when it comes to trash acquisition – it isn’t, however, the pain point us humans would expect. Finding the trash isn’t the problem – our target audience’s noses are fine tuned for that sort of work.

Raccoons need an app that gives them the ability to leave other raccoons instructions on how to open the dumpsters that hold all that delicious garbage. As our market research shows, finding the trash isn’t the problem – accessing it is.

So now it’s time to figure out the solution to the trash acquisition problem.

Designing your app

There’s two separate times you’ll design your app – the first instance being the step we’re currently on: user stories.

A user story is the step-by-step process a user will take when interacting with an app. In our case, it would be a raccoon currently stumped by a particularly stubborn dumpster lid.

There are a few things you need to think about when coming up with user stories:

  • Location
  • Situation
  • Mood
  • Method of interaction

The location and situation your users will be in when interacting with your app matters – as well as the mood you can expect them to be in. In our case, the location, at least most of the time, will be back alleys, and mostly at night. We can expect our users to be hungry, and therefore impatient.

Now, with a clear picture of the situation, location, and mood our users will be in, we can start designing the flow of our app.

First of all, we need to revisit the pain point; raccoons want the ability to share advice with each other on how to open up dumpsters, in order to get to trash faster.

So, now we need to design a feature set that will help to solve that pain point. Our app must include:

  • GPS and mapping, as well as location services, in order for users to place beacons on a map for other users to select
  • Camera and microphone access so users can take photo and video instructions
  • Back end integration so the app itself can host photo and video media
  • User profiles that can be rated based on the advice they provide

So, add all that up, and you get an app that allows users to pin video and photo instructions to specific dumpsters based on their GPS coordinates. Other users would then be able to vote on the provided advice, which would then be posted to that user’s profile.

This feature set would create a system for raccoons to share advice with each other, as well as a community based around the app.

Time to build

Next, you’ll want to take your research and user story, and bring it to an app developer. From here, they’ll be able to take your idea and run with it. From here, development is pretty much out of your hands – you’re there to give the thumbs up or down.

A full, in-house development shop will usually start by designing the layout of an app with wireframes, and then flesh out the design. Once the design for each screen has been finalized, a prototype will be built – this is for you to look over, so you can make sure their interpretation of your vision is accurate, and to the spirit of what you imagined.

The developers coding your app will reference the prototype as well – and from it, they will build the actual code of your app. After your app is coded, it will move on to testing, and from there, it’s on to…


Remember when we brought up ASO? This is where you’ll want to implement those efforts. There’s a lot that goes into an ASO campaign, and if you’d like to take a deep dive on the topic, here’s a blog all about it.

ASO, at its core, is keyword research and implementation. It’s just like SEO, but for the App Store and Google Play. We recommend new apps start with five keywords to focus on – and from there start evolving your ASO campaign with strategies ranging from A/B testing to push notifications.

The key to a long-lasting, successful app is frequent updates. Once you’ve launched your app, you’ll want to get right back to developing it – top performing apps update regularly to stay on top of design trends, security issues, and new devices.

This is a big reason native apps are more cost effective and easier to develop than hybrid – maintaining and updating a native app is a much simpler process.

The tortoise and the hare

If you’re developing an app the right way, there’s no such thing as easy development. You can, however, save a lot of headaches and backtracking by carefully planning and building your app. Do as much research as you can, and continuously test your app as you build it. Remember – slow and steady wins the race.

How to: Get a low cost app developed

What’s the key to low cost mobile app development? Preparedness. But how are you supposed to know how to prepare if you’ve never built an app before?

Well, as soon as it began, your search is over – below, you’ll find a step-by-step guide to the quickest and most affordable model of mobile app development: MVP.

Really quick – before we get into it, let’s go over what a Minimum Viable Product is (when it comes to apps, at least). A MVP is an app that focuses on solving its main pain point, and very little else. All features, design, and graphics focus on helping to provide a solution to the main pain point – hence the term “minimum.”

MVPs do one thing, and they do it well.

Now, here’s how you make one:

Step 1: Research

This is all about how to build an app for the lowest cost possible; and the key to all development costs boils down to one singular ingredient – time.

Your app’s design is crafted through a combination of creative thinking, mouse clicks, and keystrokes; your app’s code is built by process-oriented imagination, and a whole lot of keys being pressed in rapid succession on a keyboard. There’s nothing magical about the development of an app.

Now, this isn’t written with the intention of giving the impression that developing an app is easy – quite the opposite, in fact. Building an app is kind of like writing an interactive choose-your-own-adventure novel, but it’s written in a language computers can understand, while also remaining readable for us humans.

And in order to pull that off in a streamlined, cost-effective manner, you need to complete all of your research before going to a developer with your app.

Find out why we recommend against using services like Appy Pie or app design templates to build your app.

The first step to research is…

Determining your pain point

All apps are beholden to one goal: solving their pain point. For a MVP to be a MVP, however, it must only provide the solution to its pain point. Any feature included in a MVP app must play a role in helping to solve this problem – this is to ensure no time is wasted spent developing out features that aren’t truly needed for users to receive enjoyment and benefit from your app.

The reason this is your first step taken on the road of app development is because everything that you do during the development process will be determined by the pain point of your app – from the market research you conduct to the features your developers implement.

A good pain point is both marketable and actionable – meaning there’s an audience or group of people who want a solution to this particular problem, and are willing to do something about said problem.

Let’s say you’re making an app like BrewTrader – just for some context, it’s an app that gives craft beer enthusiasts a platform to find and trade beers with other users.

Take a second to analyze that sentence. You know you’ve come up with a good pain point when you can explain the whole idea of your app in one sentence. Think of it like a thesis statement; if you can’t construct a grammatically correct sentence that covers the entirety of your app’s functionality, your MVP isn’t focused enough. It should be succinct, but meaty.

After knowing the problem you want to solve, and how you want to help solve it, you can move on to the next step of research:

Competitive analysis

This step serves two purposes – it gives you an idea of what your competitors are currently doing (obviously) – but more importantly, it will serve as a roadmap for ideating your app’s feature set.

If you want your app’s development to be quick, (and therefore low cost), you’ll need to know every feature your app will utilize; this includes knowing details like where in the user flow a feature will exist, how it will interact with the user, and if you’ll need supplemental features or APIs in order to properly implement the original feature.

Download the top three competitors and use their apps for at least one session from start to finish. Get an understanding of what they do correctly, and make a note for later. Then, go find the lowest rated app (be careful about security risks) in the same category, and pay attention to what they did wrong.

Knowing what’s incorrect is just as important as knowing proper UI/UX design. It helps to prevent you from making a decision that might seem like the makings of a previously-unimagined and creative UI/UX solution – but there is more than likely a reason the top performers use the UI/UX flow they already have.

Also, begin your ASO research now – pay attention to keywords the top competitors are using. When starting out with a new app on the App Store or Google Play, pick five keywords, and focus in on those.

Market research and marketing

There’s a million different options for conducting your market research, but some key data to be aware of are:

  • Target age range (different age groups respond to different mobile marketing strategies)
  • Target preferred platform (we recommend iOS if you’re starting with a MVP)
  • Target interests

As soon as you know what your app will be called, you have a logo, and you have a description of what your app will do, build a website. Even if you only have content for one landing page, make it, and make it live.

SEO takes a while to take hold, and having something to link back to within your social campaigns will help to build a solid SEO foundation. Apps on the App Store and Google Play require both SEO and ASO to thrive – so don’t neglect either.

Speaking of social media, you’ll want to make sure you’re putting out as much content as possible. Speak to the voice of your app’s brand, of course, but don’t be afraid to open up a little. Everyone understands that when they’re interacting with a brand’s social media account, they’re talking to an actual human being.

Be open and honest and genuine – know your target audience’s interests, and speak to them. To steal advice from Gary V, if they like the Red Sox, talk about the most recent Sox game. Engage with your followers more than you advertise to them. Then, every once in a while, sprinkle in some native content that speaks about your app’s brand, or the features it will provide, or where you are in development.

People love documentation. You can easily create content for social media by documenting the journey you’re on through the development of your MVP app – take one long-form piece of content, and build a few pieces from it each day. Then cater those pieces to each social platform your brand is on. All of a sudden, you’ll be running a fully-fledged social campaign based on a single piece of content (that you didn’t even have to take time out of your day to make).

MVP development

Whether you’re developing an MVP app or a fully-kitted-out enterprise level app, the actual process of coding remains largely the same – the only difference is the time table, which is shorter with a MVP, due to the limited feature set that needs to be built and implemented.

The importance placed on knowing your feature set in and out comes into play here – the most effective and efficient way to ensure easy, low cost app development is to make sure there’s no unanswered questions between your vision, what you want, and how you want it to work.

The clearer of a picture you can give, the more information, and the more concrete of a user flow you can produce for a developer, the better. It’s always important to take your developer’s advice, but relying on your own research and business acumen can help speed up the process.

One thing to keep in mind with (and this is specific to) MVP development is that everything doesn’t necessarily have to be perfect. Don’t confuse this with the idea that it’s okay to make a sloppy app – but understand that as long as your users know that your app is in a semi-beta stage, they’ll be more forgiving.

This is why a strong, personal, and open social media presence is so crucial to a MVP app’s success; in order to properly distribute the message that your app is starting with humbler-than-most beginnings (but improvements will be coming), you need to be able to have frank, honest, transparent conversations with your followers. And, they need to be willing to listen.

The purpose of a MVP app is fast, efficient development – the efficiency truly begins to shine after a MVP app’s initial development.

The second word in the acronym MVP is viable. It might be the most barebones version of a product, but it’s still viable. What this means for you is that you can charge for it. Whether your app goes with a pay-to-play model, or subscription to a service, or with sales from ad revenue, you can begin to make a profit from your MVP as soon as it takes hold on the App Store or Google Play.

Post MVP development

As soon as your app is launched on the App Store or Google Play, make sure:

  1. Your ASO is in place and ready to go
  2. Your website reflects the launch of your app
  3. Your social media has (and will continue to) promote your app’s launch

Take the revenue you’re making from your live MVP app, and start implementing updates. Make sure updates focus on fixing bugs, fixing security risks, and providing quality of life improvements to the UI and UX flow.

Be vocal and transparent about what your updates will accomplish and feature – use both social media and push notifications to advertise these updates.

Be aware that when you’re advertising, you need to be extremely aware of just who you’re engaging with. Older generations, like generation X, prefer value-based advertising. As your target market gets younger, they will expect more personalized advertising – in order to properly do this, it’s necessary to use an app analytics platform. Our favorite is Kumulos.

Be prepared, but be ready to adapt

Knowing what you’re getting into is the most important step you can take to ensuring low cost development – but, always be ready for something unexpected to pop up.

To learn more about the in’s-and-out’s of MVP app development, check out our blogs on:

And, for more about planning out an ASO campaign, check out our ASO: 101 blog post.

With carefully planned feature sets, a concrete layout and vision, and some well-planned and executed social media, SEO, and ASO, you can both shorten your app’s development schedule, and lessen your need for monetary investment; giving you the ability to make an app now, and capitalize on an untapped market – rather than waiting for outside investment and finding a highly competitive and saturated playing field.

Improving your employee training process with an internal business app

An enterprise level, internal business app is the perfect solution for innovating your company’s employee training. More accessible and less resource intensive than traditional employee training programs, internal business apps are, most importantly, much more cost and time efficient than their traditional predecessors.

Internal business apps provide a platform that empowers the growth of your employees – as individuals, professionals, and team members – all scalable, and all within an affordable budget.

Before we get into the how of this topic, I want to cover the why:

The psychology of self-fulfillment apps

Just what is a self-fulfillment app? It’s any app that helps an individual better themselves – while they exist in different spaces, fitness trackers and internal business apps would both fall into this classification.

In fact, when implemented correctly, the structure and UX of the training portion of an internal business app should closely resemble that of a fitness app.

They’re very similar to each other, especially when the internal business app is used to provide or enhance your employees’ training – and just like a fitness app, your internal business app’s training program should focus on rewarding your employees for reaching action or comprehension milestones while on their path of growth.

Why is this? Just as fitness apps use this milestone method to increase user engagement and retention, so too can your internal business app. While employee training might be a virtually mandatory step in the hiring process, this doesn’t mean employees are highly – or sometimes, even moderately – engaged with the process.

With many new positions, employees going through training can find themselves inundated with excess amounts of new information – this can lead to overload, or even to your new employees tuning out for the rest of their training.

By implementing a rewarding, individually-trackable training experience for new employees, you can rid your company of these systemic issues. The best part is, this process doesn’t have to come to a close – internal business apps can empower your employees’ growth throughout their entire career at your company.

Let’s get into some concrete examples:


Imagine being able to start new employee orientation as soon as they’ve signed their offer letter. Along with the email you’ve sent, you can also include a link to your enterprise app. From here, the new employee can complete paperwork that usually takes up a significant portion of their first day.

During this first touch your new employee has with your business’ internal culture and processes, you can adjust the amount of guidance to whatever fits your needs – from live chat features to video calls. Or, you can go the fully automated route, if this portion of your on-boarding needs to be streamlined.

As your new employees progress through orientation, your app can act as their own guide, keeping them appraised of what’s coming next in the training process. This helps them prepare before hand, lessening the time spent introducing the topic that is about to be taught, or from scrambling for necessary resources at the last minute.

Your internal app can also act as a reference point during any step in the new employee training process, allowing new employees to find answers without interrupting training sessions.

When new employees have the power to look back and see the entirety of what they’ve learned (as well as the ability to reference the details of your business’ processes), they’re less likely to feel overwhelmed, and more likely to feel in control – and therefore, are more likely to fully engage with their training.

New employee on-the-job training

While nothing beats human interaction when being taught a new subject or process, an internal app can enhance the efficiency of your new employees’ on-the-job training. Very rarely does a co-worker or manager have carte blanche access to their schedule for a day; so when that new employee is inevitably faced with a situation where they don’t know how to proceed, and the employee training them isn’t around, they can reference the provided guides to handle the problem themselves.

This improves efficiency twofold; your veteran employees can spend more time doing what they do best – producing product, and bringing in new customers – and your new employees can solidify their knowledge retention by having the ability to answer their own questions.

This is very similar to an already tried-and-true method of information dissemination tech companies have used for over a decade – Stack Overflow. Tech companies are extremely process oriented – both when it comes to budgeting for labor, and the structure of code. In order to improve efficiency, developers will upload coding solutions to Stack Overflow for other developers on their team to utilize and learn from. This helps ensure stronger code, as well as increases efficiency for new employees and their team alike.

When new employees have the power to find the solution to a problem they face on their own, they’re much more likely to ask the question in the first place, rather than ignore the issue until it becomes an endemic problem.

Even better, you can cater these reference materials to different learning styles and situations – everything from pre-recorded video to simple presentations, or even tech documents and spreadsheets – these are all viable forms of information dissemination through an internal business app.

New employee on-site, real-time training

While it might not be realistic for every businesses’ budget to implement AR headsets for every on-site worker (like BMW and their mechanics), it is within the realm of possibility for a company to implement a few for new employee training purposes.

In a blog we wrote earlier this year about MxR and its implications for labor-based jobs, we touched on the experience Cnet’s Ian Sherr and Scott Stein had with Microsoft’s HoloLens2, which they reported to feel like “practical magic.”

Why did it feel like magic, and what does an AR headset have to do with new employee training?

MxR headsets now have the ability to interact – in real time – with the environment around the wearer. Both Sherr and Stein – neither of whom claim to be auto mechanics – were able to complete a set of repairs on an ATV engine with live guidance from a HoloLens2.

What this means for your business is a more efficient use of labor hours when bringing a new employee into the field. Your veteran employees can, again, spend their time doing their jobs while the new employee is guided by a real-time, accurate system that provides step-by-step, visual directions.

Continuous learning and growth

Perhaps the most exciting aspect of an internal business app’s training capacity is its ability to be included with the other processes your enterprise level app provides – like inventory management or culture and communication.

When something new is added to your business processes that everyone needs to know, you can send out a push notification with a link that brings all of your employees to the new information – or, you can segment targeted information to the team that needs to be in the know, in order to maximize the efficiency of your other employees.

Employees, at any moment necessary, can reference all of your training materials at any point in their careers – which keeps bad habits from forming, and helps re-align inefficiency.

As your employees foster a culture of continuous learning, new employees will be more readily brought up to speed, as information given to them is guaranteed to be uniform, and standards are always expressly laid out, in plain view for everyone in your company to view at any time.


Most impressive is an internal business app’s scalability and reach – when all of your employees have access to everything they’d ever need (no matter where they are or what they’re doing), you can ensure every employee receives the same standard of training.

This is especially beneficial for offices that work remotely from each other, as it can save countless hours of deciphering one another’s work. Process uniformity can have a positive impact in localized offices as well – but when working remotely, this issue is more profound – and therefore, the solution is more noticeable.

An internal business app’s training capabilities are also scalable on a sense of time – it’s incredibly easy to enhance your training methods, as well as the information provided to new and old employees alike.

A personalized, yet uniform employee training experience

That’s what your new employees get when your business uses an internal business app to enhance or provide new employee training. Not only does this benefit employees at the beginning of their tenure at your company, it helps to ensure a uniform continued growth path for new and old employees alike – whether or not their orientation was through your enterprise level app or via a more traditional route.

Internal business apps give your company the ability to cater to different learning styles, without holding separate training sessions – new employees can watch a video explaining your data management system all while reading along with the provided tech doc, or reference slides instead – whatever works best for them.

With an internal business app’s gamification of the usually (let’s face it) less-than-exciting process of learning a company’s operations – as well as the ability to track and reference past accomplishments and knowledge, and easy scalability for any business model – improving your business’ new employee training with an internal business app is achievable for any company’s budget.

How to: Find a top app designer

Finding the right app designer is a process that should never be taken lightly – there are so many app development companies out there, and each has their own approach to app design. So how are you supposed to know what to look for? How do you cut through all the chaff? How do you find your top app designer?

The only fool-proof method for discerning what makes good design is to know it yourself – so, before we go over how to find a top app designer, let’s look into what makes a well-designed app.

For a general guide to finding a mobile app developer, visit our blog on the topic: How to find the perfect mobile app developer.

Knowing is half the battle

There’s a quote I’d like to put here before we get any further:

“Form follows function – that has been misunderstood. Form and function should be one, joined in a spiritual union.”

It’s a quote from probably the most famous architect in modern history, Frank Lloyd Wright – and a re-framing of his mentor’s original words: “Form follows function.” What Wright wanted to impart to other designers was that (at least in contemporary terminology) good user experience and good design are one in the same, and go inescapably go hand-in-hand.

Users are named as such because they use apps to accomplish something; just as important as the why of an app, is the how it goes about accomplishing said task. That “how” is where good design lives.

In order to know how you want your app to look, feel, and act, you first need to know why it will do the things it does.

Discovering your pain point

Every app helps play a part in the solution to a pain point. Whether it’s a consumer-facing productivity app, a mobile game, or an enterprise level app, they’re all meant to help solve a problem their audience faces throughout their day, week, or lives.

There’s three main ways you can go about discovering your app’s pain point – through identifying a pain point in your own life, from conducting market research into a particular market or audience, or from identifying key areas of your business operations to improve upon.

No matter the origin of your pain point, the most crucial aspect to determining your app’s success is to make sure your app will help solve a problem that’s worth solving. When it comes to app pain point ideation, I like to think of another quote – this one from my poetry professor in college: “Write about grief. Not a grievance.”

Now, we’re not writing poetry here, but it cuts to the core of the idea – a pain point is, by definition, painful. For an app to fall into the realm of truly valuable, the pain point it solves must be worthy of its namesake.

What makes a good pain point?

Not all problems are made equal. Some pain points just aren’t all that painful, and some don’t fit well in a digital medium. Let’s go over the four determining factors for judging the quality of your app’s pain point:


While these factors aren’t listed in any particular order, this facet may be the most important. All apps on both The App Store and Google Play are ranked by a few different metrics – of which user retention plays a significant role in determining their ranking.

User retention is the frequency at which users engage with your app – and different types of apps can expect different engagement rates. A customer-facing app that updates users on their electrical usage might be checked once a week, or once every month. A fitness app can be expected to be opened at least a few times a week, and apps like mobile games can sometimes expect engagement rates of multiple sessions per day.

Mobile games high engagement rate is due to providing a solution to the number one pain point of all time: boredom. Because of this, mobile games do often see high retention numbers in the short term – they do, however, struggle to maintain that retention over time. As users become more familiar with a game, the pull of a new experience diminishes – and eventually, leads to the pain point the game was originally intending to solve.

When determining the feasibility of an app, always keep the expected user engagement frequency in mind – it will help you plan your push notification campaigns.

This can be especially important for apps that are centered around once-a-year timings, like a Black Friday bargain app. This app would want to start its push notification campaign the day after Halloween, and ramp up until Thanksgiving evening. In order to be successful, a Black Friday app would need to maximize its user engagement throughout all of November.


There’s a rule I named myself – I call it the “subway-cornfield” rule. Basically, it means your app should behave the same no matter where a user is engaging with it – whether they’re standing in a subway, or the middle of a cornfield.

When designing your app, however, it’s main use case should be carefully considered – while it should work well in all situations, it should excel in a select few. For instance, compare the UI of Google Maps to that of Facebook:

Google Maps vs FB

While there’s only a few buttons and fields to interact with through Google Maps, Facebook’s UI has a substantial number of options from which to select. Why is this?

I don’t know about you, but when I’m interacting with Google Maps, I’m usually already in my car, moving, and need to keep my eyes on the road. A user on the move is Google Maps’ main use case – so in order to provide the best experience, the UI was designed to be as simple as possible. With a simple UI, the solution to the pain point of being lost is solved faster – which keeps users’ eyes on the road, and not on there phones.

This provides the user (and those around them) with a better (and safer) user experience.

*NS804 in no way condones using your phone while driving*

Also note how information is presented in Google Maps – important roads are highlighted with a strict hierarchy: blue for the route the user is taking, orange for highways and interstates, yellow for main thoroughfares, and white for side streets.

From a zoomed-out perspective, only major landmarks, parks, neighborhoods, roads, and businesses are named – as you zoom-in, names auto-populate as visual space becomes available.

All of these design choices are both intentional, and important to Google Maps’ UX. When less information is presented to a user on a single screen, they’re able to more quickly take in the information they actually need.

Facebook’s mobile app takes the direct opposite approach – users are given lots of options and information (both visual and written) to consume. Facebook’s main mobile use case is someone who is both bored, and has the time to engage with the app. Due to this, Facebook is designed to keep users scrolling for much longer periods of time than a user would spend with Google Maps.


There’s a cold hard truth every app has to face: you have to make money somehow. There’s another quote I’d like to share, this one from Mark Fischbach: “If the app is free, you’re the product.”

This doesn’t necessarily mean every free app is collecting and selling your personal data (here’s to you, Facebook), but free apps more often than not do have some form of monetization that revolves around an entity purchasing user’s time or views. Advertisers purchase space on a free app in order to capture the attention of users – just as platforms will offer free versions of an app in order to entice users to purchase the premium version.

Here’s a list of a few app monetization models:

  • Paid download
  • Subscription fee
  • Ads
  • Take a percentage of sales

No matter what, your app must provide a good enough solution to its pain point for people to be willing to spend money on it. Keep in mind what monetization model your app will implement – it will help you streamline your design and development schedule.


Remember the mobile gaming example? App longevity is a key factor in determining if a pain point is worth it.

If an app solves a once-in-a-lifetime, or even a once-every-five-years pain point, it probably doesn’t need to be an app. There is one exception, however – a use case that isn’t reoccurring for the individual, but is widely spread throughout the population as a whole. Or, put simply – something that you might only deal with every few years, but at least a few people deal with every day.

Here’s an example; you don’t paint your house every day. You don’t, however, see a lack of painting companies – both suppliers and actual painters. Just because a single family only repaints there house every five years, or even once a decade, there’s always a few houses with a fresh coat of paint.

An AR app that allows users to play with the color of their walls when selecting what color paint they want to purchase may only be used once by that individual; but as a wide-spread pain point with a straightforward and easy solution, it will continue to be used by other users in other houses the next day.

There’s a lot more to proper app design – we just wanted to give you an introduction to the thought process behind good UI/UX, and what ultimately lays the groundwork for a well-designed app. We’ll be getting deeper into the subject in the future.

For now, let’s get to the actual finding part. First thing’s first…

Don’t use Google to find designers

There are already companies dedicated to finding designers for you. Two sources you can trust are Clutch and The Manifest. There are a lot of sites out there that showcase app design companies – but these two you can trust, as they use information from a designer’s client history, client reviews, as well as ability to deliver in order to determine rankings, rather than a payment hierarchy method.

Using Clutch

Clutch gives you the ability to find app design companies, set what parameters you want to use to find them (by platform, vertical, or location), and provides you with a breakdown of that designer – from client reviews to service lines, and from industry focus to what types of business they’ve worked with in the past.

Clutch also hosts a blog where you can find information covering everything from B2B marketing to ASO and beyond.

A nice feature Clutch offers are badges, which developers can display on their site to show that they’re trustworthy. If you see a developer with a Clutch badge, they mean business, and you can rest assured they know what they’re doing.

Using The Manifest

The Manifest operates in largely the same manner as Clutch. The Manifest offers industry leader shortlists, and a blog hosting great thought pieces and business advice.

Like Clutch, The Manifest will offer a short bio and client history for each development firm, so you can get a feel for what each developer brings to the table.

And with that…

You’re all set! Happy hunting!

Just remember that you’re always going to have questions – and that’s okay. A good designer will either have an answer for you, or do what they can to find one. Most importantly, your personal preference and business needs should always be taken into account, and if a website is telling you x is the better choice, but you have a good feeling about y, go with your gut.

How to build a MVP iOS app

Building an app is never a simple process – but there are steps you can take to make your app’s development as smooth as possible. In a follow up to our Which is the better platform for a MVP? blog, we’re going to go step-by-step through the development of a MVP iOS app – from ideation, through development and testing, and onto publishing, launch, and post-launch development.

If you’d like a refresher on MVP development, check out our blog post on Clutch.

But first…

We need to reiterate why we’re specifically going over iOS MVP app development, and not Android. While there’s a lot of reasons as to why iOS is the ideal platform for a MVP, there’s one aspect that we will be covering in detail throughout this blog – user engagement:

  • iOS users engage apps for nearly twice as long as their Android counterparts
  • iOS apps have a higher retention rate than Android apps
  • iOS users download more purchasable apps than Android users and spend more money on in-app purchases:

  • Gaming app average revenue per user: $1.99 (iOS) versus $1.56 (Android)
  • Shopping app average revenue per user: $19.64 (iOS) versus $11.49 (Android)
  • Travel app average revenue per user: $32.29 (iOS) versus $20.47 (Android)

It’s stats like these that make up a market better suited for a MVP – not to mention the faster development and testing time for iOS apps, which compliments (as well as keeps up with) the already quick development cycle that makes a MVP a MVP.

The steps to (quick) iOS development

It’s important to note that there is no shortcut to development – if you want to make a good app, at least. The trick to achieving the speed of development that an MVP is known for is to build an app that works with as little features as possible.

To a service-minded company or appreneur, this can sound counter-productive, or even go against mission statements that boil down to “providing the best service possible.”

But a MVPs end goal isn’t to remain as a minimum viable product – once a MVP has had a successful launch on the App Store, the development cycle continues in the form of updating the code base of your app to include more features.

The efficiency of a MVP comes from those aforementioned iOS user metrics; user engagement, in the form of constructive criticism and requests, will serve as your market research and your app’s beta test. This is one of the deciding factors in the lower cost of developing a MVP app – that, and the shorter amount of time actually spent in development and testing.

Let’s look a little deeper into things.

Step 1: MVP ideation

All apps should stick to features sets that help solve their pain point – but a MVP, by definition, must so. A simple way to make sure your app is only utilizing features that play a role in solving your pain point is to write a list of everything you want your app to do.

Then, take your idea and start trimming the fat – let’s take a look at an example:

Let’s pretend that it’s a few years back, and we’re currently in the process of ideation for Brew Trader. Brew Trader is an app that connects craft beer enthusiasts by providing them with a platform that serves as a medium through which to trade craft brews with others in their area.

So, we write out a list of everything we want it to do:

  • A map that shows the locations of bottles up for trade, and is updated continuously so users can see the latest offers, as well as the ability to move the locations of trade beacons
  • A user profile that contains information the user wishes to share, as well as the user’s entire collection of craft brews
  • A messenger so users can DM each other
  • A trade history so users can find other users based on past interactions
  • A bar-code scanner to populate information about bottles available for trade

Then, we edit that list down to what Brew Trader needs in order to function properly:

    A map that shows the locations of bottles up for trade, and is updated every 10 minutes so users can see up-to-date offers

  • A user profile that shows their bottles available for trade
  • A messenger so users can DM each other (while a significant feature set, this is necessary, so users are able to communicate meet-up times and locations)

All in all, that boils down to three different screens, which are built out in the next step.

Step 2: MVP UI/UX

Let’s take those three feature sets and break them down into the visual elements that will make up Brew Trader’s UI. First of all, just like 99% of iOS apps, we’re going to need a bottom menu navigation bar.

This is utilized in UI design so a user can quickly switch between the screens that contain the feature sets listed above. This bar will contain three icons, which will each signify one of the three screens – those being the map screen, the user profile screen, and the messenger.

The next thing to do is layout your different screens.

The map will be hooked up to a mapping API, such as Google Maps. Google Maps is free, as long as your app is free. If you’re looking for other options, check out our blog about how much it costs to implement a GPS & mapping API.

The next element of the map screen to design would be the trade beacons, as well as the sub view that would pop up when selecting a beacon – this sub view would present the name of the bottle up for trade, as well as the user whom it belongs to.

The next screen to design is the user profile section. For a MVP, this should be done in the simplest way possible – a section to add a thumbnail profile photo, and fields to add and view bottles that are up for trade.

The final screen, the messenger, can utilize a messaging API – many of these can be tweaked to match your app’s branding and color schemes.

That’s all you need to design if your making a MVP. Next in line is…

Step 3: Coding a MVP

iOS apps are built using Swift, which uses the following components to create an app’s architecture:

View Controller – Think of this as the frame of a painting. The view controller, which is aptly named, controls what you see on the screen of your mobile device.

View – Within the view controller is the view. Think of this as the canvas of a painting – the view makes up the sum of all visual aspects of the app. Each screen of an app is a different view.

Subview – Subviews are the individual sections that collectively make up the view. Think of a subview as specific sections of a painting, such as how the subject matter is distinguishable from the background. More specifically, a subview would be the keyboard section of iMessage, or the section where text messages display.

Buttons – Buttons are… well, buttons. Within subviews, buttons are the interactive elements of apps. Think of the individual letters of the keyboard section of iMessage.

Images – Also within subviews, images are used to display specific pieces of visual information, and range from photos to logos and icons. An image can function as a button.

When it comes to coding, there really isn’t any difference between programing a MVP, versus programming a fully-fledged app. The shorter development time of a MVP comes from the smaller number of features to implement, which means less UI to build out, and less backend logic to program.

If you’re looking for tips on how to avoid costly mistakes, check out our blog on app development pitfalls.

Step 4: MVP testing

While one of the upsides of a MVP is your early adopters serving as your beta test, you still do need to test your app before you send it off to the App Store. This is especially true for iOS apps, as they face a rigorous review process before they are officially published on the App Store.

Not only will your app be rejected if it isn’t robust enough for Apple’s standards, a buggy app will only serve to weigh your growth efforts down. Users are more likely to abandon an app than stick with it.

Because of this, you must iron out the kinks of your app before it launches. For tips on conducting app testing, check out our blog on the topic.

Step 5: Publishing

After your app has been thoroughly tested, it’s time to send it off to Apple for review and approval.

In order to publish your app to the App Store, you must pay a annual fee of $99. If your app costs money to download, or goes by a subscription model, Apple will take 30% of each sale.

That’s really all there is to publishing your MVP app – the publishing process doesn’t differ depending on what type of app you’re making. All apps on the App Store go through the same review process.

Step 6: Launch

Launching a MVP is largely the same as launching an other app, but there is one very important factor to note.

Users will make snap decision based on the first impression of your app. Users do, however, make exceptions for small hiccups if they are made aware of the possibility up front. The nature of a MVP app isn’t to be perfect, but rather to provide the best current solution to an unaddressed, or under-addressed pain point in your user’s lives.

In your App Store listing (which we’ll cover in detail below), you’ll want to include a section that explains three things:

  1. You understand that your app isn’t perfect, but you’re working on making it better
  2. Users can directly contact you to provide criticism or make requests for features
  3. Users can expect regular updates

Remember – users are more likely to delete your app from their phone than they are to keep it. This is why communication is important with your users – but doubly so with a MVP. Your users need to know from the start what they are downloading. They’ll be understanding if you’re upfront and transparent about your app. They’ll ignore, or even worse, spread bad word-of-mouth about your app if they are kept in the dark about what you’re doing.

Step 7: ASO

There are two fronts to your app’s ASO – User acquisition, and user retention. These can then be broken down into sub-categories:

User acquisition:

  • Keywords
  • The app’s build and compatibility
  • The app’s page on the App Store

User retention:

  • User reviews and ratings
  • Time users spend engaging with your app
  • In-app purchases (if applicable)

For a MVP, when it comes to a keyword campaign, focus on one main keyword, and derive from there until you have 5 keywords to work with. To continue with our example of Brew Trader, we’d use:

  • Beer
  • Beer Trade
  • Beer Swap
  • Beer App
  • Beer Finder

There’s a lot more to planning out and implementing a successful ASO campaign. For more information, visit our ASO: 101 blog post.

Step 8: MVP post-launch

This is the most important step of a MVPs development, as your execution here will determine the trajectory of your app’s future.

Start with both keeping track of analytics, and engaging with your users. Use every channel available to you to engage with your users – social media, push notifications, and responding to user reviews in the App Store itself.

For more information about tracking your app’s analytics, visit our guide to measuring your app’s success with Kumulos.

Next, you’ll want to start updating your app. In order to do this, start from step one – ideation. This time, however, use the requests and criticism, as well as your findings from your analytics to direct where you should be investing your time.

What are the steps to creating an app?

Do you want to create an app, but have no idea where to start? That’s okay! It’s actually not that complicated, as long as you have a roadmap to guide you.

Naturally, just like any idea or business venture, the first step is:


Whether your idea comes from inspiration from your daily life, or from finding a need due to market research, or even because your business needs an app; the strength of an idea isn’t based off of color schemes, names, or packing in trending feature sets to impress investors.

It’s all about how well your app helps solve the pain point your intended users face. It doesn’t matter what your app does, or what type of app it is – your app’s value will be judged by the solution it provides.

Gaming apps solve boredom, fitness apps help solve either lack of motivation or help keep track of goals, navigation apps help users find their way, banking apps help users answer the important questions like “Do I have enough money in my checking account for this coffee?”

You get the idea.

At this point, don’t sweat the small stuff – don’t even worry about what your app will look like. Only focus on the solution it can provide, and the most logical and practical way to facilitate that solution.

Market research

If you didn’t initially start with this step, you’ll want to do it now. You don’t even need a prototype of your app by this point – all that you need is your idea. Take that idea, and bring it to your target market. Talk with them about what they want. Go to networking events, conventions, local businesses, check out blogs, google “your idea + problems,” and most importantly, research your competition.

There’s 2 million apps on the App Store, and 2.6 million on Google Play – mathematically, it’s pretty likely someone has built an app that at least touches on the basis of your idea.

Your job isn’t to come up with an original idea – it’s coming up with the most optimal solution to that idea. If you’re worried about originality, don’t be – Homer’s The Iliad and The Odyssey covered every narrative trope imaginable – writers today just come up with ways to repackage those ideas.

Uber wasn’t an original idea – people had been flagging down taxis for a hundred years by the time Uber came along. When you boil Uber down to its core idea, all that it is is replacing a hand wave with an app – everything else is secondary. Instagram didn’t invent filters, it just made it easier to use filters to make your photos look better.

When you’re researching your competition, pay close attention to three things:

  • The UI/UX
  • The features it uses to solve the problem
  • The app’s ASO

Take from those three things the aspects you do like, and keep them. Replace what you don’t like with your own spin on things. Then, come up with how you can create a unique package for your branding. Remember – your idea, and even the features used to facilitate your idea, don’t need to be original. If you’re making an app that requires GPS and mapping, you’re inevitably going to implement location services during development – coding languages (and the methods for building app functionalities) were designed to be systematic and logical – not unique.

One more important aspect concerning market research – this is when you’ll want to decide what platform(s) you’ll use to build your app. Knowing which platform you’re building for will dictate every following step in the process of creating an app – and if you are building both an Android and iOS app version, you’ll need two dedicated development teams.

More about deciding which platform is best for your app:

Gather your resources

For you, this means finalizing your concept and your market research, and then finding a developer. Once you’ve settled on a developer, it’s their responsibility to determine your app’s feature set and the SDKs and APIs it utilizes to achieve your desired functionality.

Your feature set will be based upon user stories. User stories are detailed, step-by-step use cases of what a user will do during a session in your app in order to accomplish solving your pain point.

This is when it’s time to start planning out the design of your app. Some dev shops have their own UI/UX designers, some don’t. If they don’t you’ll need to do it yourself, or find a freelance designer.

App design usually begins with wireframes and color options (usually starting with the home screen and moving on from there), as well as planning out the UX of the main functionalities your app provides. Think of the inverted pyramid – start with the overarching themes, and slowly work your way down to the nitty gritty details. If your app has graphics, this is the step you’ll implement those – anything visual that your app requires should be complete before coding begins (if your app requires heavy backend infrastructure, start building that out as soon as possible).

For more information about proper app design, visit our blog on covering the topic.

From these designs, you can build out a prototype, which is actually much easier than you’d expect, via help from different prototyping applications:

Once you’ve signed off on a prototype, your development team can get down to actually building your app. A good developer will be able to take your plan and run with it from here – they’ll obviously check in to provide you with updates, and to make sure you’re happy with what they’re producing, but they won’t be asking you technical questions – that’s why you hired them, after all.


This is a step that begins after the first lines of code of your app are implemented, and after that, testing never ends. It might sound disheartening, but that’s the nature of the beast.

To efficiently test, lay out every step of your user stories (which you and your development team came up with in the previous step) in a spreadsheet, and identify the features that aren’t working properly. Take the time to make sure your app feels smooth and attentive to inputs as well. Users are likely to abandon slow apps in favor of faster ones.

Record every bug you discover while testing. Fix the issues, and test again. Repeat this step until testing is complete.

Then, it’s time for testing round two… beta testing!

Beta testing will open up your app to a small segment of the public – one that you, or a marketing agency (or your developer) will find. The purpose of a beta test is to increase the likelihood of catching bugs due to increased entropy. Beta testers, while not as detail oriented as a dedicated internal testing team, will use your app in the way they expect it to work – not the use case you have imagined. You’ll find out during this step if the two align, and iron out the kinks if they don’t.

Beta tests are important for another reason – it opens up your app to more devices and usage environments. Your app needs to work the same in a cornfield as it does on the subway. The text and font you used in your app may be legible in an office environment, but the sun’s glare might make it difficult to read. These are the kinds of details beta testing will pick up on, and improve upon.

For more information and tips about running a beta test, visit our blog covering the topic.


Before you launch your app, you’ll want to plan out your ASO. There are two fronts to your ASO campaign: user acquisition, and user retention, in that order. These can be broken down into sub-categories:

User acquisition:

  • Keywords
  • The app’s build and compatibility
  • The app’s actual page on the App Store (you can think of this as your app’s storefront)

User retention:

  • User reviews and ratings
  • Time users actually engage with the app
  • In-app purchases (if applicable)

Keywords are the bread-and-butter of any ASO campaign. The App Store’s search option functions in largely the same manner as a search engine like Google: users input a phrase or word, and the App Store displays apps based upon relevance and ranking.

Keywords are the foundation from which to build your ASO efforts, and effectively implementing them is crucial to your app’s success on the App Store. The most important steps you can take to ensure your keywords are working for you is to:

  1. Know your competition and
  2. Start with 2-3 keywords (as your campaign matures, consider utilizing up to five main keywords)

For more information about ASO, visit our blog on the topic. For more information about keyword research, check out our guide on the topic.


Congratulations! You’re almost there. The next steps are publishing your app, which will mean different things depending on what platform you want to release on. Both the App Store and Google Play have different approval processes and standards for apps to pass before they can be published, as well as publishing fees.

Apple has strict guidelines that must be met for your app to be approved – Android does not.

To publish an App on the App Store, you must pay a yearly fee of $99, and Apple takes 30% of profits from downloads (that 30% is only applied to paid app and in-app purchases). In order to publish to Google Play, you must pay a one-time fee of $25, and Android also takes 30% of profits from paid an in-app purchases.


As soon as your app is launched, you’ll want to start analyzing your user data. In order to do this, you’ll need to find an analytics platform. This is a very detailed and intricate process, so for accessibility, we won’t include that information on this particular blog – but you can find all the information you need about measuring analytics here.

Based off of your analytics, user reviews, and user ratings, you’ll want to start coming up with ideas for how to enhance your app. From here, you’ll begin again at step one: ideation.