Sealing Buy-In for Salesforce Mobile Apps with PoCs

Demand for sophisticated Salesforce mobile apps continues to rise. But any mobile project still needs to be approved, and pitching a mobile experience with UI mock-ups and PowerPoint slides won’t do your app justice. Whether you’re working internally or are a partner pitching to a client, a Proof of Concept (PoC) is a powerful way to demonstrate that an app can meet its requirements. This article will highlight the key benefits PoCs can bring, as well as examples and tips for maximising their impact.

Why bother with Proof of Concepts?

PoC applications are pivotal to any mobile app proposal, allowing the demonstration of fundamental concepts and principles. Including a PoC as part of a pitch is a great way to put something tangible literally in the hands of the decision makers. It’s an opportunity to reaffirm confidence to key stakeholders, particularly where critical technical requirements come into play.

 “The Proof of Concept system gives stakeholders a chance to understand the capabilities and limitations of the system.” - Anderson IT

A common scenario we’ve come across at MobileCaddy is the desire of our partners to reassure clients that fully network resilient mobile apps for Salesforce are possible. This example is also applicable to internal development teams working in larger organisations.

Our experience with offline-first architecture has proven this to be a grave concern for enterprises. As such, a PoC demonstrating exactly this functionality has been fundamental in progressing conversations beyond these sticking points, and further onto the real topic of how value can be gained from taking Salesforce operations mobile.

PoCs are also an ideal opportunity for mobile app owners to show creative solutions to the organisation’s challenges. Of some of the best PoCs I’ve seen, many include approaches to UI that have been implemented based solely on the skills of the developers and designers. Perhaps during earlier conversations it may have been hard to sell an idea to the decision makers through verbal conversations or flat UI mock-ups, but once implemented (even if partially), an idea has much more chance of being understood and agreed upon.


Demonstrating a PoC is also an opportune time to resolve ambiguities within the requirements, or to highlight areas of understanding or technicality that may need further analysis.

A working PoC can be physically placed in the hands of the key stakeholders, but it could also be made available to the wider leadership team, including those not present in the actual demonstration. This gives the end users a real example, time to explore the actual app, and even demonstrate it to other colleagues. The confidence and emotional triggers a stakeholder often gets from holding their own phone with an app running on it, sporting their own company logo, is something that can pay dividends when it comes to generating excitement for a project, and gaining buy-in for the application.

What to include in a PoC

 “Any POC without tangible business benefits available at the end is waste of time and money.”

- Matti Kinnunen, Chief Architect, Kuntarahoitus Oyj – Municipality Finance Plc

Here are some ideas worth thinking about including to make your PoC really stand out and achieve the best possible results.

Use branding

Incorporate the organisation’s logo and colour scheme throughout. This creates an emotional connection for the users and makes the app feel more ‘real’.

Where possible build branded installable apps (e.g. APK for Android, IPA for iOS). Having the logo on their iPhone home-screen, for example, not only provides them with something to take away and review later, but it’s another great tool for bringing a personal attachment to the PoC.

Cover important use cases

You don’t want to make the PoC too vast in scope. Doing so can dilute the aim of proving out core scenarios and functionality. Try to stick to one or two primary flows of work, like recording a site visit or converting a lead.

Make it relatable to the business

With all the above, try to make it as relevant as possible to the organisation itself. For example, if the intended team of end users have Salesforce Assets, but they have labelled it as Vehicles in their browser app, then do likewise in your mobile PoC.

Similarly, if the app will run primarily on iPads, build and demo for that device and screen resolution. Turning up with an app running on an Android phone won’t have the same impact.

Address areas of concern

PoCs should demonstrate feasibility of ideas and technical implementations. Where possible, try to address areas of concern, such as:

  • Offline data creation (e.g. master/detail creation, complex input validation, etc.)
  • Offline logic (be able to show how custom logic can be run locally)
  • Photo/audio capture
  • Geo-tagging
  • Salesforce community self-registration
  • Salesforce file handling and syncing

Include UI proposals

Try to demonstrate how the end application will enable the user’s critical processes. Use this opportunity to showcase how the app will be a tool to achieve genuine day-to-day tasks, rather than any day-to-day tasks having to include using the app. You want to show how the app will ease the user’s workflow, and how it enables and supports their work, rather than defines it.

Creating your Proof of Concept

How you go about creating a PoC will depend on your toolset, but whichever route you choose, the same factors will come into play. With the above in mind, here are some tools and assets that are worth investing in to speed up development of PoCs:

Kitchen Sink Applications

These are pre-built apps that contain wide-ranging functionality, from displaying accounts on a map, to full workflows for creating parent/child objects. ‘Kitchen Sink Apps’ could easily be cloned, stripped down, and skinned.

Using our MobileCaddy CLI, development teams from either partner or client organisations are able to start whole new mobile Salesforce application projects, specifying one of their Kitchen Sink Apps as a base point. The time saving here is phenomenal, and means developers can move straight into building out specifics for the current PoC, without needing to re-implement common features.

Starter Applications

Our Starter Applications are built to cover vertical and horizontal use cases, and have common functionalities and object handling implemented. As with Salesforce platform implementations, it’s very common to find similar use cases within different organisations in a vertical. We advise making Starter Apps focused on different form factors. Targeting a range of devices could save a lot of time in each PoC build.

As with the Kitchen Sink Apps, our partners’ or clients’ internal development teams can use the MobileCaddy CLI to also create projects based on any of the Starter Apps. The ability for our partners to also export or import application configuration and metadata at the platform level means the workload to mobilise common objects and set up other application configuration is greatly reduced as well.

Code codebooks

A cookbook can be extremely useful to refer to when specific technological scenarios need to be addressed. Our internal and external cookbooks are constantly growing as we come across interesting scenarios.

Add code snippets and Salesforce configuration examples to your cookbook whenever something comes along that has taken some time to solve. Of course if these features are to be commonplace, add them to your Kitchen Sink or Starter Apps. If not, storing them in your cookbook will ensure you’ll have the resources to hand for future projects.

The external MobileCaddy cookbook – used by ourselves and our partners – includes recipes on the following:

Container App build and deploy process

Container Apps are what we call the native piece of our MobileCaddy applications. These are the installable iOS, Android, or Windows Desktop files.

Building these Container Apps can be a time-consuming manual process. Automating these steps is a real timesaver, allowing you to focus on building out the value of the app through the business logic.


Likewise, having a means to share the applications to attendees of the demos (and farther afield) can be a great asset. Deploying Android APKs can be as simple as emailing them over and side-loading them, but for iOS you may need to make use of Test Flight, or iOS Enterprise Distribution, or similar.

We understand that the above can be arduous, especially for partners who don’t have a dedicated iOS or Android team, and that’s why we offer this service.

The long and the short of PoCs

Incorporating Proof of Concepts into your proposal will greatly increase the chances of gaining buy-in to mobilise the Salesforce platform. Through demonstrating technical feasibility, and producing a hands-on experience to pivotal stakeholders, not only do you provide confidence in the overall solution, but also create a sales aid that is directly relatable to the decision makers and the end users’ workflows. A PoC can be fundamental in drawing out ideas, and highlighting ambiguities in existing requirements, but most of all it can increase your likelihood of winning investment.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to Top