When creating a non-trivial project, you can be certain that many unexpected problems will arise. It’s the developers job to fix or work around these problems, and one of the measures of the dev’s experience is how fast and efficient they can fix them.

However, there are some problems that even the best developers dread, and they have nothing to do with programming complexity or sophisticated architectures. Rather, they cause a lot of lost time and unnecessary frustration for both the dev team and the customer.

Thankfully, they are easily preventable, and spending some effort to avoid them will turn you into a great customer in the eyes of the team and save you time and money in the long run. Here are some of the main fears you should consider, as well as possible solutions.

Communication with other time zones

Clear communication between the customer and the dev team is paramount, and even more so when the time zones of the sides don’t overlap a lot - it means you have less time to talk to each other. This is a common issue for outsourcing the development effort overseas, which also adds the concern that someone is using a non-native language.

There are some ways you can prevent the possible confusion and miscommunication:

• Forming shorter, simpler sentences.
• Avoiding ambiguities.
• Not being afraid to over-explain concepts.
• Using specific examples to explain each case.

No division of labor

Building a complex application requires many different steps: designing, programming, testing, managing the team, collecting user feedback and then iterating again and again to achieve the desired result. All of this fields are complex enough to warrant dedicated specialists with defined areas of responsibility, and each of those specialists wants to work with other professionals.

It can seem expensive to hire both a designer and a developer when there are people claiming to be able to do both, but the truth is that most (but not all) of such people only produce mediocre results in both fields. It can not only lead to unsatisfying results, but actually cost you more money, as it takes them more time to achieve the same things as their narrowly specialised counterparts.

Consider a developer with an hourly rate of $15 that says it will take him a month vs a developer who says he’ll have it done in a week for a rate of $60/h. In the end, you get (hopefully) the same result for the same amount of money, but 3 weeks later.

Unclear requirements and no feature list for the final product

One of the worst things a developer can hear is “can we quickly add this feature before the release”. Any task has to go through the whole workflow (creating specifications, designing, implementing and testing), and a narrow timeframe can lead to cutting corners in any of those steps, resulting in bugs and undesired behaviour.

Moreover, a seemingly small change can require significant effort, and sometimes even an architecture and underlying model change.

This way a feature that would only take a day if defined in the beginning can end up requiring a month of work near the completion of the project. It helps to have a technical person take a look at all possible additional features at the planning stage and tell you how much effort each will take, and whether it should be included at the very beginning.

Not iterating or answering questions

As much as technical specialists don’t like micromanaging, giving them free reign on the project might not be the best choice either. Good developers realise this and frequently ask for feedback on the completed work and directions for future tasks.

The fact that you’ve chosen the best dev you could find doesn’t mean that all of your views will align. So it’s in your interest to take part in the iterative process and check the available progress, especially if the team asks for your opinion.

Same goes for answering team questions. It might be tedious and sometimes the questions seem like nitpicking or clarifying very minute details, but it all insures that the developer crafts exactly what you have in mind.

Insufficient quality assurance

Often when a business owner wants to reduce costs, they resort to hiring less experienced people, and at first sight the QA specialist is the obvious choice. After all, all he does is open the app and tap around, trying to crash it or finding inconsistencies.

In reality good QA is vital for your app, and a bad QA specialist will not only miss critical bugs, but also waste a lot of the developer’s and project manager’s time. Here are just some of the things that have to be done right:

• Concise bug titles and descriptions.
• Using correct builds and environments.
• Understanding app’s logic to state the correct cause for the bug.
• Making sure only a single bug is described in one issue.

A good QA specialist is the developer’s best friend, a bad one is a source of frustration and wasted time.

Summing Up

Taking time and care to prevent or solve the mentioned issues (and others like them) is a win-win situation for all parties - you get a productive and loyal team building the app you envisioned, and the developers can spend time solving actual problems and improving the quality of the final product.