It’s important to first mention that a successful developer usually views a new client as a long term partner, not a ‘one-and-done’ project.  If you are working with a developer that views working with you as a partnership, then you can be sure that the more time and effort spent in the discovery and estimation process, the more focused and lean your final cost, and final product!

An experienced developer knows that almost every client can save a ton of money by narrowing down the key features required to launch version 1.0 of the software.  This not only saves in development costs, but it allows the product owner to focus on successfully demonstrating core features to users, while facilitating the users’ feedback to determine the best enhancements to spend money on in version 2.0 of the software.  Additionally, experienced developers know that if you don’t save a healthy amount of your budget to obtain and support users to your platform after the initial launch, then your software is likely to fail.  This obviously doesn’t work well for a long term developer/client partnership!

To arrive at an estimate which you can rely on, it’s helpful to view the process within three main areas:

• Define the software users’ needs.
• Define the process to complete the project.
• Define the metrics by which the project will be judged a success.

In this blogpost, we will focus on the first area — Define the user needs

What problem do you solve?

When discussing the concept of your project with your developer, including all the features and functionality of the software, make sure you start by defining the problem you are solving for a user.  E.g., the way it’s currently done looks like X.  With our new digital platform, the process will look more like Y. In that process, be prepared to literally explain every step you envision a user taking from the moment they’ve logged into your software, to the time they have completed a session and logged out.  Don’t worry if you might be missing something, as there will undoubtedly be plenty of refinements to the user experience as you iterate with the developer’s creative team about your concept.

A day in the life of your user(s)

In order to ensure that you are covering all the needs of your user base, you may want to start by creating what developers call ‘personas’.  A persona defines an archetypical user of a particular software system.  It’s a detailed example of a fictitious person who would use your software.  It’s usually a two to three paragraph write up describing one of your user types, where there may be a handful of different user types (and thus a handful of different personas which you need to define).

When you write a persona, you start by creating their name, then their socio-economic and family background, their daily routine, their primary needs and desires… all within the context of how your software might touch one small aspect of that routine, and improve their experience.  You may refer to these personas by name throughout the entire project so that you better guide your developer’s decisions about functionality and design.

With personas, now the entire design and development team can be on the same page with you, and the product managers of your software, when discussing how each feature in your software directly affects each of your primary users.

Prioritize features and functionality

Rank all of the possible features that users of your software might have.  Start with those that the user would need most in order to solve their problem, to those that would be ‘nice-to-haves’.  Some features will make version 1.0, while others may fall into later versions of the software.  A good developer usually has no problem telling you the features that you DON’T need in version 1.0.  Yes, that’s less money in their pocket initially, but again, it all comes down to making sure you have remaining capital to market and support your software after launch.  This translates to a successful product and long-term partnership with your developer.

Roadmap it

Don’t be embarrassed to explain your features by demonstrating them with crude, even ‘back of the napkin’-type sketches.  Your developer’s UX/UI designer will be thankful for every bread crumb that you can give them so they may design something that successfully translates your vision to the screen.  Your developer may even convert your sketches into an abbreviated set of storyboards and wireframes before even calculating your initial project cost estimate.  This will help to eliminate any misunderstandings about what you can expect in your final product.  Of course, if you decide to pull the trigger on your project after the discovery scope and final estimate, then the developer will start by completing a highly detailed set of wireframes that will inform the final designs, and the code behind them.

Utilize competition

During your discovery scope, be sure and mention any other websites or mobile apps that provide some of the same features you want to provide to your users.  This can really help your developer hone in on what’s currently available that works, and what doesn’t work, for solving the same or a similar problem that your software seeks to improve.  Most developers take these live examples and use them to refine their search for even more examples of user experiences, or to create new user experiences to further improve your software.

Summary

Defining user needs can be the most time-consuming portion of your project.  However, thoroughly tackling this stage will help create a finished product that becomes something your users feel like they can’t live without!  And before you ever spend a dime to code your software, you’ve narrowed it down to only those features that your users need, which of course can save you a lot of money in development costs!

In the next blogpost, I’ll discuss how your development team can take your completed user requirements and convert them into a detailed estimate and timeline that you can understand, and rely on!

Native apps are coded specifically for a mobile app platform, such as iOS or Android, and are downloaded from those respective app stores.  Once downloaded, a native App runs directly on the mobile device without an internet connection required.  A native mobile app can fully utilize and integrate with the native features and functionalities of a mobile device such as push notifications, GPS, camera/video, device pairing, voice, accelerometer, etc.

A web app is simply a website, which requires internet connection to run, and is specifically designed to be viewed in an optimized fashion on most any mobile device. Whatever the type of mobile device you have, the web app will adapt to display properly on that device.  In many ways, a web app looks and functions somewhat like a native mobile app, but it does not need to be downloaded or installed on the mobile device.  With a web app, you also have a close to ready-made website for desktop users, in addition to the obvious mobile website that you have created with a web app.  With Search Engine Optimization, having a desktop website can further your marketing reach and app discoverability.

The main advantage to native mobile apps is that a user generally has a much faster, and overall engaging, experience while using the app.  This is because all of the powerful native device functionality can be completely integrated within the app; and information can be cached in the app, rather than relying on the speed of the user’s internet connection.  The downside of a native app is the total cost and time involved to design, develop, test and publish the apps for two separate mobile operating platforms (assuming you go with both iOS and Android).

Now that you have a basic understanding of a web app and a native app, we’ll throw in one more little variant to the standard web app.  We bring this up only because we don’t want you caught ‘flat-footed’ when some IT geek throws out this seemingly killer third option.  This third app option is called a progressive web app.  The PWA utilizes advancements in application caching which allows a standard web app to work better offline, and to utilize some of the mobile native features such as push notifications, video and audio.  Sounds like a no brainer way to go, right?!

Unfortunately, in our experience in working with PWAs we’ve found that, while most of the native feature utilization enhancements work OK on Android devices, many of them come up very short and often feel a little ‘buggy’ on iOS devices, which limits the PWA to more of a ‘half step’ forward option, or even a bad option, in many application instances.  Advancements to mobile browser technology will, no doubt, continue to improve the PWA as a viable third option.

At the end of the day, what does all this mean for you and your particular application project?  The key takeaway is to make sure you evaluate what device-native features your app users will actually need, relative to your budget constraints.  At Epic Apps, we’ve created many robust and engaging web apps for clients, where there was very little need for the user to have a native app to engage with the client’s platform.  On the other hand, there are many app use cases that couldn’t exist, but for the full integration of one or more key native device features.  If you aren’t sure, we are always happy at Epic Apps to discuss the best options for you in a free consultation.

Assuming you have completed that process and found no other live iPhone or Android apps using your name, you will now want to reserve your app name.  The ability to reserve an app name/title is very different between iOS and Android mobile apps, each with unique considerations.

iOS Apps

Let’s start with reserving your app name for an iPhone or iPad app.  With Apple, this involves setting up a developer account.  If you are using a developer to build your app, they can certainly open the account for you.  However, in almost all cases, whether they set it up for you, or you set it up, you will probably want to make sure that the Apple developer account (and this actually goes for setting up a Google developer account as well) is set up under your app’s business name and your personal contact information; phone and email address, specifically.  There are several reasons you want to do this.

First, if your app is set up under your developer’s name, the app will be published and listed under their name, and not the name of your app, or your personal name.  For branding purposes, would you rather be marketing your app, or marketing your developer?  Secondly, with intellectual property, listing your software to the public under your developer’s name could muddy the waters in any type of disagreement about ownership rights. And finally, if you set up your developer account using your developer’s contact information, instead of yours, whenever Apple has to contact you about any issues or important updates, you would be completely in the dark about such matters unless, and until, the developer relays the message.

Regardless of what contact information you use to set up your developer accounts, the actual process of signing up for an Apple developer account is very easy.  First thing to know is that, while it is free to create an Apple developer account, if you want to reserve an app name, and later submit it for publishing to the App Store, the cost is $99 per year.

To get the ball rolling, start by going to the Apple Developer Program page and click the Enroll button. For the Apple ID, if you already have an Apple ID, you can use that to start creating your developer account, but for legal and security reasons, it’s probably best if you create a new, and unique, Apple ID for your mobile app development(s).  Once you set up your unique Apple ID, you will need to enroll in the Apple Developer Program to reserve your app name, and eventually to publish the app.  Select to enroll as an individual or an organization, enter the proper contact information as we discussed above, pay the fee, and you are done!

After successfully enrolling, there is a short processing time, after which you’ll be contacted by Apple granting you access to the iTunes Connect portal.  It’s usually after this portal has been created that we see most app clients choosing to have their developer create the app entry, which effectively “reserves” the app name, assuming it’s not already in development by another developer.  A non-developer can still create their own app entry to reserve an app name.  Unfortunately, at this point in the process it does start to get significantly more complicated with things like certificate registrations, bundle IDs and environment set ups.  Just keep in mind, most app development firms are more than happy to help you complete this reservation process at little, or no cost.  After all, they hope to eventually work with you as a client to build your app!

Android Apps

So you have your name reserved with Apple.  Now what about Google …  Well, don’t shoot the messenger, because unfortunately you can’t really ‘lock up’ a name for an Android app! Google allows duplicate names. The good news from this; you don’t need to worry about reserving an app name early on Google Play, because you can’t!

Assuming you’ve gone through the name-search process we described in our last blog post, you’re all good, right?!

Well, not so fast!  Yes, the Play Store might technically allow a developer to submit an app with the exact same app name/title as one that already exists, as long as the app’s package name is different. Without digressing too far, the ‘package name’ is an ID parameter in the URL of the web page where your app resides on the Play Store.  It simply comes from a field you or your developer will enter in your Google Play Console. To find what the package name of any mobile app is on the Play Store, look at the url for the app.  The letters after the “=” sign are the app’s package name. (e.g., Airbnb’s package name in bold: https://play.google.com/store/apps/details?id=com.airbnb.android&hl=en)

App name vs. package name. Is the difference really relevant to you at this stage?  Well, no, since the first question you should be asking yourself is, “Why would I want my app to have the same, or very similar, name as somebody else’s app in the Play Store?”

Having the same app name as someone else not only creates confusion for Play Store users trying to find the app they are searching for, but it probably sets up all sorts of copyright and trademark infringement issues too.  Moreover, buried in Google’s Developer Policy Center, it states, “We don’t allow apps that use another app or entity’s brand, title, logo, or name in a manner that may result in misleading users…”, which means your app has a high probability of getting rejected at some point after you have put a whole lot of design work into an app created around your decided-upon name.

Confusing or misleading name-issues aside, keep in mind that the app name/title is what will not only be one of the key factors (if not THE key factor) in your app store discoverability, but it’s also the first impression that a user has after seeing your app’s icon.  In other words, don’t take your app title lightly, and don’t name it something that can be easily confused with an existing app!

When you are ready to have your developer start on the Android app, you will most likely still want to set up a Google Developer account under your app name and your personal contact information; for all of the same reasons we discussed in setting up your Apple developer account.

To set up your Google developer account, you will have to pay a one-time $25 registration fee.

Go to the Google Play Developer Console and sign up for an account.  The process takes no more than 5 minutes, as Google lays out each step very clearly.  If you get stuck, or have any questions during the registration, most app development shops will gladly help you for free.

The bottom line with an Android app name; just make sure that the Apple Store app name that you secure is something you can also use on the Play Store, but which isn’t misleading relative to other existing apps.

Whatever you decide to name your iOS or Android app, it’s time to start making it a reality!

One of the first things you will want to do is research and then reserve your app name before you spend time and money designing the logo and key screens. Before deciding on a name though, just one quick important note to keep in mind on the technical side of things regarding the app name. Android apps can have up to 50 characters in the Play Store, and can include the name of the app as well as the description of what the app does, i.e., what Google calls “brand name + key function”. One example is, “Trivago: Hotels & Travel”. Trivago is the brand name, and [finding] Hotels and Travel is the key function of the app. For an iOS app, you can only have 30 characters, but there is an additional ‘subtitle’ field for up to 30 characters. What you pack into those 50 or 30 characters can get pretty nuanced, as far as app optimization and discoverability. There are entire books written, and even more YouTube videos, on utilizing all sorts of fancy discoverability techniques like indexing and keyword selections. We’ll save that topic for another day.

So, what does that mean to “reserve” the name, and how do you even go about finding out if the name is already taken? In this blog post we will discuss the second part of that equation, which is how to best find whether your app name/title is available, and all the considerations involved with that. In our next blog post, we’ll describe the exact process for securing the name of your app in the app stores.

When you are trying to lock up a website domain name, it’s as easy as going to a large web hosting and domain registrar company, such as GoDaddy, Domain.com, etc., and typing in BestWebsiteNameEver.com in a search bar. Immediately you are told if it’s taken, or if it’s available. If available, you pay about ten bucks and BOOM, your domain is locked up! If only it were that easy to find and reserve your app name!

Unfortunately, with apps there’s no one, definitive, place to search and confirm if someone else already has an iPhone, iPad or Android mobile app name locked up, except through an Apple or Google developer account (discussed in our next blog post). However, before you even get to that point, you will obviously want to do a high-level search first. In most cases, conducting this initial search process will give you an extremely good idea as to whether an app with the same, or similar, name is already published. And often times these searches will reveal trends as to what might very soon be published and whether you might have any intellectual property conflicts.

The first “quick and dirty” search to find any iOS apps is to search in both the iPhone and iPad App stores from those two respective device types. Of course, you’ll also want to check for Android apps. Google makes this a little easier in that you able to do one search from the Google Play Store on the web.

The second search you’ll want to make involves looking for an existing app name through a good old fashioned Google search, using various search terms that are very similar, or matching, to your desired app name.   Then, you’ll also want to type in one of the following URL strings into a Google browser search bar:

1. To find an app name in the App Store type in site:itunes.apple.com app [enter desired app name here]
2. To find an app name in the Play Store type in site:play.google.com app [enter desired app name here]

Note: There will be lots of overlapping results from what you found in the app store searches. However, you can often find apps in development using the Google search methods, since it’s casting a much broader net using the world’s most powerful internet browser.

One final method to check if your app name is already published on either of the app stores is to search on one of the database aggregators on the web. Some of these sites offer a very comprehensive list of highly effective, paid research and tracking solutions that are used by app developers and marketers. However, they often allow any site visitor to do a quick name-search for free from their Home pages. One great example of a site that offers this is Searchman.com. We don’t use any of the paid features of Searchman.com, and this is not an endorsement of those more targeted research and ranking solutions that they provide for a fee. However, the limited, free search option that they offer seems to find the majority of app names we’ve searched which we know, or suspect, are already live.

So you’ve completed your search above, and nothing comes up that is an existing, published app using your desired app name. The next step is to do a free search on the www.USPTO.gov to see if anyone has already filed for a trademark in the same trademark industry classification number(s) that you want to eventually file your app’s trademark under. There are several great articles on the Internet about how to do your own initial search on uspto.gov without hiring a lawyer. Suffice it to say, that it’s really not that difficult. However, if you are going to spend tens or hundreds of thousands of dollars developing and marketing your mobile app, at some point you should realistically budget to pay an attorney to do an exhaustive trademark search and provide a professional opinion. Obviously, the scope of that legal process is well outside of our expertise, and this blog post.

If you’ve done all of the above, and still aren’t finding any conflicts out there for your app name, then you are well on your way to securing the name! In our next blog post, we will tell you how to find out if another developer has already reserved your app name in a development stage, and if not, what needs to be done to reserve it.

Imagine a restaurant at 5 p.m. on a Friday looking out the window at the start of a heavy snowstorm. In the old days, you’d send home half of your employees, and prepare to put a complete loss on the books for that night. Now, just send a push note out that says “2 for 1 entrees for app members from 5-7 p.m. tonight!” to folks in the neighborhood, and you’re good to go.

How are those Push Notes Received by your Customers?

Well, unlike text messaging, with push notes, a large percentage of smartphone users have their devices set to receive a push note on silent mode, so it doesn’t interrupt them if they are in the middle of something important. Whereas a text message often pops up under an unknown 5-digit short code, with none of your company branding, the push note lands on your customers home screen in a way that clearly reveals your brand and concisely states your deal or announcement.

A simple tap on the incoming push note, and your customer is brought directly into a fully optimized page view within your app that gives them all the additional details they might need. The push note could also have a link that opens directly to a page on an external website, to a specific tab within the app itself, or to a custom graphic that you can create. And if it’s something like an event you are announcing in the push note, then your customer can just tap to add the event date within the app, and it will automatically give them a reminder on the day of the event.

How to grab the User’s ‘Opt in’

Just put yourself in their shoes, and ask, “What would entice me to ‘opt in’”? An example might be announcing deals and limited offers first or even exclusively through your mobile app. Or announce important events, alerts, new products, special guests, etc. And of course, customers always love ‘free stuff’ (e.g., “The first 10 app users who come in receive xyz …”

When writing your push note (remember you only have 128 characters by FCC law) be creative, succinct, bold, humorous … whatever speaks to your customer demographics. But most important, be consistent! Sending out a weekly push note is much better than sending out just one monthly push note, even if that one push note is a really great offer or discount.

Always remember, the push note is a subtle, quick and easy way to stay consistently on your customer’s radar so they don’t stray to your competitors. So what are you waiting for? Get pushin!