Backend-as-a-Service (Baas) provider Kinvey published an interesting infographic on the average time taken to build an iOS or Android app (with a backend service) this week. The data comes from a survey of 100 developers with their estimates averaged. Before interpreting the data, it’s worth bearing in mind the following:
- This is only to build a Minimum Viable Product (MVP) – it’s nowhere near the total that would be spent on a successful app.
- The features included create an app with a relatively rich backend service and a fairly basic client.
- This is only building a client app for one platform rather than several.
- Building a robust API versioning system would not normally be part of an MVP.
- This survey has been created specifically to promote the benefits of BaaS.
Even so, the the items included in the infographic would be common to a wide range of applications.
Using one of the more fully featured BaaS offerings you could cut the timings down as follows:
- Data Storage – in many cases you don’t even need to define a schema, you can just start storing objects from client code – 0 days.
- User Management – already provided, although you typically need to design and set up user roles and permissions – 2 days.
- Server-Side Logic – assume you can use some functionality provided by the BaaS but this is mostly unique to your app – 10 days.
- Data Integration – again, the BaaS may help with social network integration but the data sources are unique – 10 days.
- Push – all done for you, you just send push notifications from your custom server code or client code via a simple API – 0 days.
- Versioning – all done for you, create a new version when you need one on the BaaS (often a paid feature) – 0 days.
Backend total is reduced to just over 4 weeks rather than 10. However, that’s not all, since BaaS provider client SDKs can also include Caching & Synchronisation functionality, which could save another couple of weeks on the client app development. In theory the average of 18 weeks to build an MVP-quality app for one platform from the survey can be reduced to more like 10, that’s 55% of the effort required before you can test your app idea in the market with real users. Of course cost isn’t the only driver for technology selection but as long as you also consider the risks, a BaaS could make a lot of sense for your next mobile app.
Wow. You nailed it. Seriously, you just nailed this infographic. I run marketing at Kinvey, and I was the “owner” of this project, and you really understood what we were trying to do here. In your entire post, I’d have pushed back on only one word. You wrote, “This survey has been created ‘specifically’ to promote the benefits of BaaS” and I’d have chanced ‘specifically’ to ‘tacitly.’ Our marketing goal at Kinvey is to attract users by helping them without ‘selling’ them. That’s why we’ve published ebooks like “How to build an Android app” — books that barely even mention the company. But that’s semantics. I found your blog post informative (where did you get the estimates for time saved with BaaS?) and thoughtfully presented (the front end list of caveats, ‘specifically’ notwithstanding, are right on the money. Excellent stuff here. -Joe Chernov / Kinvey
Thanks Joe, glad you liked it. Thanks for creating the infographic. I really like your marketing approach but I’ll stick with specifically because the feature set chosen rather heavily favours the more complete BaaS providers.
The estimates for time saved with BaaS are mine and are only intended to be illustrative, although I’m a developer and have previously run engineering teams for a large mobile agency, so am used making that kind of estimate.
I’m a big fan of the BaaS concept & Kinvey looks like a great offering to me, although from a developer perspective I find your native/non-native app pricing split confusing. What if I have an app that spans iOS, Android & Web? -Mark Wilcox