App Map

App Map

Not to be too much of a downer here, but you aren’t psychic.

Since you are not psychic, you will have to communicate your app idea to others using words and pictures. You are going to need an App Map.

Your App Map is a way for you to visualize the different features and how they connect.  It shows others what you want your app to do and why.

There are a lot of different ways to plan your app: App Map is ours.

Step 1: Problems and Solutions

Too many apps are a solution without a problem or have a solution that doesn’t match the problem.  Having a clear vision of the why and what of your app prevents this.

Get some stickies and/or some 3 x 5 note cards and painters tape.  This allows you to have a way of re-arranging ideas quickly.

Get a nice big patch of empty wall or window that you can use as your workspace.  It helps if you have a space that isn’t on the same wall as doors that open to the outside or are in rooms that lots of people travel through.  You don’t want things flying off the walls and getting rearranged unintentionally.

To begin, write on a large piece of paper the problem your app is trying to solve and tape that high on the wall.  Next to that write how your app will solve it.   Write big enough that you will be able to read it both from a distance and in a picture later.

For example, if you were making a traffic navigation app, your problem might be: There are no navigation apps that show how to get to places using only even numbered streets.   Your solution would be: app will display directions between locations using only even numbered streets.

Do you see what we did there?

There is a clear problem statement. 

The solution solves the problem.  

The solution is directly related to the problem.

Next, you are going to write out the main things that the app will do in a row. Below each of those things a lot of additional things need to happen.  For our pretend map app, which we’ve decided to call Even Streets, it might look like this:

    • Identify even numbered streets on a map
    • Give directions list
    • Show map of directions
    • Audio cues for directions
    • Show traffic jams and accident

Below each of those things a lot of additional things need to happen.

Identify even numbered streets on a map

    • Have a map
    • Highlight even numbered streets in green
    • Show all other streets as grey lines

Give directions list

    • Show every turn on route
    • Show every street on route
    • Show distances traveled on each street
    • Show the name of each street
    • Be able to slide between list and map picture

Show map of directions

    • show map with route highlighted in blue
    • Have arrows pointing in which direction the person should go
    • Map can be made larger or smaller by pinching screen
    • Be able to slide between list and map picture

Audio cues for directions

    • A bell tone will sound when a person gets within 100 feet of a turn
    • A voice will read directions when a person gets 90 feet from a turn
    • Voice will state what next turn or direction is after a turn has been made
    • Voice will report if there is an accident or traffic jam
    • An alarm tone will sound when the app picks up the signal of a traffic jam or accident report
    • Voice will announce re routing when it occurs

Show traffic jams and accidents

    • Traffic jams and accidents will be shown in red

Re route when a wrong turn is taken

    • Show a new route when a wrong turn is taken to get back to even numbered streets as quickly as possible.
    • Show new route on both map and directions list.



    • How much map should be shown on the screen as a default map size?
    • What is the maximum and minimum map size?
    • Is it a male or female voice?
    • What kind of tone?
    • Can you select the tone type?
    • Can you silence the tone and keep the voice?
    • Can you silence the voice and keep the tone?
    • Can you mute both the voice and the tone?
    • What constitutes a traffic jam?
    • How much slower than traffic usually goes does it need to be for a jam?
    • Where are you getting the traffic and accident data from?

See how this can get complicated?  How will each item work?  And then what?  Ask, “And then what?” until you’ve got no more what.

Step 2:  User Stories

Next, we are going to make “user stories.”  User stories are a way to explain in a single sentence the relevance and need for each feature.  If a feature is not relevant or needed, cut it.   This is really hard when there are things that are super cool but serve no purpose.  Even if you waaaaaant it, how much money are you willing to pay for something that doesn’t really do anything?

To come up with the stories you are going to play a game of Let’s Pretend.  You are going to pretend to be:

    • An app User
    • A Developer
    • An Administrator/Business Owner

You are going to create user stories for each role, with at least one user story on each feature.  You are going to come up with statements that follow this formula:

As a ________, I want  ____________, so that I can ____________.

As a User, I want the app to alert me with a tone prior to a turn so that I can be prepared to make it by being in the correct lane.

As a Developer, I want to know the parameters for a traffic jam so that I can set them.

As an Administrator… wait a minute, what if there isn’t anything on the map that an administrator would want? Maybe you should think about that. What would you want/need to know as the app Administrator?  What functions would help you measure and improve performance?  What do you need to be able to bill/make money off of the app?

Step 3: Narrowing it Down to MVP

Now that you’ve played this game of Let’s Pretend and gotten your user stories up, your App Map should look pretty full.  You’ve probably had to move and expand it a couple of times.

Take enough pictures to clearly show each of the parts of the app so that you could clearly read what is written on each post it/card.

What you’ve got on your wall is a fantasy.  It’s what you would do if you had unlimited funds to spend on getting your app made.  You aren’t going to get the fantasy.  Or, as one of our clients once said, “I feel like you’re telling me I’m not going to marry a supermodel.” Guess what, you’re not.  But that’s ok.

Every single post-it/note card on that wall represents money.  Money gets wasted when features (that’s the stuff on the post its/note cards) turn out to not be the ones the app needs to be successful.

How can you possibly know which ones will be successful?  You don’t.  You’re going to want to test it out a little bit at a time.  You’re going to start your app with the smallest possible piece of it that you can make.  The most bare bones skeleton of an app.

What is the one thing that if your app doesn’t have this, it can’t exist?

What is the feature that best solves that problem?

Once you’ve identified the core functions-your first release- of the app, pull those to the far right or left of your wall.  Put a piece of tape between it and the rest of the feature sets.  Take a picture.  It is your Minimum Viable Product (MVP).

Let’s say that by some miracle the first release of your app was profitable.  You would use the money you made in your initial release to fund a second round of features and improvements.  The money you made in your second release then will fund the third, and so on.  What would your first release be?   Group those portions of your App Map and take pictures of them.

Really Do It

There is no App Fairy.  Your app will not magically come together just because you clap your hands and believe.  The more you’ve thought your app through before you go to a developer, the clearer you can communicate that process, the better your chances are of actually getting the product you both want and need.

This seems very simple, but like most simple things, it is crushingly hard.  Don’t give up, do it anyway.

Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

Three Tools to Make Your MVP Faster, More Flexible, and at a Lower Cost

This most efficient business solution to manage risk is a Minimum Viable Product (MVP). At Salty Dog Technology we create MVP’s to test the basic functionality needed to verify solutions.

Having a MVP that includes a back-end amplifies risk beyond a stand-alone architecture. These risks fall into three common categories: cost, time and flexibility.

Cost matters.  An MVP’s costs can spiral if the back-end implementation is expensive operate or takes a lot of hours to build. Though not in plain sight, the server’s cost should not be underestimated.

Time matters.  If you go the route of building everything from scratch, it can take longer, be more error prone and require more testing. There is a lot of “plumbing” that needs to be implemented in that case.  You can miss product release goals if this is not taken into account when making development schedules.

Flexibility matters.  Building a back-end from scratch requires finding or creating a bunch of scaffolding functionality. If you use a 3rd party framework, then you bring its baggage along, which may be more trouble than it’s worth. All frameworks are built with assumptions that may, or may not be ideal for your app’s back-end. A back-end implementation that cannot easily change will incur higher costs and take more time.

There are some 3rd party back-end services you can try such as Facebook’s defunct and now open-sourced Parse Server, or Google’s Firebase. They have a vested interest in locking you into their service and libraries, and often they have tiered pricing which may not reflect your usage. This means that you may end up having to pay a lot more and have less ability to change.


A Middle Solution


At Salty Dog, we use a strategy that combines three Microsoft programs: Azure Functions, Azure DocumentDB and Xamarin.

Azure Functions:  Azure  Functions are a way of providing server functionality without actually having to create a server. You are charged for the resources when they are used, as opposed to a virtual machine which incurs ongoing costs independent of actual usage.

Azure functions are not tied to single computational resources. The more that your Azure functions are accessed, the more computational resources will be automatically applied. This allows the Azure functions smoothly scale according to application needs.

Azure functions provide a rich programming environment where the functionality can be implemented in a number of languages including C #, PHP, JavaScript, Python and others.  They can utilize third-party libraries to provide extra functionality, as well as access external resources such as databases and messaging infrastructures.

DocumentDB:   DocumentDB is a server-less, schema-less JSON document database. Document DB stores the data in hierarchical JSON documents. They are indexable by primary and secondary keys. Like Azure Functions, it scales smoothly as your needs grow.

This means that time doesn’t have to be spent creating the schema, updating the schema, making sure that all data passed conforms to the structure. All of those things take time. Purists would argue that those up-front definitions provide a higher level of quality, and they’re right. However, that purity and build-in checking comes at a cost that isn’t necessary with an MVP.

Azure provides is an SQL interface to DocumentDB that understands some aspects of JavaScript syntax. This gives you a known query language that can leverage Javascript data aspects.

Xamarin:  Xamarin provides a set of tools to build Android, iOS, and Mac OS apps using C#. Rather than writing in Java, Objective-C or Swift, you write in C#. It is compatible with a lot of existing .Net libraries that can be used directly in the applications.

There are multiple ways to use similar functionality across the platforms in a generic way. Typically this is done using an IoC or Inversion of Control, system.  This means that someone can create a GPS widget that is used the same way, down to the API level, on both Android or iOS.  Below the surface, it accesses the specific native functionality on the device. This means the code you write doesn’t have to know if it is running on Android or iOS.

Xamarin has created a cross platform user interface library called Xamarin Forms. Xamarin Forms provides a usable lowest common denominator UI with the ability to customize and enhance it. For less fancy or performance sensitive applications, such as games, it can speed up development.


The Right Building Blocks


Together, the three tools provide a solution to the main risks we identified.

Cost is saved.  Infrastructure, routing, and boilerplate are built in. A lot of the “plumbing” is in place.  Azure Functions feels like you’re working with a bigger web framework, without sacrificing flexibility.

Pricing is relative to the actual time a particular function is performing work. If one month the Azure Function is only used for an hour demo, we will only be charged for that hour. Conversely, if the month after that, we put our app in the hands of 50 potential clients and they use it heavily, the infrastructure will smoothly scale to meet their demand without any intervention on our part.

Using Xamarin for mobile development, especially Xamarin Forms, enables code reuse, since the same piece of code may be able to run on either Android or iOS. Development will not be done twice as it would have been if building native apps.

Time is saved. Apps can be developed locally, unit tested, and put on the server using common source control methods, like Git and branching.  It isn’t necessary to continually upload to the servers and test. This makes it easy to add features, find bugs and fix them. When the code is ready changes are pushed to the right branch, and then Azure Functions will execute a pull from the control panel. This allows multiple live versions that correspond to production phases such as “beta” and “development,” or whatever makes sense for our product. With Xamarin, the app can be separated into distinct parts  for testing in isolation outside of a mobile device.  This can save time in the develop, test, and fix cycle.

Flexibility is saved.  Since the interface between the application and the web server is the well-known REST standard, your app isn’t locked in because of special libraries.




Creating MVP’s for mobile need not be time consuming or require huge infrastructure investments.  Using Azure Functions, Azure DocumentDB, and Xamarin allows code to be quickly developed, unit tested, and reused. Used in conjunction, they allow you to focus on the MVP and its refinement without worrying as much about cost, development time, and flexibility.

Minimum Viable Product- MVP

Minimum Viable Product- MVP

Minimum Viable Product (MVP) is a term frequently used, with an abundance of definitions, and is often poorly understood.

An MVP isn’t an incomplete product, it is the the MINIMUM product that will accomplish what you desire.  It is a whole, useful, and useable product. (more…)