The simpler devices get, the more complex our jobs as developers becomes it seems.

When I first started my independent developer career way back in the dark ages of 2006, building an app usually meant building a desktop product that persisted data locally. In some cases there was an Internet backed service tied to it, but it wasn’t the norm. This was before Dropbox, people.

If you truly wanted Internet connected services, you built web apps. Using a mix of HTML, CSS and a sprinkling of Javascript you could build web pages that could replace your desktop apps with something that could run on any device and any browser.

Once mobile came on the scene, web apps weren’t as ‘sweet’ a solution as some would have liked us to believe. The pendulum swung back towards native app development, but with the added bonus of being network connected at all times.

For an app that connects to a third-party service such as Dropbox or Twitter, always-on connectivity means implementing a third-party API in your app and using that as the foundation for your data access. It’s a little more work than our desktop days, but certainly not that big of a hassle.

Fast forward to 2014 and you’re starting to see convergence of mobile and those web technologies. Mobile apps from smaller developers are starting to offer online services either as a value add (such as the wonderful Day One app) or as the foundation of the service (such as Glassboard or soon-to-be from Vesper).

Mobile apps requiring their own custom backend data isn’t new for many operations, especially those with a large staff and a bankroll of venture capital money to burn. For the mom-and-pop shops like Second Gear and Q Branch, it’s a whole new world that just became more feasible just recently.

So, what changed?

App Pricing And Expectations

When I released Photos+ last year, one of the biggest sources of feedback I received was “where is the iPad version?” Nevermind that I just spent several months perfecting the iPhone version, consumers expected that the app would be run on all their iOS devices.

Beyond just expecting your app to run on both an iPad and iPhone, users also expect that data to sync effortlessly between those devices.

Implementing that amount of functionality isn’t impossible, but at $2.99 per app or so it becomes really hard to make the economics work in your favor. If you can instead sell a service for a monthly or yearly fee, however, and then give the apps away for free it becomes a bit more feasible to make the economics work. Still difficult, but at least less of a crapshoot.

The Cloud!

Everything is in the magical Cloud now. All your files are on Dropbox. All your photos in Photo Stream. Everything else in Evernote.

Cloud computing has eliminated the need to be a sysadmin and host your own server hardware in favor of renting resources in the cloud. Amazon, Microsoft, and Google are the big three and are all jockeying to lay claim to all the CPU and storage on the web.

Glassboard runs on exclusively Microsoft Azure. All user data is encrypted and stored in Azure Table Storage. Images and videos live in Azure Blob Storage. The actual platform app itself runs on an Azure Cloud Service, which makes scaling as easy as adjusting a few sliders on the Azure web site.

Backend as a Service

Take the cloud computing paradigm, and simplify it even further and you get Backend as a Service. With a BaaS provider such as Parse, Google App Engine, or Azure Mobile Services, you don’t even have to worry about provisioning resources on the cloud. Instead you just import an API wrapper into your mobile app and configure a few cookie cutter options on the BaaS provider’s web site.

These providers make cloud-enabling your product incredibly simple. The tradeoff of using one versus the more traditional ‘cloud’ is that costs rise exponentially much quicker. It’s a tradeoff that many are willing to make, plus competition has made pricing a bit more competitive than it was even just a year ago.

The Parts of a Platform

We’ve accepted that running our own server-side resources is becoming a reality, we should analyze what that really means. And more importantly, understand what is involved.

1. The API

The brain of that powers any cloud-enabled service is its API. It doesn’t matter what language you write it in as long as its secure, stable, and reliable. Glassboard started out as a full C# product, but I’ve been rewriting parts of it in Node where it makes sense.

Most of the time your users won’t see your API firsthand, unless you offer it publicly as a value add to your customers. Whether it’s a public API or not, versioning from the start is always a good idea. You’ll inevitably get to the point where you want to add or change your API’s functionality. By versioning your API from the start, you can ensure that legacy clients aren’t immediately cut off as you improve your product.

If you’re running a marginally successful service on an API, it’s worth your financial and time investment to look into services like New Relic and Runscope. New Relic does magic things to figure out bottlenecks and other slowdowns in your API clients. Runscope is an API monitoring service that lets you test the health of your API as you run a suite of tests against it.

2. The App(s)

Whether its iOS, Android, Windows Phone, or OS X, the app is the nut of any platform. It’s what your consumers will predominantly use to interface with your service and will shape their opinion on it.

This is likely going to be where most of your time is spent, assuming you want to build something that stands out in such a crowded market. There are plenty of hybrid app solutions that can get you on all platforms quickly, but quick doesn’t necessarily mean quality.

Glassboard has native Android and iOS clients. Each one is built using the system-specific APIs and designed to look and behave like a first class citizen on their respective platform. It’s far more work (and cost) than the hybrid approach, but I believe a better app experience in turn leads to a better conversion rate to paying customers of the service.

3. The Management Backend

This is the one most people forget. Once you’ve developed your API and built the app(s) to consume it, you likely have a user base that is going to be emailing in support requests and bug reports. Those requests likely mean you need to look into the data stored on your backend.

You aren’t an animal. Running raw SQL queries from the Terminal is neither safe, nor ideal. You need yet another app for your platform. The only difference is that this one is for internal use only.

The admin portal is the piece that most developers forget about until after they’ve shipped, but it can also be one of the most important part of your product once you reach a level of success. Let’s imagine you outsource your support to a third-party company (I recommend and use AptFolk). Ash and crew are a smart group, but they don’t know the internals of your product or how to connect to your servers. Nor should they need to. By offering a web or mobile app that allows them to look up and adjust account information or whatever else is relevant, you’re making your job easier.

Beyond just support, metrics are essential to measuring success or failure. There are simple vanity metrics that are useful for showing on an app like Status Board:

Daily signups

Active users

[Your Specific Data] created

Daily/Weekly/Monthly Revenue

For more advanced metrics, I recommend a third-party provider that specializes in things like customer segmentation, funnels, and other more advanced functionality. I use Localytics, but I’m actively shopping for an alternative. Mixpanel is also a nice service, but gets expensive real quick.

Every Piece Matters

The good news is that even though our jobs as app developers is becoming more all-consuming, the tools that enable us to do this are becoming far easier to use. I couldn’t imagine running my own servers back in 2008, and now I don’t have to. Cloud computing takes care of the heavy lifting and let’s me focus on the product itself.

Just because I don’t have to worry about imaging and provisioning servers doesn’t mean I can slack on other parts of my product’s development cycle. The API, apps, and backend platform are all equally important pieces of the puzzle that defines your product. The app may be the only public facing one, but without the API it doesn’t exist. Without the backend management portal, supporting your user base becomes a nightmare that impedes development.

Treat each piece of your product’s stack like it’s the most important, user facing portion bit. Quality isn’t just mean for the surface.

The Full Stack App Developer

Whenever I look at job boards, I notice that a lot of web development jobs are wanting someone who is a ‘full stack’ web developer. To me, that means someone who can build the front end of the application using HTML, CSS, and Javascript as well as the backend using whatever server-side framework is in there. To top it off, sprinkle in a bit of knowledge on cloud computing.

The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.

Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.