What to Ask When Hiring a React Native Consultancy

If you don’t have your own tech team and need an app built, sometimes hiring an agency to design and build it for you is a valid option. Like with any other significant purchase, you should be informed before putting down a bunch of money to get your app built.

Far too often, companies and individuals who do not have a technical background have no way to gauge whom they’re hiring, or what to expect in an engagement. This list covers some important questions that will at least make you think about the types of things to look for in a software consultancy. A handful of them are React Native-specific; most can be applied to any technical engagement of any kind.

(Note that I use the words agency and consultancy interchangeably.)

Project Scope

“What’s your process for gathering requirements?”

Discovery (or requirements-gathering) is included as an initial phase by many agencies; it’s the process whereby any unknowns become known: time risks, difficult technological challenges, complex business processes and a number of other possibilities.

The agency should be able to give you a sense of whether discovery is needed for your project, how long it should last, and what the discovery process will entail.

“How long does it take / how much does it cost to build a React Native app?”

To most pros this is a silly question since it’s like asking how long it takes (or how much it costs) to build a house; the answer is there’s a big range that depends heavily on what the house has in it. The number of rooms; the type of rooms; not to mention the conditions of the land the house will be built upon.

That said, a good agency will handle a question like this gracefully by explaining the above to you.

About the Technology

“Why React Native?”

React Native may be a hot technology buzzword, but that should never be the only reason a team uses it. Whereas many teams will focus on one framework rather than another, they should be able to justify their decision to focus on React Native vs Flutter or Titanium for example. And with multiple branches of reasoning.

“What can’t React Native do? Or what doesn’t it do well?”

No one framework is suited to every task, project or situation. Anyone who is experienced with React Native (or any other framework) should be able to tell you situations where it’s not the best solution. If they can’t, it may be a sign that they’re way too attached to their tool of choice (and a bit dogmatic with their approach to technology), or not experienced enough to know its limitations.

Development Process

“Do you develop on simulators or actual devices?”

Development teams will often rely on software that simulates mobile phones and tablets since it’s impossible to own every device out there, even for a very large team. The simulators allow an unlimited assortment of device models and versions.

There are certain things that are only accurately testable on real devices though; things like in-app purchases, or camera usage for example. Mobile engineering teams — especially remote ones — should have at least a device or two on hand for testing things of this nature.

“What’s your Quality Assurance (QA) process?”

QA is the process whereby the software is tested (manually, and in an automated manner as well). A good consultancy should have a process by which the software is ensured to be working as intended, a way of tracking issues, and time allocated to a project’s budget to ensure any critical bugs are found and eliminated.

“What does the end-to-end (E2E) process look like?”

Automated software testing is crucial when building complex applications. End-to-end testing, in particular, is testing that runs the app and simulates the use of the app as if a real person was using it; clicking, tapping and typing relevant information into it.

E2E testing runs more slowly but tests that the critical things are working at all times. So an engineering team needs a strategy for when to apply this type of testing, and a process for how to go implement it (and how to run the E2E tests regularly, such as with a Continuous Integration process).

“Will our developers, or other contract workers, be able to maintain a React Native codebase after the contract ends?”

This is crucial. Sloppy engineering teams build things that aren’t easy for anyone else to follow; code is written with poor naming conventions; documentation doesn’t exist; things are cryptic for no reason; files in the codebase are large and messy.

Better teams have well-commented, self-documenting code that is unambiguous along with release notes, wikis, and other things that make it easy for anyone with decent skills to pick up and work with.

Getting the App Out There

“How do we release a React Native app?”

A novice RN engineer might be able to cobble an app together and have it work in the simulator; getting it live in the Apple App Store and the Google Play Store successfully (and repeatedly so) takes a bit of experience. Experienced RN teams will be able to tell you what types of materials you’ll need upfront (marketing, legal, and so on), in addition to walking you through the many ways the stores (in particular, the App Store) can notoriously reject your app, forcing you to go back to the drawing board and spend more time and money.

Customer Service

“How do you educate your clients?”

Consultants are meant to be experts in their industry. The more established ones teach, publish, speak at conferences. And even the ones that don’t should at least know a lot more than you about the subject matter; that’s what you’re hiring them for.

As such, they shouldn’t just take your money and make things; they should be able to give you some understanding of why a feature should work a certain way, why some tasks will take longer than others, and the implications of taking one approach over another. They should be adept at (and comfortable with) explaining complex concepts to people outside their realm.

“How do you ensure timely delivery while staying on target with a budget?”

Time and money are things that anyone who’s ever hired an agency cares about. Normally, you’re hiring an agency to build something that’ll help you make more money or save more time, so you don’t want to burn too much of either one during the process.

Asking this question will give the agency a chance to describe the processes, habits, tools and everything else they use to keep timelines and budgets from missing their mark. And depending on how they explain this, it’ll cue you in to just how important they treat their clients’ time and money.

“How frequently will I be updated about my project?”

Some consultancies (or freelancers) will take a project spec and disappear without a trace for days, weeks on end. That’s all fine if that’s what you agreed to, and you’re comfortable with it — most people are not.

Any consultancy you hire should have a typical pattern of communication with their clients, be it biweekly, weekly or daily. This will differ by the type of project the consultancy focuses on, industry, team preference, and project. But they should be able to verbalize why they approach their communication the way they do and make you feel comfortable that you’ll hear from them when they say you will.

About the Agency

“Have you worked with enterprise (or SMB, or fill in your industry) clients before?”

Enterprise technology projects have different needs, restrictions and processes than those for small startups, small- and medium-sized businesses. So the agency’s approach needs to fit within those needs.

Similarly, each industry has its own subject matter and specifics. Health tech (which we happen to do a lot of) has specific rules around HIPAA data privacy and patient information. So whereas a good technology consultancy can work in a great many industries, it doesn’t hurt for them have had a little experience in your industry, particularly if it’s one with a lot of specific industry knowledge like health tech or FinTech.

“Where are your engineers/designers/QA testers located?”

I believe that consultancies should be very upfront about this, but I’ve seen many advertise themselves as being based in the USA when only one or two employees are based there (usually sales reps), and their engineers are completely offshore in another country. This feels like a bait-and-switch to me.

Engineers located anywhere can be effective, but it’s important that you know what you’re getting. And if it’s important to you that you’re working with domestic engineers, or engineers in a closer time zone, that information should be front and center.

“How can a remote team be as effective compared to a shop that is all onsite?”

The world is still divided in their perception of remote work; many companies still cling to the notion that all people regardless of role need to be in a cubicle working to get anything done. Quite the reverse is true and it’s gradually becoming more understood publicly, however; and as remote agencies, we should be able to verbalize why. I for example often cite stats about the effectiveness of remote workers and the book Remote, both of which solidify the tangible benefits of remote work.

“What process is in place for when an employee is sick?”

When you’re hiring an agency, you’re looking for a solid team of people—people, not a person—to build something great for you. By definition, you’re hiring a group of people, not an indestructible lone wolf hero. With that should come a realization that all people (even our lone wolf hero of legend) are human, and run into problems at times.

Sickness, injury, jury duty; all these things affect even the most lone-wolfiest of us. A good agency has safeguards for handling them all without any disruption of your project’s progress.

“Will the same engineers be working on the project for the full duration of the project? How often do engineers transition out?”

For longer projects, in particular, it’s not always ideal—for either the agency or the client—to have the same engineers on the project for too long. A certain amount of time is important for understanding the domain, setting up the project on their computer and so on. Too long, and it’s easy for people to have less impact at what they do, and stop learning drastically different things.

This is one of the benefits of hiring consultancies; their engineers see so many diverse projects, that their knowledge is extremely robust. So some consultancies switch them out after a period of time to keep them improving and bring new eyes to your project that will see things the veterans won’t. But this duration should fit well with your project’s timing, so it’s good to have a sense of this upfront.

“Can I talk to any of your previous clients?”

This last one is a question that few people think of but is incredibly important. Recommendations and social proof of some sort can make you feel a lot more certain that you’re hiring a group of professionals that have helped another professional like yourself get things done—well, professionally. You’d ask for references for someone who was babysitting your child; for some, their company is like their second baby. A good agency will treat your project like an infant—with the care and respect it needs. And they’ll be glad to ask their other clients to tell you just how well they’ve taken care of them in the past.