5 Reasons App Developers Fail their Clients

I’m a business and development consultant. I have been working for Magora for nearly six years. Many of the clients I meet have worked with other developers in the past. Often the reason for the change of provider is that their previous experience was not satisfactory.

In this post I’ve collected some of their most common regrets, so that you can learn from their mistakes and spare your nerves, time and money while implementing your own project. 

#1 Alien code

“The first 90% of development is not as difficult as the last 90%”.

At work, I frequently meet people with a problem that sounds more or less like this: “I went to a freelancer, and he developed an app for me. However, when I got the final solution, it turned out that it doesn’t work / works differently from the way I wanted it to.”

You as a client always have a choice. You can go to freelance developers or to an IT agency. Obviously, the first option is economically more beneficial. However, is one person able to perform the same high-quality product as a team of programmers, designers and QA specs? Based on my experience, the answer is not often.

My case: We received a code that we needed to review and fix. The programmers end up having to rework as much as nearly 90% of the other developer’s script to provide the final software solution in order to guarantee the proper functionality and stable, invulnerable realisation.

Moral: If you need a simple program and don’t dream of all the bells and whistles for your application, maybe it’s no problem asking a freelancer for help. However, you shouldn’t expect much in the case of complicated and well-balanced software.

#2 Who Framed Roger Rabbit

“East is a delicate matter”.

The reason any newbie to application business might want to work with Indian developers is that they are cheap. While Brits, Americans or European developers charge on average $50-150 per hour, an Indian can charge $15.

• However, the question is: can you expect the same quality from a non-qualified employee as from a mature professional? Believe me, developers who work for Google or Microsoft in India are very well-paid. But the low-cost ones will waste your time even in the case of a trivial project.

Let me tell you a story. I was in touch with a buyer who hadn’t made up her mind yet. She was choosing between the Indians and us. The business owner was literally torn between our portfolio and the Indian prices. Finally, she chose them, but came back to us after some time, somewhat disappointed with her first misstep.

• Guys, while making the final decision, consider such a “risk” as Oriental mentality.

In many eastern countries, it is considered very rude to just say “no”.

So, successful negotiations do not necessarily mean that you’ll get the project done within the agreed time and budget.

Tip: If you’re determined to work with the Indian agencies no matter what, choose trustworthy developers. And if you’re ready to deal with the language barrier and the difference in mentalities, just count double for each deadline so as not to be disappointed.

#3 A Quiet Place

“Why didn’t they ask?”

Communication is key. At times, things seem crystal clear in our heads, only for us to realise that other people can’t read our minds.
One of my clients told me this story:

“I hired a development agency to make an app. It should have facilitated the process of currency market fluctuation analyses. I have no idea where on Earth they dug up the economics book they’ve borrowed the calculation formula from!” Long story short, the program worked well, but the trends had been calculated incorrectly. This was discovered only at the final approval stage.

Moral: It is always better to come over-prepared than under-prepared.

Professional developers ask many questions – that’s how they discover your deep-seated needs. Provide as much information as you can.

You’ll save a big chunk of the project budget by explaining in writing things that are obvious to you. And you’ll save even more just by sharing future prospects. This way, the program architecture will cover your up-and-coming plans.

#4 Limited budget

“Life is short and so is money.”

When you plan to develop an app, keep in mind the widely-known project management pyramid Time-Money-Quality. Only two of these things can be your priority at the same time. You can save money and get a nice product but will have to wait longer. Otherwise, you get it quickly but with limited initial functionality.

One of our clients came to us with an idea for a brilliant e-commerce app. It had some gimmicks that made it rather technologically challenging. And, as usual, the budget was limited and time was pressing.

First, we decided to begin with an MVP and add extra features later. Following discussions, the project description was acquiring cool new features that made the app sparkle.

Can you imagine that the final budget was 10 times what was estimated in the beginning?

The more features you add, the more expensive an app becomes.

Hint: To avoid tensions, decide what the key points are for you. Is it more important to stick to the budget or to get the fully-fledged app?

It’s a great idea to begin with a compromise and add functional elements with each release. This way you’ll start making money from the first day the MVP is launched and attract more customers on the go.

#5 Out of the blue

“Two weeks till the project launch… Let’s make some major changes!”

My partner told me this story about an agency from whom he ordered some analytical software. An economical web solution, transparent architecture, a couple of SEO analysis features – and it’s a ready tool for turning a profit. With the team, they decided to develop an MVP and then see how it went.

The work is almost finished when the boss decides to change the concept and, instead of a chamber project, wants a more global version. The developers say they won’t do it in PHP like the MVP, but need to redo the whole thing on Node.JS. “I think they just wanted to rip me off! What do they mean they can’t do it so? The project is bigger but the logic is the same!”

Here I had to disagree. It’s not that we’re just talking in terms of some extra lines of code. To be able to process exponentially larger peak activity, one needs a totally different architecture and resources.

With Node.JS the program doesn’t have to call to the server each time adding more pressure on it but responds to requests immediately, which is, of course, much more efficient.

In a small project the difference is invisible, but with the high-load system it becomes crucial.  

As a development specialist, I totally understand the decision to redo the project from scratch, because the number of users critically affects the choice of architecture. I am sure that the project would be realised in a totally different way if the developers knew about future prospects of the app from the very beginning. I also understand the client who simply didn’t know this was so important.

Tip: Your vendor team has to know as much about your future plans for the project as possible. This may be vital for decision-making about the technologies to be involved and to provide scalability and flexibility for the business solution.

Moral: Begin a project with a discovery phase, create a professional software specification, rethink all the details twice, pare back unimportant features and begin the realisation of your great, well-balanced app.

You’ll save time and money with good developers who are experienced enough to implement advanced features and think strategically to support your business success.

Alex Galaktionov

Director of Operations and Business Development

A seasoned technology expert and agile advocate, Alex brings over a decade of transformative expertise in the IT sector