ReadWriteBuilders is a series of interviews with developers, designers and other architects of the programmable future.

On the surface, an app seems like a straightforward bit of software. It runs a game, or manages your digital notes, or performs any of the thousands of other tasks we routinely expect apps to handle.

But look behind the scenes, and things get really complex, really fast. Suppose an app stores your digital notes in the cloud, for instance, or offers to share your high scores on Facebook? App developers have to include code that manages those tasks—and every time that cloud storage service or social network updates its software, the app has to update, too.

It gets much worse if an app needs to work with multiple services. That original development and subsequent maintenance requires a lot of effort—especially for small developers, though it’s no small feat for enterprise teams, either.

Things would be a lot easier if a layer of “middleware” could handle those tasks, taking requests from an app and properly formatting them for the various “backend” services it needs to work with, and vice versa. Among other things, it would make app development much easier, since developers would only need to write their code to work with this middleware platform, and not with every individual backend service it intereacts with.

See also: The App Plumber: Parse’s Ilya Sukhar

A few years ago, several small companies saw a market opportunity and built “backend-as-a-service” middleware platforms to deal with it. Companies like Parse, StackMob, Kinvey, FeedHenry and several others have rushed to fill this void and make building backends—all those services that make an app run unseen by the user—easy.

I sat down with Sravish Sridhar, CEO and co-founder of Kinvey, one of the first startups to get into the whole backend-as-a-service sector. Kinvey is based in Boston and has been building the middleware that services backend systems since it was accepted to the Techstars startup accelerator program in 2011.

Building Middleware For The Mobile Era

ReadWrite: You guys started Kinvey from TechStars in 2011, end of 2010. What did you see in the mobile market that led you to create this thing you call backend as a service?

Sravish Sridhar: I think the basis of the company was quite straight forward. I just bet that there were all these phones that people were going to use at the time. And these phones are going to run apps of various kinds [with] tremendous kinds of fragmentation when it came to phones. Different operating systems, different versions.

And these apps are all going to need a back end, because they were going to be social, they were going to help people buy and sell things. They were going to be dynamic in terms of data. They were going to be location sensitive, and so if people had to build each of those back ends, for every app, that was going to take a lot of time.

The cloud platform was focusing on the infrastructure piece—nobody had thought about providing a full back-end stack of the box. For me, that was a big opportunity. If you could build a back end for all of these apps, you could be what Google is for search and what Facebook is for social … for mobile applications. I spoke to a lot of developers about it. They all agreed, [but] of course they didn’t believe me. They said it was impossible to do this. And I said what if I did it and gave you a service? They said, we’d use it. 

RW: What are the technical challenges of creating back end services for mobile?

SS: So for us the complexity of mobile versus the complexity of Web is different. In the world of Web in the early 2000s, when people started talking about things like Web architecture and Web services, they were trying to connect a disparate set of back end systems into a unified API. Each one of those back ends had different protocols. They had different APIs, different databases, different authentication.

In the world of mobile, that entire complexity is still there. And there’s two additional things. One, in addition to all the enterprise legacy systems, there’s also these new cloud services. Facebook’s API is different and Twitter and Google’s API is different. But there’s also complexity on the front end. Every [mobile] operating system is different. Every SDK to build apps in these operating systems are different.

Operating systems change versions every time, so things can break on the front end easily and things can break on the back end. So we look at this complexity as an hourglass. There’s all this complexity at the top, and complexity on the bottom and back-end-as-service is the glue that holds everything together.

Why Focus On Enterprise?

RW: The concept of backend-as-a-service started as a tool for developers. As it has evolved, it has taken on an enterprise IT bent. What is the difference between these two groups?

SS: There are some nuances, but it’s a fairly similar thesis. And the thesis was, in order for us to be successful, we have to build a developer community.

Unlike most popular mobile SDK tools, that leveraged an open source product [the way] Appcelerator leverages [the application framework] Titanium and Sencha leverages [the Javascript framework] Ext JS and so on, the back end as service companies did not jump on popular open source platforms. We built these companies and platforms from scratch.

And for us to become successful, the Phase 1 was we needed to build a developer community, not only to increase our brand presence and get people talking about the platform but also to background test what we were building.

Most of us knew that in order to scale the business from the revenue standpoint, we have to move into the enterprise, so in fact all of us end up doing it at the same time [in 2013]. And in the enterprise market, the problem is that they’ve got all of these disparate systems that they’ve custom built and purpose built for Web interfaces that now building mobile against it is really hard for them. 

And so the technology that every one of us has built it in the back end service space helps connect into these systems and mobilize them. And mobilize them means quickly and in an agile fashion building an API that is mobile-centric [for those] internal systems, and exposing that API via iOS or Android or Javascript to make it easy to build apps again. That was the natural progression. I’d be surprised if any of the CEOs of backend-as-service companies stood here and said they were looking to build a massive business via just individual developers. That’s a really hard thing to do. 

RW: What is the biggest problem facing app developers and building their apps, now and going forward?

SS: I’ll answer the question two ways. I think that for all the mobile developers in one group, I think the hardest challenge for them is the pace at which mobile operating systems and features in SDKs are maturing. Apple updates the SDKs on a regular basis, Android updates on a regular basis, OS version are getting updated.

Just to keep track of updates and publishing the apps and creating new versions of the app and deploying them out to a service, thats just a lot of work on an ongoing basis. I think that’s difficult to do, so the more processes that you can put in place to make that easier, the more tooling you put in place to make that easier.

For an individual developer, that’s why they use backend-as-a-service because that’s one less thing to deal with, they just rely on us for the entire backend.

Building In Boston

RW: You are a Boston company. What are the challenges of building in Boston versus New York or San Francisco or Austin?

SS: I’ve been so lucky to be building in Boston. I came here completely by accident by following my girlfriend at the time, wife now. We moved here and I had no clue that I would ever live in Boston.

I think especially building an infrastructure company in Boston, it comes naturally to the people here, and so when they realized what they can do with Kinvey, we had a great opportunity to work with great investors, we had really good talent, on the engineering, and sales, and marketing side, it was relatively easy for us to make progress in the early days.

The one struggle that we had being a Boston based company was getting the name out. Because at the end, like I said, all of us are trying to build these developer communities, and companies from the West Coast have it relatively easy, I’m not saying it’s easy for them either, but relatively easier to build a developer community than us.

And I think partly because from a DNA standpoint, no matter what business you’re starting, people in the West Coast are, in my opinion, more prone to be early adopters. They’re willing to give you the benefit of the doubt and sign up for a service and try it.

Optimizing Mobile For More Efficient Systems

RW: Simple, open ended question: What is the future of mobile? What are people building next? 

SS: I see apps that are available today in two forms. I see the long tail individual developer community or the startup community, people are thinking about really cool, innovative apps like games that you can do with friends, in a very social context. They’re really pushing the envelope on where can mobile go.

On the enterprise side it’s still mostly based on productivity. I have a device, how can I get content on the device to be more productive? I think what people haven’t figured out with mobile, is people haven’t effectively figured out with mobile, how to make money especially in the enterprise.

So for example, with beacon technology, I can make retail a much more interesting experience and potentially get more money. With sensors of different kinds, I can optimize my supply chain and reduce fat in my supply chain, and therefore reduce costs to my business. 

So what nobody has talked about in a big way, especially in the enterprise, is how is mobile going to help you raise revenue or cut prices? I think we are going to see more apps built that way. We’re going to move away from apps that just help sales people, the CRM, or documents and charts, to actually apps that are going to help you. That’s going to be the big thing. 

Lead image by Dan Rowinski for ReadWrite; laptop image by Madeleine Weiss for ReadWrite