"I'm going to have a developer build an app for me, and I want to make sure that we manage very effectively so I don't end up spending money for things I don't need to spend it on. How should I proceed?"
Barry, Owner, Senior Consultant
Barry has over 5 years of experience developing native mobile apps for clients, line-of-busniess mobile apps for fortune 500 companies, and original apps for the Apple App Store. Before that, he was building standalone SaaS applications that helped thousands of businesses serve their customers better.
App development is expensive, and for a lot of companies app development just doesn'ty have the right level of ROI [Edit: unintentional Scotty impression... but I'm leaving it]. You're going to be creating a new codebase for yourself and your team to maintain, you're going to be dealing with a tough learning curve, and you're going to be tieing up a lot of talent for a long time. So, its not really a wonder why mid-size companies will look at native app development in particular (iOS-ObjectiveC/Swift, Android-Java) and run away screaming to the seemingly safer arms of cross platform tools like Xamarin and Phonegap, which have their own pitfalls. So, for various reasons, the ROI of developing apps doesn't justify the cost of implementing them. But, if you're dead-set on creating an app, what are some of the things you can take into consideration in order to lower your investment costs. In this quick posts, we'll break down some of the major money-sinks and expose you to the necessary knowledge that will help you avoid getting upside-down on your app development projects.
#1 - Besure to map out your entire project and be as complete as you can be, defining all the screens, designs, and functionality before you start coding (be extremely thorough).
Storyboard the entire app, plan all your animations, all the fields and things you'll need, you define it all up front and freeze it into your app build. Even go so far as to factor in the designs of future-looking features. This is so, so, so critical to saving money on building apps because rework is much more painfully expensive in mobile apps than in web apps (IMO) [1]. But, why should this be? Long story short, its the nature of the implementation, the painstaking mappings from UI to models, the lack of scaffolding, the verbosity of the languages, and the often-low-level worries that just aren't as present in modern web frameworks that do a metric ton of heavy-lifting for the developer. Play it safe, plan ahead, be meticulous on your design and then and only then, start coding.
#2 - Keep the UI simple and your customizations to a minimum. The simpler the better.
It almost goes without saying that a custom UI with really slick custom behaviors and animations can really boost the cost of a mobile app, but you're probably underestimating how important this is. Work with your developer to find a middle ground where you can get most of what you want without falling off into the deep-end. A good developer will know where the line is between something that will take no time at all and something that will take a sizeable time investment.
#3 - Avoid money-sink features like push-notification (unless its a core feature of your app that users really really want)
I regularly tell people that push notifications will, no joke, add as much as 20-30% to the cost of a project, not just in terms of up-front setup, but also in terms of ongoing maintenance. Certificates need to be generated, installed, and tested (every year). The app will have to register to receive push notifications, and it may have to do something interesting with them when they are clicked on in the Notification Center. Furthur, you will have to send notifications from a server somewhere, either on a schdeduled basis, or in batches, and if you're sending thousands of them at a time, you really have to pay attention to throttling and good error handling so you maximize your chance of message delivery. For some people, this is a reasonable expense to pay because the users will REALLY want to get those notifications, for others, its not worth the tradeoff.
#4 - Avoid globally configurable styles and text
Here's where we start going off the rails a bit, because we are suggesting that you avoid best-practices in favor of cost savings. When we say "configurable", we mean that the colors, text, field sizes, et. all are all editable from a central location in the code. This means that a developer will take extra time to make every element configurable in some way. Now, the extent to which a developer will make things "configurable" varies from developer to developer. Very senior developers will tend to favor configurable setups, but it does add cost. Be sure to talk to your developer to see whether this will be a concern or not. Its possible that you can squeeze some cost savings here by asking that the developer avoid configurable text and colors.
#5 - Designing a "universal" app vs one-device only
If you can get away with designing just one user interface, you should do it, and that's at the heart of this suggestion. If you want your app to run on iPhone and iPad, generally you need to consider creating two designs to fit the different screen resolutions of the devices, but since we're in penny-pinching mode, we can forgo this expectation of users in favor of a simple, single UI design that works well on iPhone and iPad. A good developer and designer should be able to accomplish this within reason, but they will also try to steer you towards having the two designs (because that's what's best for you when you don't consider costs). We're not saying this is ideal, we're just saying its cheap.
[1] By the way, this is where cross-platform tools like Phonegap have the advantage. Things are much more easily refactored in Javascript and HTML generally than Objective-C. With the advent of Swift, however, we might see the scales tip back to the native iOS implementations.