Being 6 years on the market and running a mobile software agency has brought our team loads of invaluable experience derived from epic failures and spectacular successes faced on our way to become a mature organization with codified processes. That is why it popped to my mind that it will be nice to share some of our findings and thoughts.
Main questions that I want to answer are:
- What are the distinguishing factors of mobile app development Dream Team?
- What you should look for and what you should avoid when choosing your development partner so that you don’t end up with a failing product and a team you want to immediately run away from?
So let’s discuss…
Trait no.1 – Experience
This part may seem obvious. Everyone is naturally looking for an experienced developer. The tricky thing, however, is how to really tell apart a team that delivers from the one that just has good PR. The good news about the current state of mobile technology is that the learning curve of knowing how to write an app has flattened with all great coding tutorials, StackOverflow and other sites with ready-made tips, interactive mockup tools and numerous out of the box solutions you may use, from creating the application backend, to implementing app analytics and marketing automation. The bad news is that it allowed loads of inexperienced developers to pretend that they are world-class experts. If such rookie developers are clever enough to invest in their web presence, it’s a recipe for a failure for a company looking for a partner to implement a scalable and reliable app that has some chances of delivering on its value proposition and be sustainable long term.
Here are some questions I would ask to increase the chances of working with real experts:
- When the company was founded?
1-2 years of corporate experience may be fine for non-demanding customers looking for cheap and easy app. It may be somewhat risky for the ones who want to make sure that a ‘serious’ app really works in the end.
- Who founded the company?
Stay away from a bunch of students or new grads even if they look like they were coding since they were born 🙂 I personally believe that the greatest combination is when the founders of the company consist of a tech geek who was coding himself / herself for a long time and created the company for a reason and a non-geek who has proven skills set to care about the business side. These complementary approaches should usually result in working with a company that truly understands your problems and can look at it from different verticals
- What are their technical USPs?
Look into CVs of the critical team members and make sure that there are ones with multi-dimensional coding experience, ideally knowing more than one programming language. For instance, if you are about to create a mobile game, it would be ideal to team up with a mobile developer who once coded in C++ and worked on desktop games. If you want to create IoT backed intelligent home system app, it would be great to have someone who knows a thing or two about embedded software, etc.
- What were their past failures and what have they learned from them?
“Honesty is a very expensive gift. Don’t expect it from cheap people.” (Warren Buffet) It is equally hard to expect a valuable honest opinion from inexperienced developers. That is why it usually works to ask the company you are assessing to tell you about the most valuable project experiences they learnt from their failures. Mature organizations are generally very open in providing numerous examples of what they realized on their way – what was eliminated and improved, etc. Rookie developers will either have nothing to say or they still will have a vague and unconvincing idea on how to be better in the future.
Trait no. 2 – Rock solid but flexible team structure
A good development company should be able to consult you on the optimal team structure for your project. The suggested team setup is also a great indicator of who to choose. You need to make sure it really is the Dream Team. Here is the list of people you usually need to create an app:
- UI / UX designer
This person is like a striker in a football team. His/her role is to make sure your app not only rocks visually (UI) but also is fun and intuitive to use (UX). Apart from checking the portfolio of such a person, it is usually advisable to rely on gut feeling whether you just get along together and both seem to be on the same page of what you are after. At the end of the day, if you don’t feel the ‘chemistry’ here how can you expect your app to be designed in a way that truly reflects your vision? Such things are usually easy to detect when you conduct a workshop as part of the discovery phase when you just sit together, discuss, sketch and draw to come to terms of what the app is about and how to implement it in optimal way. Be cautious if you are advised that one of developers will also play the role of UI/UX designer – geniuses like Leonardo da Vinci allegedly exist, but what you really need is the synergy derived from constructive discussion of an UI/UX expert whose mind is flooded with creative ideas and a developer who usually is more down to earth and looks at it from the feasibility and timeframe perspective.
- Backend / frontend developers
The appropriate setup here depends on the technology chosen (native vs hybrid for frontend and a variety of backend coding options), project timeframe, budget and generally on what the app is about and whom it serves. It usually is good to have at least 2 developers engaged per platform so that they can code review each other, engage in pair programming and generally motivate one another to deliver. It is possible and quite often beneficial that senior devs are accompanied by well-identified juniors or mid-levels, thus adding ‘fresh blood’ to the system and allow for more vibrant flow of ideas. Some seniors tend to follow the well-tired-out implementation path and promising juniors are usually full of innovative ideas and possible new ways of solving some problems, that they generally found somewhere in the Net and got excited about. If you had only juniors, then they would learn at your expense and had no idea what to do when something fails. Good senior acts like a ‘father’ here, providing reassurance and security but allowing juniors to explore and experiment when time allows it, which sometimes brings about unexpected brilliant system optimizations no-one had thought of before.
- Quality Assurance engineers
Well-designed software development process resembles a production line. An item moves further down the line if the person involved in this part thinks it is good enough to move forward. That is why, it is so important that a QA engineer is a SEPERATE team member. Once some part of the coding is done, then developers may review the work and manually test if added feature generally works – for some development agencies that is the end of the story. What you really need here is separate people involved in complex application testing once developers are done with their part. Ideally it should cover both manual and automated tests to ensure that you always know when you are with a product and which element is malfunctioning. Such setup hugely mitigates the risks of allowing nasty and embarrassing bugs pass unnoticed which may even kill the whole product once detected by mass users.
- Product Owner
This role is somewhat mysterious and many times wrongly interpreted but even a greatest dev team may be malfunctioning if the Product Owner was badly chosen or there is no such person. What is our definition of a PO? It is an intermediary between the product and the dev team who has enough time (important) to sit together with a team on a daily basis and translate the business requirements into development requirements and set the proper priorities so that both sides match. Assigning the Product Owner position is one of the most crucial team setup decisions. It is possible that the business or startup owner is also the project’s Product Owner but a separate person may be assigned here if the time or competencies of the business owner are limited. Generally, you need to make a wise decision here and the coherence of the development company recommendation in that matter may indicate if you found the proper people.
Trait no. 3 – Good and codified methodology
You can easily tell a good and bad development company apart when you ask them to share their white paper documents describing their workflow with you. The effort of codifying the knowledge gained is usually a sign of an organizational maturity. Good companies consider the collective knowledge as an invaluable asset and make sure that experiences learned on their way are spread across the whole team. Step two is usually making sure that people from outside are aware of the company’s expertise.
Take some time to analyze the methodology documents of the company you are assessing, ask disrupting questions, check how did they arrive there. Asking proper questions is really important here because some PR-oriented companies have the tendency of copy and paste random whitepapers to be found on the Net and call it their methodology. If you find their answers consistent, reassuring and professional, you may be one step ahead in finding your Dream Team.
Trait no. 4 – Constructive communication on both sides
A professional development company knows that a project may be derailed by mere lack of optimal communication between the dev team and the business owner. How to measure a good communication? By the ability to share mutual concerns in a productive manner. It is kind of natural that the business owner shares his/her concerns with the team (why are you late, why is it buggy, can’t you just be faster?, etc.). It is equally important that the key players in the dev team are able and not afraid to openly tell what they are worried about or which route may be better for the product. On top of that, the professional dev team is able to manage client’s emotions and concerns and turn them into challenges that they both face and are equally motivated to solve.
Trait no. 5 – Developers are not robots, they care
One possible strategy for a development company is making sure that the developers do their things right and basically create functional and bug-free software. Sounds reasonable, right? I personally believe that there may be a higher level a development company may reach, which is also a nice distinguishing factor. A Dream Team actually concentrates on doing the RIGHT things for the product. What does it mean in practice? Development team should not consist of robots that are ‘programmed’ to do their tasks, they have to think why they do this and what value it brings in general. It is further measured by the level of assertiveness and thinking outside of the box you notice when speaking with a dev company you potentially want to hire. If you feel that you are speaking to ‘YES-Men’ who are afraid to disrupt your idea or ask difficult questions, you are probably in the wrong place. Your Dream Team needs to represent a partner that you find valuable speaking to, not just a servant. What is the end result of such strategy for a development company? When you employ people who care, it is more likely that they contribute to the app’s final success which brings sustainable business and returning clients.
Obviously, the traits described above do not cover all possible issues you may have when dealing with a software company but I do hope that it will make it somehow easier for you to find the partner you will be glad working with.