A very interesting side discussion ensued at an iOS Meetup on mobile backend as a service (MBaaS) that I went to in Palo Alto, Calif., last month.

The topic: Should developers use a Backend as a Service (BaaS) or continue to code without a framework? And if you do choose a BaaS, which should you pick? And what can do you do to protect yourself if something goes wrong?

A quick background for those uninitiated in this new jargon. BaaS is a model for providing web and mobile app developers with a way to link their applications to ready-to-use backend services like storage, messaging, management, databases, and location.

This is an area that has exploded in the past couple years. According to MarketsandMarkets, the global BaaS market had an estimated value of $216.5 million in 2012 and is projected to grow to $7.7 billion by 2017.

But all backend services are not created equal. Some, like Parse, focus on consumer apps, while others, like Kinvey, focus on business apps. Some offer tons of services but not much depth in any one service. Others might offer only one or two services, like messaging from Urban Airship, but provide significant depth in those services they do offer.

Whatever can be developed with any of the BaaS platforms can also be developed without one. So why spend the time and resources integrating with any of them? There are three important reasons.

Time to market

I don’t know of a software project where time to market isn’t key. As competition increases, the need to deliver projects faster is becoming even more critical.

Imagine you have two weeks to deliver an application. Your choices are to develop fast using a BaaS platform or do it on your own, knowing that your application may slip by weeks or even months. So what should you do?

The answer really depends on the percentage time-to-market advantage. Typically, without a BaaS platform you’re looking at one year versus less than nine months with one in place. A general rule of thumb most developers tell me is that if they don’t gain at least a 25 percent time-to-market advantage, it’s not worth the additional resources. So certainly, the bigger the time advantage, the more beneficial it becomes to adopt a BaaS platform.

Reduce cost

Most applications suffer from budget crunch, whether it’s a large enterprise application or a consumer application that really needs to understand adoption before investing any additional resources. In the new world of delighting users, front end tends to cost more and more, thereby leaving less budget for the backend. So a BaaS platform becomes the only viable choice in a shrinking budget scenario.

Sure initial cost reduction and time-to-market are important, but total cost can be just as compelling. Consider the costs for initial development, plus testing and maintenance. A BaaS platform that offers better built-in testing tools may reduce your overall cost more, even if it costs slightly more upfront.

Expand skill set

Even if you don’t have all the skills required in your internal team, the product has to be completed and launched on time. This is where the right BaaS can really come in handy.

Imagine you’re developing an enterprise mobile application where you have to interface with your corporate SQL database sitting behind the firewall or in some private cloud. (Yes, it may be hard to fathom in Silicon Valley, but most corporate data still exists in SQL databases!). But your team doesn’t necessarily have deep expertise in SQL databases.

Selecting the right BaaS that offers depth in database services may be a better choice. The same is true of other skills, including authentication, messaging, and analytics.

Protecting your apps from the vagaries of BaaS

As with any fast-moving market, BaaS is quickly consolidating, first with Facebook buying Parse and now Paypal buying Stackmob. So far, however, the results have been mixed.

Parse continues to focus on developers, while Paypal ultimately discontinued Stackmob products, leaving developers rethinking their strategy. Stackmob users got only a couple of months to migrate — not exactly the happy ending many teams planned for. And consider the far-reaching impact for business-critical applications!

But even in the worst-case scenario, all is not lost — as long as you read that fine print. Those T&Cs can make or break your project. Before signing on the dotted line, ask vendors these questions:

  • Will the BaaS vendor spin an instance in the cloud of your choice so that you can continue to use the service even when the company goes away? Sure, you may be vulnerable if new bugs are exposed in the product and you may not get new features. But at least you will be able to extend the time for migrating your application if needed.
  • Will the BaaS vendor offer you an in-house appliance so that you can host it in your own data center? That way you can continue to run it even if the vendor has stopped delivering newer versions.

The truth is, there really is no simple answer to why and how to select a BaaS platform. And for the near future, expect the BaaS market to remain in flux, colored by lots of consolidation and uncertainty.

So before making your choice, spend the extra time evaluating your needs against the various features offered by any BaaS platform. Many can deliver lower time-to-market and overall cost and effectively expand your team’s skillset. But read that fine print and work with your vendor to make sure that you are protected – just in case.

R. Paul SinghR. Paul Singh is chief executive of Espresso Logic and has been founder and chief executive of many startups, including Veraz, Pixsense, and Internetware. For over 10 years, he has helped to pave the way for new mobile technologies, on both on the infrastructure and the application side. Paul is a board member of TiE Silicon Valley and was an entrepreneur in residence at Lightspeed Venture Partners before working for Sun, Telebit, and 3Com.

VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.