Your backend is your app’s best friend. Don’t let it fail.

When we think of the mobile user experience, we tend to visualize the front end of a mobile application, whether it be finding ourselves on a map or playing with angry flying birds.

Meanwhile, the back-end servers and platforms that run our apps just don’t as easily jump to mind. What I have found over interactions with thousands of developers is that no one truly appreciates this hardworking back-end infrastructure and what it takes to run it effectively, until the moment it doesn’t work the way you expected.

Unfortunately, the most amazing front-end UI work will fall over if something in the supporting infrastructure breaks or simply stops working. And when a mobile app doesn’t work, users will avoid it.

Only 16 percent of users will try a failing app more than twice, according to one recent survey. Yet 62 percent of apps crashed, froze, or displayed an error in the six months between September 2012-March 2013. That’s a sobering statistic.

App failure comes with a steep price tag as well. The Royal Bank of Scotland had to pay its mobile customers £175 million in compensation and costs after the app failed for two million customers.

Amazon had to issue a public apology last Christmas Eve, when an Amazon Web Services outage caused Netflix to go down just in time for the holiday.

For businesses that rely heavily on delivering data to customers on an ongoing basis, such as e-commerce and telecommunications companies, downtime can cost up to $11,000 per minute, according to one recent study.

Time to harness the backend

Mobile apps pose a particular risk for breakage, because they are constantly pinging servers for information. This, along with more location and time dependent usage patterns, can create huge volumes of unpredictable traffic and sudden spikes in load. As a result, they strain your infrastructure more than more traditional web or desktop apps.

How can you ensure that your backend scales and performs continually, so that your app can continue to serve users regardless of load or demand? Here are some things for app owners to think about upfront to ensure their infrastructure is up to the task.


This is the ability to expand capacity as needed in an instantaneous and ideally an automated way. Theoretically, the technology exists to make your app spin up more instances on a private or the public cloud when needed. Practically, this isn’t simple to accomplish.

In order to achieve real elasticity, you need infrastructure that can simultaneously:

  • Spin up an extra instance of your application
  • Deploy all of the basic stack, code, and versioning you need for that instance
  • Deploy the application onto the new stack and instance with all needed components automatically and without human intervention

In order to do that, you need an application platform that supports it and ideally that works in both private and public cloud so you have choice and consistency in deployment.

A common application platform will enable you to run your apps on multiple infrastructures, whether in-house, on the cloud or both, and provide the automation you need for true turnkey elasticity.


Mobile apps today are released quickly and iterated frequently. In order to deliver apps effectively, you must embrace DevOps practices. Automate and streamline the dev, test, staging, and production environments, easily troubleshoot if something isn’t working and enable rapid turnaround of fixes or product enhancements without impacting quality.

This is a situation known as agile delivery, which I’ve written about in the past. It’s crucial to have an uncomplicated way to manage apps on back and front together within your infrastructure and easily roll app versions back to previous iterations as needed. Otherwise, you risk chaos, both on the development and ops side.

Analytics & insights

Many mobile apps today run on API-based RESTful/JSON Web services architectures. Because API calls go out to — and data comes in from — multiple back-end API calls, it’s hard to get visibility to whether all the different pieces are working as they should.

Also, if there’s a problem, it’s hard to track down the source. Which of your API calls isn’t delivering what it is supposed to? Where in the process of calling on multiple systems did your flow break? Which server or process is slowing your app’s response times down?

You need a way to gain insight and intelligence into what’s happening to deliver the full functionality of your app at any given time. Analytics can also help you see problems before users experience them. With each app connecting more and more devices, platforms, and APIs, it’s best to get acquainted with analytics sooner rather than later.

Appreciate the backend

Needless to say, the mobile user experience is dependent as much if not more on the back-end infrastructure you choose as the front end mobile user interface. My recommendation is to make it a priority to streamline the agile delivery process and monitor all of your application’s moving parts so you can support your desired flawless front-end user experience.

Andi Gutmans is CEO and co-founder of Zend Technologies. Founded in 1999, Zend was instrumental in establishing PHP. Today, Zend helps organizations create and implement back-end services for mobile and web applications. Zend Server and Zend Studio are deployed at more than 40,000 companies worldwide.

Original article published on VentureBeat

The following two tabs change content below.

    Andi Gutmans

    CEO and Co-founder at Zend Technologies
    • Jacob Fogg

      So true. We just deployed our first mobile App. We worked diligently on the back end, adding appropriate caching layers, streamlining execution paths, and employing layers of unit testing to help ensure back end stability. Simply turning off our caching layer causes the app to become annoyingly slow. Overall, our only missing piece now is the ability to spin up new servers… Plans are already in the works!

    • nidorx


    • Tim

      “Only 16 percent of users will try a failing app more than twice”
      So true, I’ve often noticed this behavior with myself…

    • David Stockton

      There’s just not enough time to deal with failing stuff. Apps, electronics, APIs etc. If you want to keep your customers, it’s critical to make sure it works and works well.

    • spabby

      Brings nothing new to the table really.

    • ctankersley

      This is something that I think a lot of developers don’t understand. Your application isn’t just a bunch of code, it’s an entire stack. You need to be able to keep up on them and make sure the whole package is working.

    • Aaron Saray

      I don’t think developers want to admit this, but we have pride… and ego. We want to be recognized for our hard work. There’s nothing more exhilarating than your best friend (non-programmer) or family actually liking, appreciating, and understanding your newest creation.

      But, normal people can only understand the front end. Try to get someone to understand async processing, queues, messaging systems, I dare you!

      So, combine the fact that normal people can’t understand the backend, the core of the product, and we want at least some recognition, we can sometimes spend way too much time on the front end. I think from time to time we say we really value UI/UX, so that’s why we dedicate ourselves to it. Isn’t it also just a tiny bit because we also want someone, really anyone, to see and understand why we’ve spent another 2 beautiful days in the office in front of computer screens?

      Personally, when I realized this in myself (and trust me, I’ve seen it in many, many other peers and team members I’ve mentored), I was able to focus more on making a secure and dependable backend. The stats are true – even if you have the most beautiful front end, if the back end fails, you’re toast. As another commentor said, applications are not components anymore, they’re a full stack.

      We must concentrate on the full stack. :)

    • Lonnie

      I think these are well known concepts, yet as I head out to do things on my phone, I constantly run into sites and applications that are horrid. Good to see folks laying out the whole picture for consideration to make it work properly.

    • Michelangelo van Dam

      I like this article for the focus they put on the architecture of applications. In my experience I see people start with prototypes and develop a back-end to match the requirements of the prototype (which is turning into the real product) and once they are live it’s scramble to keep the backend up and running.

      I often wonder why people accept the fact you need an architect to build a house, but for application development people are ignorant to that fact.

      Great post, thanks for sharing.

    • Cal Evans

      Good article, Andi. I’ve been referring to this mindset as API first (Backend first) for a while now. If you get your API and infrastructure correct the first time, everything else is a lot easier. :)


    • Faraz Ahmed

      Great post! I do the same thing with the apps I work on, i.e. Layout the API structure first before even thinking about how the front-end will look!

    • Daniel Rhodes

      An interesting introduction to the topic. Though it might be nice to mention some real-world examples of the desirables mentioned. For example the Amazon AWS stack for elasticity, Jenkins CI for agile DevOps.

    • Asgrim

      To echo many others, the back end is hugely important, and definitely worth investing in your API design. Make sure it’s scalable too of course – that way you’ve got a solid foundation for anything else – apps, whatever. Good read, Andi.

    • Sharon Levy

      This answers a question I had even before mobile apps were all the rage, what is more important to devise the front-end and then make the backend support it or create the backend and have a front-end that makes the info easily accessible to users. I also agree very much with the importance of an organized environment for agile delivery. You may get faster results in a chaotic environment, but if you value reliability and a quality product, the chaos must be tamed.

    • Lucas Maliszewski

      Not much to say but that I agree with the majority of what was said. The part of the server side “backend” is taking the blunt of the heavy lifting away from the users. Meaning rather than letting a browser chew through code, let the server handle all those delegations and let the users experiences be as burden free as possible.

    • Christian Wenz

      I believe analytics is the key point here. Knowing that “something went wrong” is a good start, but knowing what exactly went wrong (and finding out why) is paramount.

    • Jeremy

      Amazing how expensive even just a minute of downtime can be. Sort of explains why it makes sense to have proper power protection for equipment that you can’t afford to go down.