Mobile back-end consulting?

During a recent discussion with a friend (hi Brian) i had an epiphany. Well, actually it was just a series of realizations that should have been obvious long ago. The series was this:

  1. most mobile applications have a server component
  2. web services are the most obvious way of exposing server components to mobile applications
  3. therefore, mobile applications are just another flavor of semi-autonomous web service clients
  4. mobile applications are a growth space
  5. mobile application development skills are very different than good server-side development skills
  6. i know a lot about designing, and implementing, REST/HTTP web services to support semi-autonomous clients
  7. profit?

That last bullet really does come with a question mark instead of an exclamation. I really like designing web service APIs, and i am really good at it. I am just not sure there is enough of demand to make it worth focusing my career on that space. On the other hand, it feels like it might be a highly underserved niche.

I think that if i am to make a go of this it would have to be as an independent. It seems unlikely that a shop focused on mobile application development would be willing to add the fixed cost of a back-end developer in this economy. That would be a hard sell even to a shop that fully believed that an expertly designed API would pay of in reduced maintenance and lower costs of change over the long run.

So my questions to my readers (all three of you) are: a) Is this an idea worth pursuing? b) Do you know of anyone developing a mobile app that could use a skilled mobile app back-end developer? c) Do i want to go out on my own right now?

3 thoughts on “Mobile back-end consulting?

  1. I think you might need to consider your point #3 some more: if mobile apps are “just another” client, how much more value can you add to the development?

    Also, REST/HTTP has many kinds of awesomeness, but bandwidth friendliness is not typically one of them. Consider that many bandwidth constrained apps do things like send single bytes with the bits inside flipped as flags vs what bandwidth would be sucked up by running through the whole HTTP stack.

    I’m not trying to be pessimistic so much as just suggesting that you really need to articulate the expertise and benefit you could bring to a mobile > backend development above and beyond any other fat client > backend situation.



  2. Michael, thanks for the feed back.

    I have plans for some posts articulating what I have found is important when developing APIs for mobile applications. They do have some limitations (e.g. they generally suffer from high latencies) that need to be taken into account but in many ways they are not particularly special (e.g. bandwidth is usually pretty reasonable).

    On the other hand, judging from the set of APIs on the internet today, the number of people that can actually design an decent API seems to be vanishing small. For mobile applications it is particularly important that APIs be well designed because of the limitations of the devices and the fact that once you release a version of the app that version will never go away.

  3. You can develop an elegant, powerful API for mobile applications and attempt to sell it. I’ve tried something similar a couple of times. The Object-Oriented Project Size Estimation tool, Oopsize, written in Java, produces time estimates for the development of oo objects. We formed a company, put up a Web site, advertised, and wound up selling a single copy. We closed the company. Further down the road, I developed the Mathematical Server Sizing tool and published an article in IEEE “Computer” describing the mathematics of the tool. Once again, after a couple of years, it became clear that no one was going to buy the tool from me, even though the idea of the tool showed great utility. Today, the tool is freely available on Source Forge and I have like 800 users worldwide.

    I doubt that you can develop a viable program product on your own. Even if your idea is “dynomite” and the tool is well thought out and a great problem solver, it takes piles of money and connections to get your tool in front of someone that may actually buy it. If you’re curious, consider seriously how you intend to market your tool. Check out those costs. You absolutely will not believe what they charge for advertising. I thought I had a great advantage with the Server Sizing tool because it was written up in “Computer”. As it turns out, managers that could possibly authorize the purchase of such a tool actually can’t read, a fact I overlooked in my initial marketing plan. Please don’t quote that last comment on the Web. I’m trying to get a job, again.

    Sarcasm aside, developing both of these tools was a lot of fun. If you have the time and money to put something like this together, go for it. But I wouldn’t recommend quitting your day job, especially if other people are depending on you for financial support.

Comments are closed.