You have an idea of a web or mobile application. Now you need a development company to make it real. This post is an overview of 8 critical areas to consider when hiring one.
The article is the 1st in the series. Later, we'll cover all these areas in details; for now, this post will be our Overview Guide (or Roadmap, if you will).
So, people in a good development company...
1. Masters in technologies you need
aka Strong Technical Expertise.
The company has experience making apps using the technologies you've chosen.
Technologies might mean:
- Platform (iOS and Android for mobile; Linux and FreeBSD for operating systems; Amazon Web Services for cloud computing)
Some indicators to measure expertise:
- Years on the market.
- Popularity of the apps they've developed
- Contribution to their technology and community:
- open source projects
- commits to frameworks/libraries
- training programs
Pretending to work with any platform or framework is definitely a bad sign.
Check their apps: verify they are working and accessible from the link on their website.
It's wonderful if you have an expert to estimate their apps for you!
Ask about technologies they used on their recent projects, and why did they choose them.
Discuss the possible challenges they see in your project and ways to deal with them.
Get their recommendations for technologies on your app. Do they approve your choice? Why? And what if they propose a better solution, and their answer is sound and well-reasoned?
2. Worked with your sphere of business
aka Business Domain Experience.
Examples of business domains are:
- Financial Technologies aka FinTech (banking, loans, money transfers, mortgages), like PayPal, Skrill, or TransferWise (we have Sindeo and MoneyPark).
- HealthCare (telemedicine, medical records and hospital management): like HealthVault (we have CareNetwork)
- Travel and Hospitality (hotels, accommodation, tickets), like AirBNB, Booking.com (we have Timedom and Diviac).
- Transportation (taxi service, ridesharing) like Uber or BlaBlaCar (we have Taxofon).
Knowing your business domain, developers will most likely:
- Understand your business better and thus convert requirements into features faster and more efficiently.
- Predict challenges your industry faces and propose solutions beforehand.
- Help you avoid typical mistakes they've learned from previous projects.
Make sure they are familiar with your business sphere.
Talk to them as if you were interviewing a future employee. Would they be smart enough to answer the awkward questions — even when their domain experience in not as sufficient as you would want?
Ask if they've worked with companies of the same business from your country. If Yes — that's almost a perfect match, since they'll also be prepared to handle your regional challenges.
Don't expect or ask to "fork" another project, i.e. to copy another app and fine-tune it for you. Beware if they propose to do so. You came for a unique solution, so their approach must be.
3. Created successful apps you can look at
aka Representative Portfolio.
This means rolling out projects that may impress you. A must for every development house.
Investigate projects from their portfolio
We mean it: spend more than two minutes scrolling through their landing page. Register and walk through an entire user flow. Verify that the application at least:
- Runs smoothly (you're not irritated as a user)
- Doesn't have obvious bugs
- Shows good response time
Look for feedbacks about the app on the internet
This will take time, but, in return, will give you more than a dozen of references.
4. Have good feedbacks from customers
aka Client References.
This shows if their customers are happy with the work. An absolute must, and a critical area to investigate.
Read the reference carefully
Not just screen it through but read every sentence. Try to feel if a real personality stands behind the reference, and the text is not just a set of marketing cliches.
Contact the referee
That's the person who's left the reference.
This will give many advantages. At first, you'll verify the person exists, and your future developers don't start cooperation with a lie.
Then, ask the questions that matter to you.
Contacting a referee is the toughest advice in this article. You may find that the person is a misanthrope, hates human beings and won't speak, acting as a spy on a KGB interrogation. You may spend hours reaching the referee and then finally know he's gone and "... was seen no more".
But in the end, the personal talk will give the best recommendation possible, and highlight the areas you couldn't even think of.
Look for additional and external references
Finding your potential developer in an external rating (like clutch.co) is the most promising sign. It means the company has been officially recognized among professionals in their field.
5. Have a great team
This is critical because, after all, it's the people who do the work. Technologies, business knowledge, experience, and processes — these are tools in the hands of the specialists you trust your project to.
The keyword is Team, the solid family of professionals, as opposed to Individuals, temporarily united to do some work. And it is the development company that creates and keeps Balanced Teams.
A great team is:
Actually a team — not a couple of Senior Developers and a bunch of service staff to help. The company must use their own approaches and algorithms to form your future crew, considering specifics and budget limitations of your project.
Dedicated — full-time employees (not outsourced or freelancers) who work in the company for several years, and either sit in the same location or have good communication practices (if working from different company offices).
Scalable — the company must have people to substitute team members who (for whatever reason) may stopе working on your project. Or, in the best scenario, may bring in more developers if your projects is a success.
Balanced — consists of people with needed domain and technical experience, and maintains a good ratio of specialists of different levels.
Passionate — expresses interest and enthusiasm when discussing your future tasks.
Try to know more about their employees
- Browse through the company profile on LinkedIn; see how long the people have been working in the company.
- See the Team section of their website, look at the personal and group photos. Try to understand if you actually like them.
Check the company contribution to community
Again — not individuals from the company; the company presence must be emphasized.
It's good if they:
- Have and maintain own open source projects
- Participate in community events
- Visit and talk at the conferences/meetups
- Provide own trainings
- Write to blogs or media
Don't try to get only Seniors or Leading Specialists to your future team
Instead, ask the company how are they going to create a balanced crew, and what would be the criteria they will choose specialists for your project.
Talk to your future team members before the work starts
6. Know how to manage your project
aka Well-Established Processes.
This is about the ways they organize the development flow:
- Models (or paradigms): Agile, RUP, Waterfall
- Agile methodologies: Scrum, Kanban, Lean, XP
- Structure of their company and teams: Hierarchy, Flat, Matrix
- many other types of processes
The topic is very important; thus we'll return to it many times in our future posts. The main idea is that business processes have a huge impact on your project.
Ask for an introductory lecture
This should be a For Dummies tour to the processes they use on different levels (from development paradigms to daily meeting management).
The successful lecture will show they have a person (or several of them) who is a specialist on Operations. That's a guarantee that your project will be in good hands.
Also, pay attention to the way they speak. Simplicity means understanding. Ask for practical examples, don't be afraid to ask many questions.
Discuss processes on their other projects
Ask not only about the methods they implied, but also about the reasons.
Verify if they can work with different methodologies
Agile (so popular in the Startup World) is not a universal methodology. Ask if they actually have experience implementing other techniques, and why.
How do they see own maturity with CMMI?
Capability Maturity Model Integration (CMMI) is a program that estimates how mature (professional) are the company organization and its processes.
There are five levels: from 1 (Initial, unpredictable and poorly controlled) to 5 (Optimizing: the processes are not only fully measured and controlled, but also improving).
The mere knowledge about CMMI shows a professional company. Ask how do they estimate own maturity in CMMI, and what makes them think so.
Finally: what can they recommend for you?
Require a solid answer.
7. Don't hide anything, keeping you updated at any time
aka Transparent Processes
This is about keeping you as much informed as possible, always. What the company must do:
- Hold regular meetings with live talks.
- Fully share the Agile Board on the 24/7 basis, letting you know the status of any project task. This is also about not having various Boards for you (as a Client) and for developers.
- Engage you in daily working discussions. It depends on you how deep your participation should be, but the discussions must be open, for you to look and interfere when necessary.
This may be done by keeping everyday discussions in Slack.
- Grant you the full access to the code base, with the Administrator privileges.
- Provide contact details of future team members.
- Consider the possible time difference between you and them.
We have an article about the tools to help us stay transparent and keep partners always updated. Hope it helps.
Do not allow any part of development to be hidden from you (even if said they're doing it not to overload you with extra technical details).
Discuss the degree of your participation from the very beginning. Are they willing to involve you to the maximum possible extent?
Ask how are they going to handle the six transparent items above.
0. Finally: you enjoy talking to them
aka Effective Communication.
Making a good app (web or mobile) takes a long time and usually continues after the MVP. It involves support, enhancements, bug fixing. This means you'll have to talk to your development partners a lot.
In good communication:
- You feel comfortable speaking with them. You're not frustrated just from seeing an incoming email with their name in the address line.
- They listen carefully and don't interrupt.
- They don't say "We can't do that" but rather "What if we try this …"
- They are proactive: for every idea of yours they come out with a dozen ways to do that.
- They have good sense of humor, making talks relaxed and fun.
Let's not mention signs of bad communication — they might be different for everyone.
If you feel you don't like the communication after going through all the things in this article, better hop off. We're sincerely sure the cooperation should be easy, enjoyable, and fun — for all sides.