How can I work with top developers and stay within my budget?

There’s a common perception that top-quality developers are too expensive, and it comes with a hint of truth.

As more and bigger organizations demand their services, quality mobile developers (and even the not-so-good ones) can command top rates.

Some clients then attempt to reduce costs by opting for companies (that are often based “offshore”, or outside the United States) that charge lower upfront fees. Unfortunately, this approach frequently backfires.

Here are some approaches I use to reduce costs when a client’s budget isn’t enough for what they want to build. (Spoiler: none of them involve sacrificing quality.)

1. Build features iteratively

I recommend an iterative approach to building software. What that means is you don’t build every feature you can think of into the first version of your app.

I often talk with entrepreneurs who start with a grand vision of how their software will look, and they start by asking for a bid for their bells-and-whistles, everything-but-the-kitchen-sink vision. This is a mistake.

Many of the features you think you need to include in your first version won’t provide enough value to your users to justify the cost of including them. Building the wrong features hurts your app and your company. It’s better to build your app with a focused approach.

An iterative approach lets you release software at a fraction of the cost of a “mature” app. And a big additional benefit of this approach is being able to learn from your users quickly.

That ability to learn is an under-appreciated benefit for new entrepreneurs, but well known to those who’ve wasted their development budget on features that couldn’t support a business.

Do your users actually need this feature? Would they pay for it? Would they continue to use your app if you didn’t have it? Build the simplest version of your product that will let you answer these questions, quickly.

This approach allows you to pivot and change course before you’ve sunk too much time, effort, and cash into features that no one wanted or needed.

1a. If I shouldn’t build everything at once, how do I determine what features to build first?

These are some criteria I use to decide what to prioritize:

What’s going to benefit the most (actual or desired) users?

Start with functionality that benefits a large chunk of your users. Is feature X used by most of your users or just a handful of power users? That’s a good place to start.

What’s going to get used most frequently?

Start with tasks that are frequent or repetitive; these are the core of how your user base interacts with your product. Save the edge case for later (or never… or as a premium feature for those power users).

Mobile apps are good choices for functionality that is used regularly, because they allow you to create efficient user interfaces for frequently performed tasks.  This is where a mobile app’s custom, native user interface provides clear benefits over other approaches.

If a feature is used less often, the performance gains from a native mobile app aren’t as obvious and a web application can be a more cost efficient solution.

What’s causing your users the most pain?

Some parts of a user workflow are probably difficult or tedious. Fix the bottleneck(s). Focus on the parts that give your users the most headaches.

What’s going to drive the most profit?

The functionality that is used most often by the most users is usually (but not always) the functionality that drives the bottom line. Do your users get stuck in a part of your workflow that prevents them from becoming paying customers? Then optimize that experience.

Use the native mobile experience to allow your users to do efficiently do the things that help your bottom line.

2. Reduce the scope of the software

Along with adopting an iterative development approach, it makes sense to really focus the scope of your app. A mobile app shouldn’t solve every problem for every user. This is especially important for existing business to business (B2B) companies starting mobile development.

Here are some ways to reduce scope and create a more focused app:

Reduce user types

Does your application serve a number of different types of users (e.g. Employee, Manager, Field Technician)? Ask yourself: Do they all need a mobile app, especially this one? Often not.

Many jobs are done at a desk with a big monitor attached to a desktop: that means a browser-based or desktop application would be easier to use. Don’t create native mobile experiences for these cases.

Create apps for those users without easy access to a desktop, or the ones who would primarily be using your app on the go or in the field.

Reduce use cases

Similarly, most applications cover a range of use cases. Are these tasks that will be done primarily while the user is at a desktop workstation? Or are they most frequently done while the user is off-site or away from their desk? Focus on the tasks that often need to be completed while away from a desktop computer (like approval workflows) vs the ones that are still usually done at a desk (like data entry).

3. But won’t removing features produce a “lesser” app?

No. You might think that I’m advocating creating a substandard version of your application. The opposite is the case: keeping your app focused provides both cost savings and a better experience for your users.

Here are some added benefits of keeping your features focused:

Reduced maintenance costs

The upfront cost of software development is just the down payment; every piece of code you add to your codebase has a continuing cost.

The code is something your developers have to keep working on while they add new features. Even with experienced devs, it’s easy to break things while adding new features. And even if if you’re not regularly adding or changing functionality, new OS versions often require code maintenance to keep things working.

The more complicated (and unfocussed) your app is, the more code developers will have to maintain – and the more costly this will all be for you.

Design debt

Another cost is design debt. Put another way, the more functionality you pack into your application, the harder it is to use.

Every added button, drop down and screen is another opportunity to confuse your user. Worse, adding the wrong features provides no value, and often provides negative value.

Design debt is one of the hardest temptations to resist when planning an application because it’s just easy to add a new feature without considering the continued cost. (A good sign you’re going down this path if if you find yourself asking the question, how hard would it be to…)

—

These are some of the factors I use to help entrepreneurs work within their budget to build apps that support their business. This advice won’t just save you money: you will create a better app for your business and a better experience for your users.

Ultimately, a good developer working with clear priorities will build software that will generate revenue for your business.

Ready to work with developers that specialize in iterative, focused development? Contact us.

Also published on Medium.