5 common mistakes clients make when using agencies to build mobile apps

There are numerous articles about mistakes agencies make when working with clients, but those lists tend to be quite big, addressing everything – from communication style and understanding the business, to skipping steps in the design and delivering untested builds.

At Five, we’ve been continuously learning and enhancing the way our agency works over the last eight years, and there are still things we could and should improve.

The client *was* always right.

I won’t go into differences between “good” and “bad” clients or try to educate you on how to be a good one. I also won’t repeat the basics, such as “be careful with the change requests during the project” or “trust and listen to your agency.”

All agencies are aware that “the client is always right”, but the agency has been hired due to its specific expertise and knows the ins and outs of the business. And I actually genuinely think it’s the agency’s job to get the client to listen, whether through the right arguments (such as user-testing data), strong presentations based on previous industry experience, or simply high hourly rates (according to the old secret of consulting “make them pay you a lot, so they have to listen to you”).

Over the years, I’ve seen mistakes that our clients repeat over and over again. Some have been quite frustrating, and some luckily do not have repercussions (if we don’t count the “I told you so” moments). Here are five mistakes that can have the greatest impact on a project and yet can be easily avoided.

1. Asking the wrong questions during the RFP process

The first thing that could go wrong is, obviously, choosing the wrong agency. We’ve had clients turn us down during the request for proposal process just to return a couple of months later unhappy with the agency they chose.Why? Because they asked the wrong questions during their early vetting process and put too much emphasis on completely irrelevant matters.

The goal of the RFP process is to meet the agency, see how they work and what makes them special. It’s a two-sided process: not only do you (as a client) pick the agency, but the agency picks you as well. For example, don’t make them compete on price early on because most of these estimations are a shot in the dark, and pay attention to the questions they are asking. Don’t be blinded with the brands they’ve worked with and case studies they’ve published — maybe it was their A team, and you’ll get to work with a C team.

The goal of the RFP process is to meet the agency — see how they work and what makes them special.

Also, be realistic with the proposal deadlines if you want them to do their homework, research your business, and come up with a detailed proposal. Don’t ask for it by tomorrow EOD just because you have other agencies in the pipeline.

The pressure is on you.

There are a few types of questions we are always asked, and it’s not something that will make or break the project.

For example, asking the question “What is your hourly rate?” first is pointless because that question is totally irrelevant. Maybe our rate is $50 but we’re extremely slow and inefficient, and maybe our rate is $500 but we deliver bug-free, easily maintainable code weeks ahead of schedule within a fixed budget and with lifetime support.

What you should really be asking are questions like “What could you do with a $150,000 budget?” or “What is your typical project budget?”, if you want to keep your cards hidden.

Five questions you should ask (in a subtle manner):

• Where do you see pitfalls and problems?
• Do you see this project as an important reference for your agency?
• What is your typical project timeline?
• How do you manage projects, and how can we sync our two orgs?
• How do you handle change requests?

2. Making the wrong budget allocation

Most clients expect a fixed budget at the beginning of the project. And that’s fine — it makes perfect sense from the client’s perspective. However, it’s unrealistic. The typical input for the budgeting process is a written specification for the project. But a two-page Word document with a bunch of bullets can’t possibly be enough to scope out the next four to six months of work, right?

Even if the agency is willing to commit to a certain fixed budget, it’s not necessarily a good thing. As the project moves forward, you will begin to clarify your expectations on certain features, and if that falls outside the scope the agency planned for, they will push back. It’s simple math and it will work against you. You want the agency to do the best for you and your project, and push to maximize quality rather than to minimize the extra work. So how do you reconcile these two interests?

Ask for a budgetary estimate at the beginning.

The agency is expected to have experience and be able to say whether the project will be somewhere between $50,000 and $70,000, or $100,000 and$120,000. But lately we’ve started to budget projects in three phases:workshop as the first one, design phase as the second one, and development as the third one. And you can do a 100 percent accurate fixed-price estimate only after you’ve successfully completed the prior phase.

So we deliver the fixed-price estimate for the workshop (more about that in #3) and do a budgetary estimate for the next two phases. And it works.

Crunching the wrong numbers.

Another problem is incorrectly allocating the budget for the project. We’ve seen clients spend all of their budgets on the first version of the app and completely forget about the version 2, changes and updates, or marketing. If you’ve just raised the funding for your project and let’s say you have it fully allocated for the app development, plan to spend a maximum of 60 percent on v1 of the app.

If you’re in the planning process and you’re allocating the corporate budget for the app, plan to allocate 100% more for marketing, and version 2 plus changes to be applied after you’ve learned from the v1 results.

3. Not communicating business goals (or even worse, not having them).

It sounds so obvious, but the majority of our clients actually don’t know their business goals before the project starts. And those goals should shape the whole project and affect where we focus most. We simply need to understand your business goals and what drives you forward.

It sounds so obvious, but the majority of our clients actually don’t know their business goals before the project starts.

First, ask yourself the following, and then communicate it to the agency:

1. Why are you doing the project? What’s the motivation behind it? What drives it?
2. What are the key metrics you will measure? Is it revenue, user base, time spent in the app, monetization, brand awareness, or something else?
3. What is the criteria for success? A year from now, how will you measure the success of the project?

Be the hero.

You have to understand one of the concerns each agency has: it’s that you’ll cut the project at some point if it doesn’t bring the expected results.

Maybe it will be your CFO who will simply look at the numbers and decide to cut the funding. Maybe it will be your CEO who will not have you spend any more time on this as it’s not bringing value. Our goal as the agency is to make you, the project owner, a hero within your organization and to help you move up the ranks with the success our joint project will bring.

Our goal as the agency is to make you, the project owner, a hero within your organization and to help you move up the ranks with the success our joint project will bring.

And that’s why we push for workshops at the beginning of the project.

We do Design Sprints, a five-day onsite workshop during which we talk about your business goals and see how they evolve into specific app features.That’s when most of the learning happens and, interestingly enough, when clients learn about themselves as well, each stakeholder’s motivation and expectations, and that sets the tone for the project. After the workshop, we’re confident we can estimate the design phase, as only then are we all on the same page about what we’re actually building.

4. Not allowing enough time for the creative process

Clients tend to push for first app builds, as they want to see progress and show it within their company. But the reality is that the first production-ready lines of code won’t be written two months into the project (we might do a coded prototype or two of some advanced features). And there is a simple logic behind this: agencies tend to spend a significant amount of time during the design phase fleshing out all the product details and making sure everyone is on the same page.

In the design phase, changes are more than welcome, and there is a steady review process where everyone is asked for feedback and that feedback is incorporated into the final designs. Changes in the development are expensive, and in the UX phase they don’t cost more than a few clicks.

The reality is that the first lines of code won’t be written two months into the project.

There are several steps that need to be completed before moving into the development phase, and it requires time and commitment from the client as well to provide input, clarifications, guidelines, and feedback. Make sure you’ve completed all of these steps:

1. Complete wireframes (UX) with all the flows. Cover all the states (errors, empty states, messages, micro copy, etc.).
2. Wireframe prototypes (e.g. Invision).
3. User testing of the key UX flows.
4. Designed screens with style specs.
5. Designed prototypes.
6. Animations.
7. User testing of the final designs.

Take user testing seriously.

It can be done within your company or it can be done within the agency, but for real results, spend a day at a user-testing facility. After completing the UX phase and after completing the UI phase, we bring in a minimum of six external users to the facility and validate all the assumptions. In between we do simpler and faster internal user testing, and sometimes we do a week of user testing with 30 users (six per day is our optimal plan).

If you do the design phase correctly and without skipping steps, the development phase will be a walk in the park — no surprises and punctual to a day.

5. Underestimating the backend work and API

“We have an internal team. We’ll take care of it.”

We’ve heard it before and know it’s a red flag. On the other hand, the truth is that there is no one better than the internal team to take care of the backend. It ties into the business logic, databases, servers, and opening it up for an agency would require too much work. And the agencies aren’t too keen on it. We don’t want to spend months learning the intricacies of the client’s internal systems.

But the reality is that those clients’ internal teams are burdened with work and have too much on their plate. In the past three years, all the delays we’ve had in delivering our projects were directly related to delays by the clients’ internal teams in charge of the backend and the API.

API first.

In a perfect world, no front-end work (mobile apps or even web apps)should ever start before the API has been delivered and tested. We’ve yet to see that happen, as it typically all starts in parallel. Clients and agencies agree on a rough spec, and, more often than not, the agencies build their mockup API to be used during development. And the premise is straightforward: once the real API is done, we’ll just switch. And it never happens painlessly.

Building efficient APIs requires committing significant time and resources. It requires planning from joint client-agency teams, and it, plain and simple, requires staff hours. It’s easy to underestimate that work. We’ve seen it a bunch of times. And now it’s the single most important thing of which we warn all of our clients.

Start early, communicate often, and have the agency test it out as soon as possible. Treat it on the same level as you would any other project. It’s not an add-on to an external project. It’s not you just providing support. It’s a full-fledged project requiring a technical lead and at least couple of weeks. So plan for it.

Start early, communicate often, and have the agency test it out as soon as possible.

Help us build great apps!

Or should I say, help us help you.

Ask the right questions, allocate your budget correctly, communicate your business goals, allow the creative process to flow, and never underestimate the backend work and API. Having the right agency and keeping these five things in mind, you might just get out of the limbo of constant frustration and witness the process of building some great digital products.