Choosing the right software development company for your product is like hiring a crew to build your new house.
There are plenty of contractors who say they can do it.
For most, it’s true and they will build that actual house, with walls, ceilings, and everything. But will they build what you actually need and the way you need it? Even if a lot is planned and decided upfront, the final output is hugely impacted by the contractor’s abilities.
So what’s the difference between a brilliant and mediocre construction crew?
Broadly speaking, there are three:
- People – responsible, proactive, passionate, and ready to share their advice.
- Are they treating you seriously?
- Are they proactive in making improvement suggestions and detecting potential issues?
- Do they require holding hands throughout each step of the construction process?
- Do they try to understand the purpose of the construction and how it will be used?
- Do they like their job?
- Expertise – experienced in working with your specific type of construction, required tools, and materials.
- Do they have experience with similar types of constructions?
- Do they know their tools and materials well?
- Are they able to advise you which materials to use for each of the building parts?
- Process – transparent, adjustable, speed, and outcome optimized.
- Are they able to present to you a clear plan of construction?
- Are they focused on delivering valuable results rather than simply finishing their work?
- Do they communicate the progress in an open way?
- What do they do to optimize their work-flow and speed of work?
- Are they willing to update the scope of the project when circumstances change?
Frankly, no matter how much research you do, you will never be 100% certain.
But you can minimize the risks and recognize some opportunities.
And that’s the purpose of our “How to Choose a Software Development Company” guide.
When choosing a software development partner, you need to verify three things: their mindset (=people), expertise, and process. You can do this by looking at:
- Company size
- Location (language + time-zone differences)
- Pricing model
- Culture fit
- Style of communication
- Tech stack
- Process & documentation
- Security measures.
A good software development partner should be able to walk you through these factors in a transparent way and without throwing buzzwords around.
1. What do you expect?
The first step you should take when choosing a software house is defining project requirements and your expectations.
Based on the problem your product is going to solve, decide what the exact tasks for the developers will be, and what technologies, skills, and budget will be required.
- What do you want to build (e.g. web/mobile/desktop app)?
- Are you building your team and product from scratch, or do you have your own team and just need an extension?
- What are your existing roles, experience, and tech stack?
- What are your gaps – which technology stacks or specialized skill-sets are you going to need?
- Do you have long-term or short-term needs?
- What is your budget?
Answering these questions will help you narrow your search down significantly and as a result, save lots of time.
2. Red flags
At this point, you should be doing your initial search. Sift through the options you’ve Googled or personal referrals you’ve received.
Look at each company’s website, look up their projects, experience, expertise, quality of content, etc. Pay attention to all “red flags” like – poor quality website or content, vague portfolio descriptions, or generic testimonials.
Go even further – Google the company to check if you can find any bad reviews, complaints, or information about lawsuits with clients – study those issues and how they were resolved.
3. Become a VIC
I learned this advice from the book “Built to Sell: Creating a Business That Can Thrive Without You” by John Warrillow.
This simple rule will help you quickly narrow down the list of potential partners and make your choice easier.
The thing is:
Don’t choose a company much bigger than yours for a partner.
Why is that?
If the company is too big, it may not give you enough attention. If they are too small, they may not have enough experience to work on such a scale.
Similar or smaller size companies will treat you like a very important customer. It will ensure their attention, respect, and better cooperation.
4. Measure expertise
Once you have selected one or more companies, you should take a look at their previous work.
Look for apps similar to yours or experience in the market.
If possible, test the applications listed in the portfolio. They are often publicly available and you can determine whether you rate them well as a user. The app’s rating in stores like Google Play is also a great indicator.
Once you have an idea of what the company can do, and it suits you, check their reviews.
Many companies publish testimonials on their pages. That’s great, but don’t rely on that alone. They might be completely fake and made up, and the people non-existent.
Note: Testimonials on the company’s own page might be completely made up.
You might consider finding the authors on LinkedIn and asking them for details and opinions.
Try to contact your network to check if any of your acquaintances have experience with the company.
Another easy way is to look for reviews around the internet, for example on Clutch, Facebook, or Linkedin. Clutch-like portals are great in particular – clients must publish the review themselves, and the platform verifies the author and in some cases calls them to ask further questions.
5. Tech stack – the fewer the better
When it comes to technology, usually the fewer the better.
You want to work with experts. To be considered a real expert, a company needs experience.
According to our and our competitor’s experience a significant percentage of software projects is developed within 4-6 months, many others take years to finish. Technologies evolve quickly: some stay for long, some can become obsolete in 3-5 years
Having the above in mind, it’s pretty unlikely that a company with 50 developers will be an expert in dozens of technologies at the same time.
Of course, the situation looks a bit different in the case of enterprises.
In general, if you see a software development company’s landing page has a ton of logos of different technologies, like RoR, PHP, Node.js, or .Net – be careful.
To build a front-end in React, find a company working mainly in React.
If you want to have an app built with Ruby on Rails, find a company working solely in Ruby on Rails.
6. Is location important?
The short answer is:
Yes, a bit.
There are at least four outsourcing models based on geography, each has its own advantages and disadvantages.
Onshore, offshore, etc. …
Onshore software development means working with companies that are located in your home country.
Its main advantage is that you can work with skilled teams in your own country and language.
However, there is one major concern with this option – the cost – which is usually significantly higher than other options.
In a nutshell, offshore software development means hiring a team from abroad to do the work remotely and virtually.
Main advantage? It’s affordable.
Nearshore software development is the in-between of the two options described above. These companies are located in countries with time zones similar to yours.
This solution provides a nice balance between natural, efficient communication and major cost savings.
Hybrid software development outsourcing is a mix of management done onsite (in your region), and actual development done abroad.
You can work with the management part in your native language and in the same working hours, while they deal with developers abroad and handle time zone differences.
Location vs quality
In terms of the quality of code, you can find great software development partners all around the globe. But some regions are more abundant and likely to have them.
Here’s a handy table listing regions with the best score of development quality:
Technical skills, however, constitute only 30-40% of a business’s success. Therefore, you need to look for a partner who can advise you, not only write the code.
You want to hire creative problem-solvers with great language skills. In such a case, you don’t want to feel a language barrier – English is a must.
And again, English proficiency varies from region to region.
Some countries have a great education, some not so much.
Of course, one thing is the language, another is working culture compatibility. America, Europe, Africa, and Asia differ significantly.
Before you make a decision, try to learn those differences and consider if they could pose a threat to smooth cooperation.
7. Pricing models
Software projects are costly and most of them run over budget (up to 50% or more).
For example, an app that was professionally developed within 4-6 months can cost about $100,000 to $150,000.
Of course, you can find cheaper options, especially if you search in regions with lower rates.
But beware, if you go too far, you might suffer serious consequences.
If you choose the cheapest offer, you might become a victim of:
- Technological debt – Poorly written code, difficult to work on or maintain, lack of tests, lack of documentation.
- Restricted source code ownership – You might not own the source code; you might get only a bundled code or the company can offer you to license the product, despite you paying for the development.
- Poor communication – Lack of experience of the offshoring/nearshoring team, poor English level, lack of transparency in the development process.
Fixed Price or Time & Materials?
For many people, fixed-price seems the best pricing model. In theory, it should limit the risk of overspending and ensure complete & timely delivery.
In a fixed-price model (usually paired with Waterfall project management), all business and product decisions, as well as the scope of work, must be decided upon, declared, and contracted before the project starts.
On the other hand, in the Time & Materials model (which is usually employed together with the Agile methodology) the cost is based on actual time spent on a project and an hourly or man-day rate.
The scope is flexible, and changes as business, design, and software teams test and figure out solutions best fitting for the current needs of users.
Let’s compare the key characteristics of these two solutions side-by-side:
- Flexibility of scope:
- Fixed price: low – the exact scope and requirement are decided upon before development starts.
- Time & Materials: higher – project requirements and shape may change constantly in-line with business circumstances.
- Speed of launching a working product:
- Fixed price: depends – the speed of development depends on the quality of specification and scope of the project. If there’s no temptation to change the scope and expertise is available the process can be fast. In the case of long-term projects it’s difficult to evaluate the scope precisely which results in an increased risk of complicating and prolonging the project.
- Time & Materials: varies– there’s no black-and-white answer. The speed depends i.e. on the quality of the specification, however, the team is able to deal with the changes easier and quicker.
- Product-to-market fit:
- Fixed price: depends – product-to-market fit depends on the scope of the project and the quality of its verification.
- Time & Materials: more likely – the product’s new value might be discovered in the process and taken advantage of in the developed application.
- Fixed price: defined upfront, but in some cases negotiable.
- Time & Materials: difficult to estimate, less certain, in some cases development will be cheaper, in others more expensive. However, thanks to the agility of the process the ROI might be higher, and the product might bring more value per spent $).
Which solution will be best for you?
If you want to build a small feature and there is a lot of clarity regarding the requirements and the solution – BOTH will work.
If you want to build a full product for a market that does not shift too much, have all requirements detailed and basically no uncertainties at the start of the project – BOTH might work well.
However, the truth is that you can never avoid changing requirements (at least at a reasonable effort/cost). Meaning that if time-to-market is an important aspect of the project and/or there’s a limited runway, the requirements analysis will never be perfect.
Hence, if you choose a fixed price model, get ready for potential contract/scope renegotiations.
If you want to build a full product, for a frequently changing market, or you’re uncertain of how it precisely works – definitely pick TIME & MATERIALS.
You don’t know the cost, but even if the cost gets higher than originally planned, at least the probability that you get what you actually need significantly increases. If there’s a runway – make sure that the budget is clear for all the parties involved.
If you want to build:
- a small feature and requirements are clear → BOTH solutions will work.
- a full product for a market that doesn’t shift → BOTH might work well.
- a full product, for a frequently changing market → pick TIME&MATERIALS
8. Communication > price
There’s no software development without teamwork, so good relationships and communication are a must.
Businesses seem to agree as one of the most common reasons for IT project failure is ineffective communication.
You and your partner must be prepared for close collaboration, especially when you work in the Agile methodology and Time & Materials model.
How can you verify your potential partner’s culture and style of communication?
When you contact a software agency, you’ll probably talk with salespeople first. You won’t be working with them during development, so you don’t have to be particular about their style of communication. However, they might give you some nice clues about the company itself.
TIP: If the salesperson is pushy and doesn’t seem to listen to you during the conversation it may indicate that the company is focused solely on generating revenue, rather than delivering value and quality to its partners.
On the other hand, a great salesperson doesn’t guarantee a great culture in the whole company.
My advice is – you want to make contact with developers/designers/project managers as quickly as possible, and meet with them in-person/on a call to see what their style of communication and culture is like.
At Brainhub, we run quick 2-3 hours workshops with our potential clients to mainly help them verify their ideas, project assumptions, and requirements, but we also have another goal – checking the culture fit and relationship chemistry.
Yes, you heard well – chemistry. When there is chemistry and both sides are on the same page thanks to extensive, transparent communication, pitfalls can be avoided, and we can pursue our partner’s business success without obstacles.
If companies you’ve found offer similar solutions, be sure to take advantage of them, as they provide tons of valuable information. Any company’s values are always mirrored in employees’ behavior.
When talking with your potential partner, ask yourself:
- Is the way they speak and write polite and professional?
- What is the team’s reaction to your proposed solutions?
- How long do you have to wait for their response/reaction?
Your partner should…
If you want great culture and a great product, look for a company that puts pressure on constantly improving the development process, and values retrospective meetings.
They should be able to clearly articulate their expectations and listen to what you expect of them. It’ll ensure faster and more cost-effective integration.
Avoid yes-sayers. You want to have a straightforward partner who is able to say ‘No’ if needed.
- “No, you shouldn’t make this feature first – it’s a waste of money and your precious time.”
- “No, you should consider different tools…”
Of course, they should be able to say “no” in a polite and professional way.
Your development partner should also strive to understand your business, goals, and challenges. This will help them focus on the right priorities, advise you from the technical perspective, and develop market-fitting solutions.
9. Great process & tools = better product
Based on our experience, most modern IT providers employ similar processes.
Agile development methodology is a standard – 80% of IT teams take advantage of daily standups, sprints, and a similar definition of done.
Many companies finish their weekly/bi-weekly iterations with a review of the product. Thanks to these meetings teams have a sense of urgency and stay more motivated throughout the whole week.
When it comes to tools, you want your team to use:
- online chats, for example, Slack or Mattermost – they’re fast, easy to use, multifunctional, have tons of integrations with other useful apps, and provide natural, instant communication. Forget about uncomfortable, formally looking emails, that get buried easily,
- online call tools, like Google Meet, Zoom, or Skype – used for daily meetings, easy to set up, and accessible on the fly,
- project and bug management tools, like Asana, Trello, and Jira – they will help keep the workflow transparent, focused on the right priorities, and won’t let any issue report get lost,
- file-sharing tools, like Google Drive, Dropbox, Notion – for sharing files and storing important documents necessary in digital product development.
10. Avoid demonetization
Without proper security measures, the well-being of a company can be easily threatened.
Think about Intellectual Property. If your provider doesn’t transfer you the rights to the project, you won’t be able to monetize it or build upon it.
The infographic below demonstrates what project components should be protected and addressed in the contract.
Rights protecting the IP vary from country to country, so do your research about the place you outsource to. Ideally, you should have your own contract or ask the software development agency to send you one to review and consult with your legal department.
Of course, there are more documents and measures your partner and you should take care of before starting the cooperation.
Here’s a short-list of the most crucial ones:
- Non-Disclosure Agreement (NDA) – will protect your trade secrets and confidential information about your business.
- Non-Compete Agreement (NCA) – prevents the outsourced company from revealing your ideas/innovations to the competitors. The idea is that as an agency or a developer can’t enter a partnership with a potential competitor of your client for the agreed amount of time.
- API access – if an API is created, your partner can connect to the ready-made part of the secure software and treat it as a black box without needing to be granted access to the sensitive parts of code.
- Data access – you don’t have to give access to the whole database to developers working on your project, if you want, you can share only an anonymized version of it in the local copy. This gives you control over which data could be taken.
- Server access – to limit access to data, only selected employees should have access to the servers to do the necessary maintenance jobs (updating the application and the database).
- SSL Certificates – authenticate your outsourced developers with secured SSL certificates.
Here’s how to choose…
There are many things to think about when choosing a software development partner.
Here’s the key take away from this article:
Choosing software development company step-by-step
- Remember to have your expectations defined.
- Reject companies with red flags and the cheapest options.
- Avoid cooperation with partners much bigger than your company.
- Try to find as many reliable reviews as you can, pay special attention to bad ones.
- Look up the company’s experience in the field and the number of technologies they work in.
- Find experts in the right technology and avoid “all-knowing experts”.
- Be mindful when choosing the pricing model.
- When choosing companies abroad, think about potential language issues, time zone differences, and cultural mismatch.
- Pay attention to partner chemistry = mutual understanding, polite and professional behavior, and commitment.
- Check if your partner takes advantage of at least basic cooperation tools, such as online communicators, video-call solutions, project and bug-management apps, and cloud file-sharing platforms.
- Make sure the company takes security measures that will protect your intellectual property and your users’ data.
Questions to ask
Below you’ll find the promised bulletproof checklist for verifying software development partners.
→ General questions
- What is your experience working with startups/SMBs/enterprises?
Ask about the size of companies they’ve worked with, ask them to give you examples of projects.
- Have you done any project similar to mine, regarding the industry/technology/product features?
- Could you provide any testimonials/references from your previous clients?
Check clutch.co, have a call with one of the customers, check Facebook reviews, or simply Google it.
- What do your portfolio and previous projects look like?
- What is your company’s vision?
- How would you convince me to choose you and not someone else?
- What is your pricing per man-day? What does it include?
- How fast can you deliver my product?
- Will I own the source code?
- Will the developers assigned to my project work on any other project at the same time?
It is much more efficient when a developer is committed to one project only.
- To what extent will I be involved in the production of the product? Will I be able to approve or disapprove individual stages of the project? Will I have insight into the effects?
- How easy will it be to scale a team by 1/3/5 developers? How much time do you need?
If you plan to scale the team, communicate it to the software development company ASAP. Usually, 1 month should be enough to scale the team.
- Do you also provide support after the project is completed?
→ Process questions
- What values are important to you?
- What methodologies do you work in?
- What is the requirements collection and analysis phase like? Do you organize workshops with the client?
- In what cycles is the increment, MVP, etc. delivered?
- Who will be empowered to make decisions? Is such a person on the client-side or your side? (PO, PM, Analyst, etc.)
- What does the testing, acceptance, and feedback phase look like?
- How involved do I need to be and when (if at all)?
- How will we communicate during a project to know the PPP (progress, plans, problems)?
There must be a mechanism/procedure that ensures you know what’s happening in the project. You must be updated at least on a bi-weekly basis. You need to know when things go wrong.
- How will you ensure we know when things go wrong? Helper question: tell me how you handled a project in the past that went wrong.
First, nobody wants to deliver bad news. Make sure they have a mechanism in place. Second, nobody’s perfect, so there must be a case that went wrong – listen to what they took out of it. Third: no one likes surprises – the best is to be prepared for the challenges.
- What do you expect from us and what should we expect from you during the cooperation?
See what the roles are in the new-forming team. There’s no one way to set it up, but it is good to know what to expect. It’s great to know from the beginning what the scope of responsibilities is for each party.
- What measures will you take to deliver the product that will match our expectations and the market’s as well?
See how they work on figuring out what you really need.
- What collaboration tools do you use during the project?
Tools aren’t that crucial, but it’s great if they use something other than email to communicate and collaborate quickly.
- Do you use an instant communication system?
It is great to communicate often and ask questions just around the time they appear.
→ Technical questions
- How do you ensure software quality?
Check if they use, for example, peer code review or automated tests.
- Do you provide technical documentation?
- Could you provide the profiles of the assigned developers?
They will be anonymized = with no personal/contact data.
- Can I talk to the best-skilled person on your team?
- Tell me how you would solve/build a…
Give an example of a tricky part of your app and ask the potential software development partner how they would approach it.
- What are your best practices for writing code?
E.g. we have it written down as a handbook and use an ESLint company file.