We help and guide many Businesses and Process Owners reduce wasted time and effort, by implementing our simple to use mobile applications.

These applications are designed to be simple to use and streamline processes that save you time, so you exceed your customers’ expectations for now and far into the future.


Customer Support

Need help? We are here to support you through the process. Click the link and open a ticket, ask a question or open an issue.


Sign up for our Webinars and get insights as to how we do things and how to use the software to it’s fullest potential.

Ask the Expert, Eric Dobbins

Have a question and would just like an answer? Ask it. The only Dumb question is one that wasn’t asked. This will need to go to a forum type page.

20 Questions You Need To Ask Before Making an App.

We’ve compiled a list of answers to common questions one needs to ask before taking on the app journey.

1. Can you summarize the Mobile App to me in just a few sentences?

This isn’t to catch the you or the customer off guard. It’s to really see how well you understand the “essence” of the app. The better you understand it, the more confident we can be that you will be very exact and focused about what the app needs to do, who it’s focused at, how you will use it etc.

2. Who are the target users?

What problem is your app going to solve for them? Why is a mobile app the best way to solve this? Could a mobile responsive website be just as good, or an even better way to solve the problem? What devices or platforms are they most likely to use?

3. What’s the real deadline? Is it linked to any other activity (a big product launch) or tied into a seasonal campaign?

So it’s usually the case that the project should have started yesterday.  But at least you can work out what’s possible with the time you have. Work back through multi-platform testing, development, and creative, ideas to set the expectation early on what’s practical and what’s not in the time you’ve been given.

4. What risks are there with the mobile app build? What are the outside dependencies that could affect the timescales?

Addressing this up front will save you a lot of problems further down the track. Building a Risk Register as part of the project kick-off and being disciplined to keep this up to date is a good idea, even for what seems to be a simple app product. Make sure that for each risk there are actions and owners responsible for managing down the risk of this affecting your successful app delivery.

5. What’s the budget?

The answer usually is, we don’t have a fixed idea of a budget. We want as much as we can get for as little as we need to pay. The truth is Mobile projects are really difficult to budget estimate but for us to scope the project, we need at least to work to a range. Defining the scope of work is also really important as it is not just about the physical build. Is there budget for researching the app, competitors, key functions that users will highly value that will guide us on what the MVP NEEDS to have for the app to be market ready? If it’s a new client it could become a tricky game of poker, neither side wanting to show their hand. But unless we get to a range pretty quickly expectation management is going to be tricky. If the client can’t give us a range, that could be a red flag, it may not be a serious project but just a vague idea they are trying to flesh out. We should also agree what the ongoing budget is going to be once the app is live. There will probably be hosting costs, ongoing optimization of the app on-boarding and in app use, discovery optimization as well as managing scaling out back-end systems as app user grows. We could decide to scale back costs on the initial  build and get the app to market quicker, then work with the app owner to continually improve the app over time.

You get an awesome app that’s just getting better and better. We build long term relationships with your clients.

6. Who are the key Stakeholders?

Is this who you are working with, or are their others that you need to know about? Who is the budget holder? Who is the Project Owner? Your contact, or someone else? What are the decision making stages? Who need to be consulted at what stage to move from Idea, to prototype, to build, to test, to release? Who are you going to work with post launch? Is there a formal process here (you should hope there is), or is this a more organic process.

7. What does success look like at each stage of the process?

Building this into a number of smaller phases, with approval “gates” we need to go through may sound bureaucratic and feels like it could slow us down, but it will, without doubt, save us time, money and a lot of anxiety through the mobile app build.

8. What are the business objectives for the mobile app? Is the mobile app an internal app to increase workforce efficiency? Is it there to open the product or service up to a new profile of user? Will it increase sales from existing customers?

All good, worthy reasons to build an app. Answers to this question will have a huge influence on how we build the app, what the core features and functions of the app, what platforms it needs to run on etc.

9. Who will the app compete with? Has the client done a detailed evaluation of competitors in the space that you can work from?

There may be no direct competitors doing EXACTLY the same thing, but that doesn’t mean that there aren’t other ways that people are solving the problem that they have. This shouldn’t be an App to App comparison. So ask the question, “How do the future users of our app currently solve this problem?” that way we’ll probably get a more insightful answer.

10. What design considerations/constraints does the Mobile App have to work within?

Are there corporate guidelines that the mobile app layout and screen designs need to conform to? Will this work on a mobile format? What scope is there to push back at the branding police to get some design latitude to let us do an awesome job?

11. Is there scope to have multiple releases?

This is both in terms of what native platforms you need to build on as well as functionality.

Is it possible to focus on a minimum viable product (MVP) as version 1 release,  with a feature roadmap? Does it have to be big bang with all features on all platforms day 1?

This may be desired, but is it REALLY a necessity. Even if you need to go Big Bang, it’s still good to work with the client to define and agree what the minimum viable product (MVP) NEEDS to be. That will help focus discussions around the budget and timescales for launch.

12. What is the backlog of functions for the app?

Even if you’re not using an agile software development approach to building the app, getting your clients to build a backlog of (non MVP features) is a very powerful way to get them to priorities between the essential functions of the app and those that are non-core for version 1 release. This has the other benefit of helping you plan future releases for the app, big for App Store discovery optimization and managing your future project work (and cash flow).

13. What are the underlying assumptions? Is it to work across tablets and mobiles? Can this be one version that resizes or do you need a build for both?  How back compatible does it have to be , iOS8 and later, Android 5.0? Android 4.0?. Does the app need to work offline? Will it have to connect with wearables or Internet of Things devices? What languages is the app going to be built in?

The answers you get to “Who are the target use of the app?” (No. 2)  will obviously have an influence here.

14. How is it going to be hosted?

Is there an existing infrastructure it needs to plug into? What are the security protocols? Are there any upstream micro-services that need (or would be good to) plug into the app? Is there going to be a website (mobile responsive of course) that will sit along-side the app and have to share user profile information etc.? Are there any other vendors that the app needs to integrate with (salesforce, SharePoint etc). How are you going to manage user generated content and what’s the expected upload/download shape of that content?

15. What are the data points that your client will need to get from the app?

Baking the measures, metrics and benchmark objectives into the mobile app at the design stage will help make sure that the mobile app build phase delivers against the key measures of success. If you don’t define the key metrics, that underpin the tangible measures of success for the app at outset, how will you focus the decision on MVP features? Also mapping out the analytics and metrics during the build will save the agony of trying to retro-fit these late in the day, or worse be duped into judging the success of the app based on what’s easy to measure, rather than what are actually the true measures of success.  Core to this should be measures of recency, frequency, duration & lifespan.

Clients want to know:

  • How many downloads?
  • On what platforms?
  • Ratio of push notifications activated?
  • How many that download are actually fully installing?
  • How many active users you have (is this growing)?
  • What features are being used the most?
  • Where are the dead areas of the app that need re-thought?
  • How frequently is the app being used?
  • For how long (use session length)?
  • How many transactions (sales) have completed?

Mapping the actual against expected, looking at the variance them working a plan to close the gap between actual and plan is what it’s all about. As long as these are defined up front of course. You’ve got a huge role to play here, and a huge opportunity to generate on going monthly recurring revenue from the initial app project to help the owner of the app optimize and improve the commercial performance of the app.


16. What is the monetization strategy for the app?

If it’s a B2E app, solving internal problems for a business to improve staff productivity, then there is still a money angle and a Return on Investment business case. If it’s designed to increase revenue for the business, how is it going to do that? In app purchases? Subscription model? Will features be unlocked with staged payment? Is a physical or virtual product being delivered after payment (so do you need logistic tracking)? Will there be in app advertising to monetize traffic through the app? Knowing this and building the app around the business goal will keep the client focused. Agreeing the MVP and building the Backlog of features acid testing each feature and function against the business goal will mean you’re focused on doing the important things in priority order.

17. How will they buy? Different from monetization. How do they physically pay for the product or service within the app, credit card, biometric payment (ApplePay and the like)?

Depending on the answer, you need to be thinking about security/encryption and device compatibility the app must work on.  So testing regimes, influence that Native vs Hybrid decision, security & data encryption etc.

18. Are there other apps that the client likes that can be used as inspiration for how this new app should look?

This isn’t about copying or plagiarizing someone else’s design, this is about using completely unrelated apps to help get you into the head of your client and understand how they are thinking. It’s easier if your following an already predefined UI/UX design and corporate guidelines, but it’s still important to do this, if only to help you decide how essential it is to build a native app so it accesses all the rich handset functionality.

19. How is the app going to be found when it’s ready to go live?

If it’s a B2E app, this may not be that important, but for B2B and B2C apps getting found in GooglePlay and theAppStore is going to be important to draw users to the app. Don’t think this is an afterthought. It’s not. You have to think of this at the design and development stage. Make sure it conforms to design guidelines of each store it’s listing in, if it doesn’t follow the rules its going to be tricky to get it listed.  You  also have to carefully think about future releases, this has a huge influence on discovery. An App that’s continually being developed will rank better in the store. Also make the icon impactful so it communicates the value and purpose of the app is really important.

20. What about post launch? What’s the ongoing plan to learn & improve? There needs to be one, right?

No matter how awesome you are as a mobile app development agency, you’re just not going to get everything right first time. You’re also probably not going to be able to deliver all the features your client wants, within the budget they have to spend and the timescale you’re presented with. The client’s going to be very very focused on the first delivery point, getting the mobile app live. That’s natural. But your job is to coach them to think longer term. Get them to think about the MVP, getting them to build the backlog gets them in the mind-set that this is an ongoing project.

The first phase is version 1 launch. This means you get them thinking early about the ongoing phases of releases as well as the promotion of the app.  Making sure that there is good data coming from the app is also critical. Using data & analytics to know how the app is performing and the recency, frequency, duration and lifespan is what your client had expected will help your client prioritize the remedial work that will be needed to get the app downloaded, used, and reused frequently

*Bonus* 21. What dependencies do we need to consider before we can get started with your new app?

It’s good if you can get the client to clearly tell you what needs to happen before they sign the work order and kick the project off. Do you need to run an ideation workshop (to make sure an app is actually what they need)? Does a purchase order need to be signed off by the budget-holder? Are you both covered by a Confidentiality & Non-Disclosure agreement? In short, what are the barriers to starting this project in the next hour?

Here are some of our customers/partners:

Apex InstallationH and K
Can’t find what you need? Our customer care team is here.
Open Support Ticket

DOWNLOAD OUR FREE ARTICLE: Myths & Facts of Field Service Solutions


We promise to keep your information safe. You can unsubscribe to our list anytime.