How much does payroll software implementation cost?

/0 Comments/in , , /by

There are certain expenses every business has to accept – and one of the largest contributors to those reoccurring, inescapable costs is payroll. The time it takes to manage your payroll process will always need to be accounted for in your budget, but the time (and the resulting costs of the time and resources) spent can be diminished through the help of payroll software.

When it comes to choosing a payroll software, there are a multitude of options to compare – but first, we’re going to cover the reasoning behind paying for payroll software.

It’s about time

The goal of payroll is to be done in as little time as possible – there’s no profit to be made from it. Any process that cannot lead to income generation should be practiced in the most efficient manner possible – unfortunately, HR administrators tasked with payroll can spend up to ten hours a week on payroll alone.

So, when weighing the two options of either paying for payroll software or continuing to do it yourself, there’s an easy question to ask that will provide the answer as to which is more cost effective:

Which costs more – a quarter of my employee’s salary, or the payment model of a payroll SaaS?

For fun, let’s say the employee in question makes $35,000 a year – divide that number by four, and you’re left with $8750 – if your payroll is processed in house, that’s your yearly expense – for an administrative task that can never lead to income generation.

Let’s take that number and compare it to the cost of some of the more popular payroll software, apps, and APIs.

Freeware

There’s plenty of payroll software out there for free – and for small businesses, these are a good option. While not as comprehensive as proprietary software, free payroll software can help you accomplish simple payroll administrative tasks like payroll and tax computation and submission, direct deposit, new hire reporting, and year-end tax information.

There is one area that freeware can’t compete, however – scalability. There’s also a lack of options for customizing the software to your company’s needs – in the case of free payroll software, what you see is what you get.

If you’d like to try out your options before settling on a software for your payroll needs, there are many freemium versions of software that allow you to try out their service before purchasing payroll software.

One such is Gusto, which also has a proprietary software version that is purchased through a subscription. Let’s go over the cost of a subscription model payroll software:

Monthly subscription

While there are much more well-known payroll softwares out there (like ADP Workforce and Quickbooks) we think it’s important to showcase an up-and-comer like Gusto for two reasons: small businesses understand the needs of other small businesses in a more intimate way than large corporations, and there’s plenty of information already other there about both ADP and Quickbooks.

Despite a less well-known reputation than payroll software household names like Quickbooks or ADP Workforce, Gusto can do a lot: manage payroll administration, HR, and benefits administration and compliance, as well as automatically computing your business’ local, state, and federal payroll taxes (including payment and submittal of payroll taxes), and the option of paying your employees through either direct deposit or check.

Its inviting look, and simple UI make it the perfect option for someone in a small to medium business who either doesn’t have formal training in HR operations, or needs to make more efficient use of their time in the office.

Gusto offers two subscription options – their Core Plan and Complete Plan.

So, with a company of 10 employees, the Core Plan comes out to $1,118 per year, and the Complete Plan totals $3,228 per year. While still fairly priced given the automation and services Gusto provides, its costs can quickly increase as the scale of your company grows. On the Core Plan, a company with 100 employees would be charged $7,688 per year, and $16,188 on the Complete Plan.

Let’s continue looking at our options.

Per-user pricing

While this form of payroll software obviously suffers from the same issue as Gusto’s plan, they are definitely worth mentioning – for small businesses, per-user pricing payment models can be extremely cost effective.

PayrollHero offers employee attendance tracking, as well as scheduling, and time tracking and analytics – all available through a master platform that can be customized with product add-ons such as secure communication channels, data recovery, and unlimited storage. These add-ons do, of course, come with an additional price tag.

PayrollHero, like Gusto, has two payment options:

With 10 employees, the Small Business Plan comes to just $420 per year, and the Enterprise Plan comes to $540 per year. While these are extremely affordable options, PayrollHero doesn’t offer too much in the way of customizability or payroll tasks that aren’t directly related to employee attendance. For a small company that only needs a lean payroll system, however, PayrollHero is a good option.

Let’s look at a more customizable payroll platform and payment model:

Quote-based pricing

You can think of this option of payroll software as a pick-and-choose model. The perfect example of a quote-based payroll system (and one of the most widely-used payroll platforms out there) is Paychex.

Through the PayChex Flex platform, you can build your own payroll system out of pre-made sections of software – each option runs completely on its own, and they all seamlessly integrate with each other. These selectable options are as follows:

  • Payroll
  • Time & attendance
  • Retirement services
  • Recruiting and application tracking
  • HR records
  • Benefits administration
  • Hiring and on boarding
  • Reporting and analytics

Due to its customizable nature, it’s difficult to give a set price range for Paychex’s software – and prices can vary depending on the scale of your payroll operations.

Paychex is continuously improving their software through the Paychex API Developer Center.

Now that we’ve covered the different payment models of payroll software, let’s look into the costs behind the actual coding of the feature sets that make up a payroll system:

Custom payroll software development

If there are all of these great options, what’s the point in developing your own payroll software?

Lifetime value – yearly expenses add up after awhile. For example, let’s look back to our first payroll software example, Gusto. After 10 years, their Complete Plan will total $30,288 – and that’s if your company experiences zero growth over ten years.

Let’s pretend a company that started with 10 employees now has 100; at a rate of 100 employees, Gusto’s Complete Plan comes out to $16,188 per year. In just two years, that’s almost a much money as the yearly salary of a single employee.

A custom-made payroll platform has a much more cost effective lifetime value – there is only the upfront cost of development, and after your initial expense, the only extra associated costs come from maintenance or further additions to your custom platform.

Essentially a very complex backend system hooked up to different UIs, custom payroll software can cater to any business need – every feature listed in this blog can be implemented (and more): including commission management, and split payment management.

You can also integrate a custom-made payroll platform into your already existing internal business app.

Custom-made payroll software is undoubtably the most affordable option at scale – since the code is owned by your company, and not loaned by a third party, you can scale your custom-made payroll platform to any size of workforce and company infrastructure – and with mobile integration as well.

We’ve stated it many times throughout our blog – but it remains just as true; the cost of software development comes down to time, not type of software being developed. For a fairly complex custom-made payroll platform, designing and building the backend will take up the most time – this includes building out the logic, creating the backend architecture (how collections of data will communicate), and building out servers to store your payroll data.

Other costs include UI design, as well as the coding of the front end of your platform. All in all, an average estimate could range from $50,000 to $250,000 depending on your desired complexity. Those are big numbers – but keep in mind, they are truly one-time costs, and the product developed is fully scalable, at no extra cost (other than server maintenance).

Let’s compare those numbers to the expenses of a company with 1,000 employees using Gusto’s Complete Plan. After 10 years with 1,000 employees, Gusto’s costs come out to $121,490. If you’re planning ahead for your company’s future and growth, a custom-made payroll platform will end up being the most cost effective option.

Empower your HR team

When your company makes use of payroll software, your HR department has more time to do what they’re supposed to do – build and disseminate your company’s employee culture. Internal culture and employee happiness are directly related to productivity, speed of business, and employee longevity and loyalty.

When your HR team is working for your people, and not your money, your business can grow into a more efficient, productive, and happy workplace.

Android or iOS development – which costs more?

/0 Comments/in , /by

This blog was updated on July 3, 2019

Developing an app is never an inexpensive endeavor, which is why it’s always important to cut any unnecessary costs. What’s the most significant variable to the cost of developing your app?

Android, or iOS?

After identifying your targeted pain point, the next question you should always ask yourself is this: which platform do I launch on? Answering this question will dictate your UI, your marketing, your development, your testing – the entire strategy behind building your app, basically.

Quite often, however, the most important aspect of developing an app isn’t which platform to develop for, but which platform costs more. So, which platform does cost more to develop for? Well, by now you’ve probably noticed a pattern – it depends.

For the time-pressed reader, the more affordable option is usually iOS. But there are factors that can alter this answer, and it’s important to know why and how these factors impact the cost of developing an app.

Let’s get into it.

The two wrestling giants

Both Android and iOS boast an almost unprecedented number devices sold, available apps, and total app conversions:

  • In 2017, over 1 billion Android devices were sold, while Apple sold over 200 million iOS devices
  • As of 2018, Google Play has 2.6 million apps available for download, while the App Store comes in a relatively close second with 2 million
  • In 2018, App Annie released a report stating that the total number of app downloads between Google Play and the App Store was 28.4 billion conversions – of that number, Google Play accounted for 20 billion downloads

Android owns significant percentages of the marketplace, while iOS apps see higher user retention:

  • In the U.S., Android owns 54.6% of the market, and iOS owns 44.4% (Android is the top performer globally)
  • More iOS users download purchasable apps than Android users (11.82% vs. 5.76%)
  • iOS apps have a higher retention rate than Android (1% to 3% higher)

Something to keep in mind: While Android does account for a larger share of the mobile market than iOS (at least in terms of devices sold), this figure is likely skewed by the fact that Android comes with many pre-paid phone options, and there are no iPhone counterparts. While this larger presence seems to indicate apps available for both platforms would see more downloads from Android, we have witnessed the opposite from the data of apps we have published.

Out of these three apps, one has an audience centered in the U.S., one is centered internationally, and one has an audience split almost evenly between the U.S. and international markets.

  • For the U.S. centric app, 76% of downloads are from the App Store.
  • For the internationally centric app, 46% of downloads are from the App Store.
  • For the app evenly split between U.S. and international markets, 65% of downloads have come from the App Store.

Purchasing power and user profiles

When you compare the average revenue per user between app categories on Google Play and the App Store, despite iOS accounting for less devices and downloads, iOS apps see higher average earnings than Android.

  • 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)

What’s the reason behind these differences? While it’s important to keep in mind that the following findings are generalizations of markets, and not indicative of every user profile, there are noticeable trends that arise when comparing Android and iOS users:

Again, these are generalizations, and should be treated as such.

Some other interesting stats on user profiles:

  • iPhone users are more likely to engage in m-commerce
  • Apple customers are loyal; 80% of iPhone users have perviously owned another iPhone
  • iOS users tend to favor social media and retail apps, while Android users favor utility and productivity apps
  • iPhone users tend to identify as extroverts, and Android users as introverts

The cost of development

Development costs, no matter what platform you’re developing for, come down to three factors: time, hourly rate, and investment in infrastructure (like the computers used for development, or the servers that house your app’s backend).

The time it takes to develop an app can be further broken down into three determining factors: ease of programming, testing, and publishing (specifically the review of your app before it is officially launched).

Swift, the coding language all iOS apps are programmed with, is robust, streamlined, and was written expressly for the purpose of building apps for Apple’s devices. On the other hand, Android apps can be built by JAVA, C++, Kotlin, and Go (among others).

While the latter two of these languages were written with the same purpose as Swift (app development), JAVA and C++ have been around long before the idea of what an app is today had come to fruition. JAVA saw its public release in 1996, and C++ was released over a decade before that.

Since these languages are old enough to order a beer and not get carded, there are more programmers who can code for Android than iOS. While this does usually translate into a cheaper hourly rate when hiring Android developers, it doesn’t always ensure you end up with a smaller bill to pay.

There are conventions that no Android developer will break – but while there might be two, or possibly even three ways to write a feature in Swift, there’s a multitude of ways to code that same feature with JAVA (the most popular Android programming language). Due to this, when comparing the two platforms based on ease of programming, Swift tends to come out on top.

If you’re being incredibly thorough with testing your iOS app, you’re going to need about ten different devices (ranging from the iPhone 5s to the Xr, to the different iPad generations, and possibly Apple Watch). To achieve the same level of quality assurance for Android, you’d need 24,000 different devices (and there were that many in 2015!).

Realistically, a good batch of Android devices to test with are all the popular and currently used devices, plus as many others as you can get your hands on. But even when accounting for ignoring 23,970 devices, those thirty remaining Android devices still add up to at least three times the amount of devices that need to be tested against. Again, when it comes to testing, and the time necessary to properly do so, iOS comes out on top.

With so many devices necessary in order to properly test your app, Android apps can require a significant investment in infrastructure. It is definitely worth noting, however, that iOS app development requires Apple products, which means if you don’t already have iMacs or MacBooks, you’ll need to find a developer that does, or foot the bill yourself.

When comparing the cost of investment in infrastructure for both platforms, it really depends on what infrastructure you already have in place – if you already own Macs, iOS would be the cheaper option. If you already own a bunch of Android devices, Android will be the cheaper option.

What costs more to publish – Android or iOS?

Publishing an app on the App Store or Google Play is a drastically different process – Apple requires a stringent process to be followed before publishing – Android, in comparison to the App Store’s publishing guidelines, offers developers a much simpler route to publishing their app to Google Play.

Let’s go over the publishing process for both, and what these costs mean for you in both the short and long term.

Android publishing costs

Publishing your Android app to Google Play is a straightforward process. Android does review apps – but the approval process is automated, so it is relatively quick. Before officially launching your app on Google Play, you’ll want to create your promotional materials.

These are what make up the content on your Google Play listing, and are comprised of: in-app screenshots, teaser videos, graphics, and promotional text.

Next, you’ll choose your publishing options – this includes setting such as what languages you’d like your app to be listed in, as well as how much you want to charge for your app based on region.

Finally, you’ll confirm your options and promotional materials, and then push the “publish” button. In a few moments, your app will be available in all previously selected regions through Google Play.

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 – updating apps is free, and updates to your app’s code aren’t usually review by a person.

When it comes to publishing an app to the app store, it’s an entirely different ballgame.

iOS publishing costs

First off, to get the easy stuff out of the way – if your app is going to be free (as in no revenue from downloads, subscription fees, ads, anything) you’ll only need to worry about: administering your App Store account, gathering your promotional materials, and your app’s review – after that, you can publish.

Publishing a free app to the App Store is largely the same as publishing an app to Google Play, other than without any of the associated publishing and sales costs.

Publishing a revenue-generating app to the App Store is a more involved process.

First, you’ll want to accept Apple’s payment agreements, and your tax and banking information.

Second, you’ll add your users to your App Store account, which can easily be done by entering their email. From here, you can assign privileges and roles – this will help with administering your app’s page on the App Store, which will be essential in order to manage your ASO campaigns down the line.

Third, you’ll add your app to App Store Connect – this doesn’t mean that your app is available for download, nor does it require your app’s code be complete. You can think of this as setting up your app’s profile page for the App Store. After adding a build to App Store Connect, you can upload multiple versions through either Xcode or Application Loader – you can then view these variations through your App Store Connect profile.

Next, it’s on to testing and submitting your app. While Apple does require a more stringent review process for apps submitted to the App Store versus those on Google Play, they do help with the setup of your app’s beta test.

By using Testflight, you can upload a beta version of your app to send to your testers – from here, you’ll want to go through the steps listed in our blog, All about beta testing: When, why, and how. After you have deemed your app ready for review, you’ll submit it to apple for their approval to the App Store. These are the guidelines Apple grades apps by:

  1. Safety – Apple looks for harmful or offensive content, data security risks, and much more. All of these risks are more carefully considered when the app’s main audience are children.
  2. Performance – Apple will be on the lookout for incomplete apps, if beta testing was indeed conducted, if your app’s metadata is correct, and if it meets hardware and device compatibility requirements
  3. Business – Apple will make sure your app follow all of their business, payment, and licensing rules.
  4. Design – Apple looks for copycat designs, functionality, if spam is used, and many other factors.
  5. Legal – Apple will search for any violations of it’s legal agreements, especially those relating to user and data privacy – this is especially stringent when the app’s main audience are children.

After submitting your app, a real human will review your app by these guidelines and more – if you are gearing up to submit your app to the app store, we highly recommend heading over there yourself before you do.

After approval, you can officially upload your app to the App Store! 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).

It is also worth noting that for every update you provide for an iOS app, Apple must approve that update before it can go live. This review process is again conducted by an actual human being.

When comparing the two platforms based on time and cost to publish, Android is the winner. These differences do, however, influence other aspects of your app’s lifecycle, which we’ll cover a little bit later in this blog.

The cost of marketing

This is probably the aspect of launching an app that is least influenced by which platform you’re building for – but due to the centralized nature of Apple products and customers, iOS app marketing usually comes out cheaper.

This isn’t due to Android app marketing relying on different marketing channels than iOS, but rather the scale at which Android apps must market themselves. Because Android has such a large presence in international markets (one of the main attractors to the platform), you’ll inevitably spend more time and money marketing to those extra markets than the mainly U.S., Canadian, and western European markets iOS users usually reside in.

This is also influenced by the need to market your app in the native languages of those respective markets.

Longevity

Remember those strict Apple publishing guidelines? When it comes to getting the most out of the lifecycle of your app, those rules and regulations will actually work to your benefit. iOS apps are more secure, therefore they can be used for a longer period of time before being confronted with a vulnerability.

iOS apps are required to notify users of data collection, as well as receive their permission in order to do so. Because every update is reviewed by Apple before it can go live, users can always expect an update to provide meaningful, tangible improvements.

While these rules might seem strict initially, they’re powerful user retention tools. Privacy and data security are at the forefront of your users’ minds all the time, and generally speaking, iOS users can expect a higher degree of security from their apps.

One aspect of app lifecycle management where Android comes out on top is its open source nature. Because the platform itself is based around open source releases, and its core libraries are available to everyone for free, Android does have the benefit of unlimited potential for growth and innovation. In addition to this, because iOS is only available on the iPhone, iPad, or Apple Watch or TV, there is always a potential that Apple products will fall out of favor with the market.

If Samsung fails, Android remains strong. If Apple fails, iOS is gone. There is no indication that this is going to happen anytime soon, but it is worth noting.

There’s a time and place for everything

Generally speaking, if you want to access users in western markets, iOS development will be the cheapest option. If you’re looking towards international markets, Android will take the lead – at least when it comes to lifetime profits. But when accounting for time to develop and test an app, iOS will almost invariably come out on top.

Custom app development costs

/0 Comments/in , , /by

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.

Design

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.

Easy app development

/0 Comments/in , , /by

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…

Launch

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

/0 Comments/in , , /by

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.

How design impacts mobile cost

/0 Comments/in , /by

Did you know a full service development shop will put, on average, 100 to 120 hours into designing an app’s UI/UX? That’s a significant amount time – and when dealing with large scale apps, such as social media platforms – or even larger design projects, like mobile games, design hours can skyrocket into the thousands of hours.

Let’s look into why this is.

The process of designing an app

There’s a step-by-step process most mobile design teams will follow, starting from even before rough sketches. This process dictates the workflow from the first hours of working on a project all the way to building the UI/US itself in the actual code of the app.

Let’s go over those steps:

Doing your homework

First things first, do your research. Designers will usually spend at least a few hours looking at apps that exist in the same space as the one they’re about to design. This is done for a couple reasons; there’s no point in reinventing the wheel, and it gives designers a good grasp of what app users have already come to expect from apps in the same category.

With this information, designers are able to take what works from those competitors, and after critical analysis, determine what they can improve upon, or what can be changed to fit the brand of the app in order to provide a more meaningful experience. There’s another added benefit to performing a competitor analysis before starting design – it helps the design team avoid stepping on the toes of any IPs.

Logo Design

Unless the design team is working on an enterprise level app for an already existing company, you app is most likely going to need a logo for the App Store or Google Play. A good development shop will have the capability to design you app’s logo – and it’s a good idea to keep this part of the design process in-house.

Designers are specialized, just like any profession – there’s a reason the tech industry distinguishes between web dev and mobile. A print designer will make a good looking magazine, a t-shirt designer will make a cool graphic tee, and a UI/UX designer will design a logo optimized for ASO, user acquisition, and your app’s brand.

Depending on your app’s brand, designing a logo can take anywhere from 5 to 50 hours.

There’s a lot we could talk about when it comes to properly designing a logo for an app. Maybe we’ll cover it, down the road.

Wireframes and layout

If you’re not familiar with the term wireframes, this step starts out as the “sketching on the back of a napkin phase,” and ends with a fully structured (at least visually) app. This step in the design process can take from 20 to 50 hours, and if it’s a large, complex app, even longer than that. While this is a significant amount of time, it’s absolutely necessary, and critical to the success of your app.

I’d go as far as to argue this is the most important step of visually designing an app – building out the wireframes and overall layout of an app is, essentially, deciding the entirety of the app’s UX in a single step of the development process. Sure, during other steps in the design process, you can make topical changes to an app’s UX (such as color schemes to influence certain moods), but changes such as these don’t carry nearly as much weight as the actual flow of the app itself.

A proper wireframe layout will include all the information someone would need to understand how the app will work – while boxes will lack graphics, they will include language that denotes what information will be held within those visual boundaries, as well as how it will interact with the elements around it (aspects such as movement, scrolling, fading, or other interactions).

This step also lays the groundwork for an incredibly important, but often under-appreciated element of your app’s design – its negative space. The space surrounding the individual elements of your app like text, or boxes are called gutters. While their name might not be pretty, if your apps gutters aren’t uniform, users will notice, and be extremely thrown off – and worst of all, they won’t know why – they’ll just have a subconscious feeling that something is off about your app.

Design is a language everyone can implicitly understand, and when there’s a change in the uniformity of a product, especially an interactive one, our brains are wired to pick up on it. We are built to recognize patters, and when those patterns are broken, our brain sends off a warning light that’s incredibly difficult to get rid of.

When there’s a difference in the spacing of your app, even just a few lines of text, users will notice immediately notice.

UI Design

Designers will then take those wireframe layouts and turn them into the finalized interface for the app. This is the step where designers will make your app’s icons, decide and implement font styles, finalize the motion of the UI (the way the app responds to users interactions), and implement the feature set (in the form of interactive visual elements).

Something I believe is important to impart is that designers don’t just make things look pretty – just like there’s a backend to development, so to is there a backend to design. The previous step, building out wireframes, is akin to determining your APIs – and this step, UI design, is the equivalent to connecting the endpoints.

It’s a designers job to translate a tech doc into a visually interactive and stimulating experience that fits on a (relatively) small screen, is compelling, cohesive, and helps them solve a pain point they face in their lives by the most efficient path possible. There’s a lot more to UI design than selecting colors.

A designer’s day is basically one continuously reoccurring A/B test. Questions like “Does the placement of this button add to the overall UX, or detract from it?,” plague a designer’s day.

UI design can take anywhere from 30 to 100 hours, depending on the complexity of your app.

Prototyping

This step in the design process serves as the bridge between designing an app, and actually coding it. While it does add an extra step to the process, it does help to cut down on time spent revising your app after it’s already been coded however.

Development shops use this step as what I like to refer to as an “island of stability.” It serves as the benchmark for all development moving forward, because the prototype is the, after the wireframes, the first real interactive product shown to you, the client.

A prototype is designed to be as close to the imagined finalized app as possible – from UI movement to font sizes. Prototyping tools are used to demo the feature set of the app, and should demonstrate the entirety of the app’s functionality.

This is as such so you, the client, are able to determine what works, and what doesn’t. Once a design and feature set have been agreed upon by everyone, it’s time to move onto the final step of the design process.

You can expect prototyping to take anywhere from 5 to 15 hours, or more for complex apps.

Build out the UI/UX in actual code

This is where developers will take a backseat in the design process, and your developers will step in. While the designers might not be as involved with your app’s development from this point onwards, they aren’t out of the picture entirely.

In order to build out and code the actual app, developers must translate the visual elements of your app’s design into code. In order to do this, they need to develop their own structure to keep everything in its place.

To code the design of an app, programmers must hook up features that need to access servers or other outside data to the backend, as well as create the app’s individual design elements in code. In order to maintain your app’s quality and brand, programmers will make sure your app looks the same, no matter what screen resolution it’s being displayed on.

If your app is being developed for both Android and iOS, this means your developers will need to make sure it looks and works the same, whether it’s on an iPhone or a Samsung. This will, at the very least, double your app’s development time, and why most dev shops will caution appreneures to start out with a single platform.

How much does it cost to implement real-time updates in your app?

/0 Comments/in , /by

We’re on to the next chapter of how much does it cost to make an app?, and this addition we’re covering real-time updates. At their most basic level, real-time updates provide data that allows users to make more pertinent and informed decisions, and to then take action (at the right time) based on that data.

There isn’t one single real-time updating method for apps, however – just like anything that is built through software development. So, how much does real-time implementation cost you? Well, to keep the trend going, it all depends on what you want to achieve.

It’s important to note that for all types of real-time updates, there are two significant factors to their cost – time to build/implement, and the cost of data transfer throughout the lifetime of your app. If you’ve read our blog about how much it costs to implement a GPS/mapping API?, you’ll be familiar with the idea that every request made from a client to an API has a monetary cost associated with it.

The same goes for real-time updates (in fact, GPS and mapping APIs use real-time updating to function), and each data transfer will have a cost that comes along with it (for many reasons).

Let’s get into how these functionalities work:

The mechanisms behind real-time

There’s a lot of tasks real-time updating can accomplish – from detecting fraud at the moment of a transaction, to sending out the latest and greatest offer to a customer near your store’s location via proximity marketing.

Updating a device with data from a server can only be accomplished in a few different ways, however:

Polling

The simplest form of real-time data transfer is called polling. It’s the equivalent to knocking on your neighbor’s door at regular intervals until they answer. Or, for a more real-world example, it’s when a client continuously requests data from a server, based on set intervals of time.

While it is easy to implement, it’s a very inefficient form of data transfer – even if there is no change of state in the server, data will still be transferred every minute, or five minutes, or whatever pre-determined period of time you set. This forces you to play a balancing game against just how close to real-time you want your app to be, versus the cost to do so. The more requests you have, the more servers you need – which comes with higher infrastructure investment requirements, as well as higher maintenance costs.

The more data requests and transfers a server handles, the higher your costs will be. On the other side of the coin, if you don’t allow for enough server requests, your app won’t actually be updating itself in real-time – it’ll be more like what-happened-five-minutes-ago-time.

 

SCHEDULE A CONSULTATION WITH AN APP DEVELOPMENT EXPERT TO GET A CUSTOMIZED QUOTE!

Long Polling

Long polling is very similar to polling, but with one key difference; rather than visiting your neighbor’s doorstep every minute, it’s like leaving a note on their door that says “come over when you’re ready.” In more realistic terms, it’s when a server only transfers data to a client if a change has been made to the data on the server.

While this does solve the cost issues associated with polling, it still comes with some pretty significant drawbacks:

  • Servers can sometimes be expected to hold on to massive amount of data
  • It is difficult to recover a session if a connection was lost with high reliability

Because of this, long polling has the potential to become a burden to large scale apps that require a high frequency of updates, or utilize segmented campaigns to target specific user groups.

Websockets

Websockets can be thought of as a tool that turns a client into a server – it allows the client to both make and listen for data requests – giving the actual server the ability to very easily update the client.

Websockets function by the client providing what is called a callbackURL. These can be thought of as the phone number the server dials when it wants to transfer data to the client.

What this means is that because a client can actively listen to the server, there is no data transferred until a change has been made to the status of the server, and if connection is lost between the server and the client, it doesn’t matter, because the client will resume its active listening pattern.

It’s the digital version of installing a camera on your neighbor’s front door so you know when they’re home – except less restraining-order-worthy.

Note: “Websockets” and “webhooks” are easily confused terminology. Webhooks are used for server-to-server communication, and tell a server to send data to a specific URL. Websockets are used for server-to-client communication.

 

USE OUR APP COST CALCULATOR TO ESTIMATE THE COST TO BUILD YOUR APP!

Subscription Websockets

These are essentially the previously-mentioned websockets, and function in a very similar manner – the key difference is that they allow the client to determine what changes to data they want to be alerted about. For example, if a package delivery service uses a client-facing app, the client could select different types of data changes to receive alerts for: packed sent, package delayed, package delivered.

Methods of real-time implementation

There’s two pathways you can take towards implementing real-time updates: native development or through a third-party API.

If you’re going down the native development route, the cost of implementation varies depending on a multitude of factors, including: hourly rate, the complexity of the feature, the server infrastructure, and the amount of maintenance that will be required in the future.

Native development of real-time capabilities does come with perks, but its cost will ultimately come down to how much time you spend maintaining your server – while third party APIs come with reoccurring costs in the form of subscription fees – it’s a bit of a toss up as to which costs more. While natively run servers will cost less when everything is running smoothly, if something goes wrong, the maintenance fees fall to you.

Depending on the complexity of the real-time feature you’re implementing, your costs could range anywhere from $10,000 to $25,000.

Let’s go over some of the third-party APIs available:

Apache Kafka

Kafka can be used for messaging, website activity tracking, log aggregation, stream processing, and event sourcing. Like everything under the Apache license, it’s open source, and therefore free API to implement.

PubNub

PubNub can provide real-time integration for chat features, IoT device communication and streaming, mapping, GPS, push notifications, and alerts. PubNub’s services start at $49 per month, plus data transaction fees.

Fanout

Fanout.io serves as a proxy for real-time updates. Fanout also allows you to develop your own APIs alongside their service, so you can provide your own customization based on your app’s specific needs. Fanout costs $25 per month, plus data transaction fees.

Realtime

Realtime.co is a message broker that operates in real time through the cloud. It can be used for cross platform apps – and has SDKs to go with both Android and iOS. Realtime’s pricing starts at $49 per month plus data transactions, and goes up to $250 per month plus data transactions.

AWS AppSync

Amazon Web Services offers their own real-time updating API called AppSync. AppSync can be implemented for almost every use case imaginable. AppSync’s services cost $4.00 per million query and data modification operations, $2.00 per million real-time updates, and $0.08 per million minutes of connection to the AWS AppSync service.

Firebase

Firebase – Google’s comprehensive mobile development platform – has two different real time services: Realtime Database and Cloud Firestore.

Realtime Database stores your data on a single JSON (JavaScript Object Notation) tree. JSON is a “lightweight data-interchange format,” and is easily readable and writeable by people, and quickly parsed and generated by computers.

Cloud Firestore stores data in documents, which are organized and stored in collections. Documents serve as the unit of storage, and are written in a syntax extremely similar to JSON. Documents can be broken into sub-collections and nested objects, which are referred to as maps.

Both Realtime and Firestore are NoSQL databases, which come with their own pros and cons when compared to more traditional SQL databases. While SQL databases are organized to write data in a very efficient manner; NoSQL databases are organized to read data quickly, but due to their structure, require duplicate data in order to access information.

You can think of a SQL database as a collection of tables that hold very specific, uniform sets of information, that link up in a web. NoSQL databases are structured in branches, which lead to other branches, which lead to other branches.

NoSQL

Basically, when data needs to be shared instantaneously across hundreds, thousands, or even millions of devices, NoSQL databases are very efficient because of their data structure. Both Realtime Database and Cloud Firestore offer real-time and offline support with SDKs specifically built for mobile. Both are capable of being implemented for pretty much every real-time use case you can think of – from chat to re-sizing photos, to analytics and machine learning.

If you know your app will only be used by a relatively small audience in a localized area, and your data sets are straight-forward, go with Realtime Database. Cloud Firestore horizontally scalable – meaning it works better than Realtime Database when used across multiple localized areas, as you don’t need to create shards in order to do so. Because of Firestore’s structure, data is very easily split between different servers.

The Firebase payment model starts at a free version, and has two other plans: $25 a month, and a pay-as-you-go option.

Apps that utilize real-time

Sometimes, it’s a bit difficult to imagine what kinds of apps use real-time features in order to work properly, or improve their UX. So, here are some real-world examples of apps that use real-time tech:

Uber

Real-time tech is the backbone of Uber. Without it, users wouldn’t know where their driver was, driver’s wouldn’t know the location of their passengers, and GPS wouldn’t work.

SafeLite Auto

Much in the same way Uber relies on real-time updates to track its drivers, so to does Safelite’s app, which provides users with the location and ETA for a mobile technician.

WhatsApp

WhatsApp uses real-time updates for chat, voice, and video features. This is necessary for low-latency communication, and keeps conversations smooth, with even pacing, and no downtime.

Dominos

Real-time updates are how Dominos keep customers informed about the status of their pizza order – when it’s in the oven, when it’s ready for pick up, or when it’s out for delivery.

Inventory management

Inventory management at scale would be completely impossible without real-time updating capabilities. Keeping accurate track of your company’s stock requires knowing your exact inventory numbers every moment – when you’re working at a national or global scale, conversions can happen at rates that can only be tracked through real-time updates.

Your options for real-time

There’s plenty more services out there – but what’s important to know is that just like most software services, the costs of a real-time APIs increase with the scale of your app. If you’re going the native development route, your costs will largely rely on how much infrastructure investment is required, as well as your servers’ maintenance costs.

How much does it cost to implement login capabilities?

/0 Comments/in , /by

There’s a lot of apps that require a login feature – mostly out of necessity for the app to work properly – but data has shown giving users the ability to personalize their experience within your app is a powerful UX strategy when used to increase your user retention.

There is, however, one major downside to including the requirement that users set up a profile before they can fully utilize your app: app abandonment due to first impressions.

If users are met with a proverbial checklist of requirements to complete before they can actually use your app, they’re much more likely to give up before proceeding. This is where implementing a login through social feature comes into play – it gives your first-time users the ability to create a profile with one tap, rather than filling out forms and fields.

So, how much does this user-retention-saving feature cost?

Honestly, not too much – it all depends on how secure you want it to be. If you use our favorite app analytics platform, Kumulos, it can take anywhere from 1-3 hours to implement a login feature with an app, depending on the complexity.

Implementing a login feature with the lowest form of security (basic authentication) can cost as little as $100 to implement. Apps that want to utilize the highest levels of security can expect a cost of $10,000 for a login feature implementation.

When it comes to the cost of implementing logins with social media, such as Facebook, or Instagram, there is no extra cost – just the addition to the time it takes to actually implement. The price of these social login features comes from labor cost – the APIs themselves are free.

Let’s look into why adding these extra layers of security can cause such a drastic change in total cost, and, if the added security is worth it in the long run.

The costs of security

There’s many different forms of security when it comes to user authentication. The costs of which can vary depending on many different factors – ranging from time to develop to the cost of physical infrastructure.

There is something important to keep in mind in regards to the cost of security: the cost of code only changes if you are implementing third party APIs that come with a price tag or subscription fee – implementing your own code to allow for security that exists in a digital space only comes with different associated costs due to one factor: time to develop.

Let’s cover those:

Basic Authentication

The least complex login method is called basic authentication. Let’s go over how user authentication (at its most basic levels) works:

  1. A user enters their credentials
  2. Those credentials are sent to an authentication server
  3. The server will then attempt to match the credentials together
  4. Upon a match, the server authorizes the user’s attempted access

This process is faster than it sounds – it happens every time you login to a website that requires your username and password, such as your bank. This process is also referred to as “logon” authentication.

Single-Sign-On (SSO)

SSO functions very similarly to logon authentication, but rather than granting access to a single server, it grants access to multiple – a lot of social media and email websites will use this feature.

While SSO is the least secure method (as it gives access to multiple servers), it works well for apps for two reasons – smartphones are generally intimately used devices, so the chances of someone physically accessing your personal information via your smartphone is diminished; and, SSO does wonders for user retention, which is a hard-fought battle for most apps.

IPSec

IPSec is the most secure form of user authentication. IPSec allows data to be encrypted and authenticated over a secure internet protocol network. In order for the user’s device to understand, and then display the correct information based on the encrypted data, a method called mutual authentication is used.

This happens at the first instance of the user logging in, and continues to happen throughout the session as cryptographic keys are exchanged over the secure server. This can be implemented in three types of data transfer: user-to-user, network-to-network, and network-to-user.

Biometrics

Biometric security is largely implemented through physical means, and utilized in mainly on-site locations, rather than remote – therefore, its most common use case is in buildings that require high amounts of security.

Current biometric capabilities include finger print scanners, voice recognition, and retinal and face scanners. These capabilities are rapidly changing and expanding into different realms of biometrics, such as heartbeat and even brain activity.

Biometric security is a high cost investment, as it requires specialized scanning equipment – because of this, its costs can greatly exceed $10,000 – this number depends heavily on the scale and amount of scanning devices required.

Token Authentication

Token authentication requires a user to physically possess a device, such as a dongle, card, or RFID chip (plus a password) in order to access a secure system. While this is a highly robust method of security, due to the requirement of both an actual device and password needed to be used to access a server or system, it mainly only works for organizations that have the infrastructure necessary to implement an extensive system such as this.

Transaction Authentication

Transaction authentication is a pretty straightforward security method. In essence, it boils down to this: If a transaction (via credit card or payment service) seems suspicious, the person making the transaction will be prompted to take extra steps in order to verify that they are indeed the person they claim to be.

While the idea of asking someone “Are you sure you are who you say you are?” Is a simple security measure to wrap your head around, the systems required to make that process possible are intricate and costly – and require a significant amount of investment in infrastructure.

This is largely due to the fact that you must first have significant amounts of data for each customer profile before you can start defining suspicious account activity, and then flagging errant transactions.

Multi-factor Authentication (MFA)

Multi-factor authentication simply means mixing two types of user authentication together into a single authentication process. For instance, the example we used for biometric authentication (requiring bio-data and a password) can be classified as MFA, or, our example of token authentication – requiring a user possess both a device and password.

Out-of-band Authentication (OOB)

Out-of-band authentication validates login requests by requiring the user to provide information that can only be accessed by a device different from the one they are currently using to log on. For example:

When you login to your car insurance website, but before you do, you receive a text message containing an access code that is only valid for a limited amount of time. You then enter that code into the website, and you finish the login process.

This is a method of security that has a very applicable use case for an app that needs a high degree of security.

The costs of not using secure login authentication

First, it’s important to get one thing clear – if your app doesn’t make use of sensitive or highly personal information, go ahead with SSO. There are options you can take to implement extra layers of security on the initial login authentication.

If your app does make use of sensitive info, however, it’s vitally important to your user retention, brand equity, and business in general to use the highest levels of security. When comparing the cost of $10,000 to the cost a negative user review and rating can do to your app’s ranking, it’s definitely worth the upfront cost.

A perfect example of this is what happened to Facebook and its reputation after the Cambridge Analytica scandal; 1 in 10 American users deleted their actual profile, and 26% of American users deleted Facebook’s app from their devices.

Their brand is irreparably ruined in the eyes of some of its former customers – 15% of users who responded to a survey conducted by market intelligence firm Creative Strategies and Techpinions said there was nothing Facebook could do to regain their trust.

This was the response to a social media company’s mishandling of user data – now just imagine what the fallout would be if your sensitive-data-based app mishandled users’ personal information.

Context is key

When budgeting for a login feature with your mobile app, it all comes down to how secure your app needs to be. Basic user authentication can be implemented for as little as $100, and IPSec can reach the realm of $10,000.

How much does it cost to implement backend CRM software?

/0 Comments/in , /by

Continuing with our quest to provide you with the most comprehensive answer to the question: how much does it cost to make an app?, it’s our next addition to the fray – and this time, we’re going over the cost of backend CRM (Customer Relationship Management) integration.

There’s the usual simple answer (that really doesn’t answer anything): it depends on the complexity of the CRM software and the mobile app that goes with it.

There’s also two different options, both of which come with widely differing upfront and lifetime costs and value:

  1. Purchasing (and then implementing) a third party CRM API = low upfront cost, high lifetime cost, low lifetime value
  2. Building your own custom CRM software, and then integrating it with the backend of your internal app = high upfront cost, medium lifetime cost, high lifetime value

If you want to go the third-party API route, the answer ultimately comes down to the SaaS provider you chose to go with. Going the custom CRM software route, will, in the long run, save you both time and money.

Before we get into the reasons as to why, we’re going to cover the basics of the functionalities a CRM software can provide – so when you’re planning out your own internal business app’s development (and the backend integration of its sister CRM software), you’ll know what to expect.

CRM software functionality

CRM software is designed with the intention of providing a hub for every aspect of managing your business’ relationships with its customers:

  • Management of: Contacts, leads, prospects, affiliates, and partners
    • Customer data: Storage and processing
  • Customer profiles: Personal data, contact information, history of past purchases
  • Process automation: Syncing communications, automating reports as well as email (and sometimes text) marketing efforts

Let’s go over the features that make those functionalities possible.

Lead management

Keeping track of leads is crucial in today’s market – and it’s no longer only large corporations that deal with high volumes of clients – small business must compete at a global scale in order to keep up.

One of the most practical methods to increasing customer loyalty is to develop and maintain a personal connection with every customer – from their initial point of contact with your business onwards. In order to effectively accomplish this standard, lead management is a necessary and effective tool.

By using the lead management functionality CRM software provides, not only can you disseminate leads to the right people, you can automate your mid funnel processes; such as marketing and remarketing campaigns that utilize email or text campaigns that serve to keep customers engaged with your business, thereby creating (and increasing) lead generation.

A perfect example of the efficiency CRM software provides is the automation of leads’ contact information – when a client fills out their info on your website, it’s then added to their customer profile in your database.

When your sales team adds contact information to a customer profile from a lead they just created, the data ends up in the same place. Not only does this make it impossible to lose or duplicate information, it means that if a sales representative is no longer with your company, the lead’s info stays within your database – not on their personal phone.

Process Management

When was the meeting with David? No, the other David. You know – the one with the on-demand dog walking app?

CRM mitigates the wasted minutes in those kinds of conversations. If an account representative schedules a call with David-the-dog-walker, your account manager will know as well, because all the information David and his business can be found in the same place – his client profile in your CRM software.

Assigning tasks, scheduling meetings, making sure follow-up emails are sent, and phone calls are placed is simple when it’s automated. You can even set up automatic notifications to make sure no task is left by the wayside.

Speaking of keeping everything in the same place, let’s move on to…

CRM Dashboard capabilities

Everyone loves a good dashboard – and with CRM software, you can create customized dashboards for each facet of your operations – from sales and marketing to service automation and even accounting.

Dashboards are the perfect tool for helping your employees understand the big picture, the pieces and processes that make it up, and their role in your business’ operations as a whole. They’re also excellent more mobile devices, as they are the quickest way to find information on a smaller screen.

Auto-generated reports and invoicing

There’s not much to say here, other than CRM software will put the “I want those reports on my desk by 5,” cliche to rest. Instead of spending countless hours tracking down and then organizing information, you can just click a button.

There’s nothing quite as inefficient as spending money to fill and send out invoices. The time and money spent on filling out documents that are, by their very nature, asking customers for money is one of the more catch-22 moments in everyday business life. Just like reports, filling out invoices is a thing of the past with CRM software. The program already knows who bought what, where it’s going, and who’s receiving it.

Lead Scoring

Knowing who to go after at the right time is a skill business developers must hone over years of professional development. CRM software can be used to automatically track and score the engagement of your users, and then update their profiles with their current score.

With a system that can quickly analyze and interpret vast amounts of data and interactions, you can better measure your leads’ online behavior, email and social engagement, and any other channels you use to engage with customers.

Wrap all that up in an app

The best part is that all of those functionalities can be packed into a mobile app – through integrating your CRM software with your internal business app’s backend. This means that when your employees are away from their desks, out in the field, or serve a roll that keeps them on their feet, you can still make sure they’re in the know.

This doesn’t mean replacing your CRM software with an app – merely that it’s just as accessible and useful when your employees are in situations that require them to be away from their desk.

The cost of implementing CRM software with a mobile app

Funnily enough, the cost of implementing your CRM software with a mobile app is a pretty low cost- your custom CRM software is basically it’s own API, so it comes down to how much time it takes to connect the endpoints with the backend logic of your app. A typical rate to do this would range from $75 to $125 per hour.

The true cost of implementing CRM software with an app is the actual development of the CRM software itself – building out a CRM system with the features listed above is a process that typically takes (at least) a few years.

The time it takes to develop is inexorably tied to the scale and complexity of the needs of your company – which usually means the greater your need for CRM software, the higher the cost to develop. The upfront cost to begin development of custom CRM software can range (again, depending on complexity) from $50,000 to $75,000. Over the course of a few years of development, costs can range from $175,000 (for a simple CRM system), and $250,000 – $500,000 for a complex one.

Those are high numbers – but consider the longterm costs of continuously paying for a third party CRM software; when looking at the most popular CRM SaaS provider, the option with the most functionality is $300 per user per month. If you have 25 users, that means $7,500 per month, or $90,000 in one year.

So, even if your custom CRM system cost $500,000 to develop, that cost is basically paid for after five years. In regards to the long term cost, the custom CRM software will win every time. Not only does custom-built CRM software have a lower lifetime cost, it also comes with a better value – since it’s custom, it’s made to specifically improve your processes, not business practices in general. This makes your employees who use it even more efficient with their time, which leads to happier customers, and more sales.

How much does it cost to implement wearables?

/0 Comments/in , /by

Just how much does it cost to implement wearable technology with your app? We have the answer, but before we get into it, let’s look into where the wearable market is today, and how it got there.

A brief history of the future

If there’s one burgeoning technology that has “future” written all over it, it’s wearable tech. From 2010 to about 2015, there seemed to be a contraction in the evolution of different types of consumer-facing hardware – sure, there were many different devices being created, but they all generally fit into the category of “thing with a screen.”

A smartphone is a smaller tablet. A tablet is a laptop without a keyboard (unless you’re talking about Microsoft’s Surface), and a laptop is a portable desktop computer. All of these devices were made to basically function (other than inputs) in the same manner – and during this time, innovation was based around making devices smaller, and more portable.

Mp3 players were abandoned in favor of iPods. iPods were abandoned and replaced with iPhones or Android devices.

The first wearable devices, like the FitBit, were a continuation of this trend – take a screen, make it smaller, and put it on a device. There was one important distinction with this device, however – unlike smartphones, tablets, and laptops (which all accomplish the same tasks), the original FitBit only did two things – it kept track of your daily steps, and how much time you spent sleeping.

This was in 2009 – two years after the first iPhone was released, and during the time period mobile devices were focused on adding features, not purposely limiting them.

The power of wearables isn’t their ability to do everything, however – it’s their ability to do a small range of things very well. When it comes to keeping track of steps, wearing an unobtrusive device that you don’t need to interact with is a much better user experience than taking out a phone, opening an app, waiting for it to load, starting your step counter…

What’s less distracting when you go for a run – a smartphone bigger than your hand, or a device you can wear on your wrist?

So what does a watch that keeps track of your heartbeat, steps, and sleep cycle have to do with the future? It’s because this is just the beginning.

The wearable hardware market

Smartwatches and fitness trackers – the two types of devices that immediately come to mind when the subject of wearable tech is brought up.

For good reason to – the vast majority of wearable devices sold have been Apple’s AppleWatch, which sold 1 million units in one day on its initial launch in 2014. Since then, there’s been steady, incremental improvements to smartwatches, like battery life and screen resolution. When WatchOS 2.0 came out, and apps began to run natively on AppleWatches without the help of a companion smart phone, the benefit of smartwatches began to come apparent.

Wearable tech’s association with fitness isn’t unfounded either – the fitness and sport segment of the wearable market accounts for 39% of the market share. Speaking of market share – the wearable market, while new, isn’t small at all – in the U.S. alone, there were 38 million users of wearable tech by 2018.

The truly exciting aspect of these numbers is their potential – with AR-specific products already on their way to market this year, like Microsoft’s HoloLens2, the growth and innovation the wearables market will experience will most likely be staggering – in both economic growth, and impact on society. In the U.S. market, 21% of consumers have stated they are “very likely” to purchase a piece of wearable tech like a smartwatch. With AR, VR, and MxR on the horizon, this statistic will only increase.

Just take a look at this piece from TIME about the future of wearable tech – smart clothes that provide tactile feedback paired with GPS navigation, shoes that charge your other wearable devices by utilizing the energy from your movements, and GPS enabled shirt buttons that can call 911 when you’re in danger.

The wearable software market

There are three main industries focused on expanding their markets via wearable devices:

  • Fitness and Wellness
  • Healthcare
  • Defense

Both the fitness and healthcare industries are expanding into wearables for obvious reasons – defense contractors and the DOD, however, are more interested in the application of VR and AR technology.

The healthcare industry is expected to monitor the health of an estimated 5 million patients by 2023, driving $60 billion in spending on wearable tech. The Department of Defense is expected to spend nearly $11 billion on VR wearable tech by 2022 – while that’s a hefty price tag, the amount of time and money saved in training soldiers is a much higher number.

While wearable tech will most likely never fully replace smartphones and laptops, they will undoubtably enhance the experiences they provide to users. That’s why it’s important to make sure the pain point your wearable app solves is even more targeted than a standard mobile app.

Despite many pieces of wearable tech providing the hardware layer for native, standalone apps that run independently without the help of the cloud or another piece of technology, most apps that live on wearables (especially smartwatches) are supplemental additions to an already existing app.

So, how much does it cost to implement wearables?

Luckily, developing a wearable app isn’t much different than developing for iOS or Android – there’s just a few tweaks here and there. AppleWatch apps are programmed using Xcode and Swift, just like all iOS apps, and Android Wear apps are programmed using the usual suspects – JAVA and C++.

Let’s pretend that we were going to make a wearable app for Brew Trader – it’s an app that gives users the ability to find and trade craft beer with other beer enthusiasts nearby, which they can find on a map, or through searching for a specific beer.

Let’s say the wearable app we’re developing is going to be used to supplement the process of communicating with other users – currently, users are sent a notification when they have a trade request. In order to optimize the interpersonal communication between users, and lessen the time a request spends in limbo, we decided to build out a wearable app that alerts the user about any trade requests, or responses to their own requests.

What would this require?

First, we would need to build out the UI for the wearable app – the parameters of which rely on a set of factors such as the screen shape (for smartwatches: rectangular, or circular) and model of wearable device (AppleWatch vs. Android Wear). If we wanted Brew Trader to be available for both Apple’s and Android’s wearable devices, we’d need to develop native apps for both.

The interfaces of smartwatches use different inputs and design hierarchy than mobile apps, so while it’s important to keep the styles of your app similar, it’s just as important to not reuse UI elements – you’ll end up going back to re-design them anyway.

Second, we’d connect the wearable app to the mobile app using the cloud, as well as connecting the wearable app itself to the backend database Brew Trader uses to keep track of trade requests, user profiles, and user DMs.

Third, we’d use an analytics platform like Kumulos to create segmented push notifications that alert users to trade requests, responses, and DMs.

Fourth, we’d implement the new code into Brew Trader’s code base, and add the new smartwatch functionality as an update to the already existing app.

And when it comes to implementing a wearable app into an already existing app, that’s really all there is to it. Something that’s very much worth noting – if the only thing you want to achieve by implementing a wearable app into your already existent app are push notifications (and the push notifications don’t rely on data from the mobile version), there’s virtually no extra cost. All smartwatches can display the push notifications of an app, regardless if it’s a mobile or wearable app in question.

If you want to build a wearable app from the ground up, it’ll largely be the same cost and process as normally developing a mobile app. One thing we will recommend here is to directly contact the company that designs the hardware you’re planning to develop for. The wearable industry is still very plastic, so UI/UX standards aren’t set in stone, and users are still very willing to learn new ways to interact with wearable devices. As a developer, you can actually influence the development of hardware to include physical features or processing capabilities your app would need to function. This isn’t an opportunity developers have very often, and the window to do so will soon be coming to a close.