How to Choose a Software Development Company [10 Steps]

Introduction

Sometimes a line between a good and bad software development partner can be really thin – differences lie in mindset (and team), expertise, and process.

Dive in to choose well between various software development companies.

Before starting the research – set your expectations

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.

Consider:

• 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?

Your next step is to look for a company that can do the exact type of work you require (e.g. web development, JavaScript software development, etc.).

Answering these questions will help you narrow your search down significantly and as a result, save lots of time.

Where to look for a software development company?

1. Ask for recommendations.

2 Check out on sites like Clutch, Goodfirms, The Manifest, Design Rush. Look for leaders in their fields and companies with top reviews.

3. Look through various rankings like:

• top custom software development companies,
• top web development companies,
• top React development companies,
• or sites like TechReviewer.

4. Talk to your previous clients.

5. Look through LinkedIn.

<span class="colorbox1" fs-test-element="box1"><p>Check out the detailed comparison of top JavaScript development companies.</p></span>

How to choose a software development company?

There are 10 crucial aspect that make it easier to choose a software development company.

1. 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.

<span class="colorbox1" fs-test-element="box1"><p>Note: Testimonials on the company’s own page might be completely made up.</p></span>

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.

2. 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.

<span class="colorbox1" fs-test-element="box1"><p>Key takeaway: it’s unlikely that a company with 50 developers will be an expert in dozens of technologies at the same time.</p></span>

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. You cannot be an expert in 10 languages (maybe if you are a huge enterprise).

To build a front-end in React, find a company working mainly in React.

You want to have a focused software development partner. They should be experts in the technology in which they work.

3. Check out their process and communication routine

Because great process and tools = better product.

Find a company that puts pressure on constantly improving the development process and values retrospective meetings.

It’ll be a faster and more cost-effective way to integrate your external development team from day one if they can clearly articulate what they expect from you and what you expect of them.

Based on a report from Accenture, communication and quality of service are more important than price for customers today.

Agile development methodology is a standard – 80% of IT teams take advantage of daily standups, sprints, and a similar definition of done.

<span class="colorbox1" fs-test-element="box1"><p>Tip: In Agile methodology, transparency is key so always check what the company’s planning and delivery processes are like.</p></span>

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.

4. Rule of similar sized company

We learned this advice from a book “Built to Sell: Creating a Business That Can Thrive Without You” by John Warrillow.

Choosing a company similar to yours has a few advantages, the most important of them is – You want to be treated as a VIC (very important customer).

If the company is too big, they may not give you enough attention. If they are too small, they may not have enough experience to work on such a scale.

5. Partner chemistry

We strongly believe in relationship chemistry.

We work with our partners (yes, partners, not clients) as closely as possible, discussing the shape of the product.

Once there is chemistry and we are on the same page by having extensive transparent communication, the pitfalls can be avoided, and we can pursue our partner’s business success.

6. Frequent deployment

The company should be eager to show you their progress as soon as possible. Each sprint should be finished with a demo of the product.

It speeds up the development! The developers are motivated to demo weekly/bi-weekly results of their work. They feel the pressure each week. You, as a client, have the same pressure to deliver information/specification/mockups for the following week’s sprint.

Weekly demos are part of the development process and have a huge influence on the quality of the process and speed of development, in our case.

7. A partner who understands the business

As serial entrepreneurs, we’ve learned it’s not all about the code and technology behind your product – it’s about the business.

Your development partner should understand that and challenge the new features you develop, help you focus on priorities, advise you from a technical perspective, and connect with you as partners in their network.

How can you know that a company understands business side of tech projects? For example, they can offer cross-functional teams with Business Analysts and Tech Advisors. It’s also visible in the way they work.

Adapting the BizDevOps culture is a strong indicator of understanding business side of tech projects. The BizDevOps model assumes close cooperation between business and tech.

A company that implemented the BizDevOps model of working will closely cooperate with you as a stakeholder, shortening the feedback loop.

8. Geography

You don’t want to feel a language barrier – English is a must, nowadays. You want to have a software development company as your partner – to advise you, not only to write the code.

Creative problem-solvers with great language skills – those are the guys you look for. Therefore, think twice before deciding to offshore from a country with completely different culture.

Great technology is around 30-40% of a business’s success. Therefore, look for a partner who can advise you, not only write the code.

HackerRank provided a list of countries with top-skilled developers:

9. Contract they prefer – flexibility vs. inflexibility

If you don’t have exact mockups, specification, user stories, project plan, and a well-documented product with a few years of experience building similar products don’t choose the fixed price model.

It will simply cost you more money than time & material based project.

If you choose a fixed price, most of the software development companies will add 25% or more to cover the risk of not knowing the exact scope of the project.

Time & material is the pricing to go with for most projects, since it allows for a lot more flexibility. We explain the difference between fixed price and time&materials later on.

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.

<span class="colorbox1" fs-test-element="box1"><p>Note: not all providers include it in their contracts, so keep an eye out for that!</p></span>

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.

Red flags while looking for an outsourcing partner

There are a few things that should alarm you while assessing a potential software development partner:

Quotes – Reject the cheapest

It’s like buying products on eBay or Amazon – each time when you buy the cheapest iPhone cable, it’s broken after a week or two.

The same with buying services.

If you choose the cheapest offer, you will ultimately pay more at the end of the project.

Why?

There are a few reasons:

• Technological debt – Poorly written code, lack of tests, difficult to work on or maintain, lack of documentation.
• Source code ownership – You don’t own the source code; you will get only a bundled code or the company will 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.

You don’t want to buy the cheapest service, but the most cost-effective. If you focus on spending less money initially, you will pay 2-3x times more in the future (the worst-case scenario – rewrite the app from scratch).

Other red flags

• poor quality website or content,
• vague portfolio descriptions,
• generic testimonials,
• bad reviews on Google.

Other things to consider

Choose your preferred pricing model – 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.

Cost

• 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

Location – onshoring, offshoring, or nearshoring?

There are at least four outsourcing models based on geography, each has its own advantages and disadvantages.

Onshoring

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.

Offshoring

In a nutshell, offshore software development means hiring a team from abroad to do the work remotely and virtually.

Main advantage? It’s affordable.

Nearshoring

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

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.

How to choose a software development company – Checklist

General questions

• How do you work? Tell me more about your process/approach to creating an application.
  Tip: Get a big picture of the approach.
• How do we communicate during a project to know the PPP (progress, plans, problems)?
  Tip: 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-week basis. You NEED to know when things go wrong. Dig deeper using the next question.
• How do you ensure we know when things go wrong? Helper question: tell me how you handled a project in the past that went wrong.
  Tip: 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?
  Tip: 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 is the scope of responsibilities for each party.
• How do you try to deliver the product that will match our and our markets expectations?
  Tip: See how they work on figuring out what you really need.
• What collaboration tools do you use during the project?
  Tip: Tools are not that important; however, it’s great if they use something other than email to communicate fast and collaborate in a group (you + them + anyone interested in the project.
• Will we use an instant communication system?
  Tip: It is great to communicate often and ask questions just around the time they appear.
• Will the developers assigned to my project work on any other project at the same time?
  Tip: It is way more efficient when a developer is committed to one project only.

Technical questions

• How do you ensure software quality? Do they use, for example, peer code review or automated tests?
• Will I own the source code?
  Tip: check the agreement.
• Do you work on technical documentation?
• Could you provide me profiles of the assigned developers?
  Tip: They will be anomyzed – with no personal/contact data.
• Can I talk to the best-skilled person on your team?
• Tell me how you will solve/build a….
  Tip: Give an example of a tricky part of your app and ask the potential software development partner how they will approach it.
• Could you share with me your best practices for writing the code?
  Tip: ex. we have it written down as a handbook and use an ESLint company file.

Business questions

• Why are you better than other software houses? What makes you special?
  Tip: ex. Sometimes, it could be a PM or QA or Senior/Architect Mentoring.
• How easy will it be to scale a team by 1/3/5 developers? How much time do you need?
  Tip: if you plan to scale the team, communicate it to the software development company ASAP. Around 1-3 months should be enough to scale the team.
• What is your pricing per Man-Day? What does it include?
  Tip: ex. Sometimes, it could be a PM or QA or Senior/Architect Mentoring.
• Have you done any project similar to mine, regarding the Industry/Technology/Product Features?
• Could you provide any testimonials/references from your previous clients?
  Tip: Check clutch.co, have a Skype call with one of the customers, check Facebook Reviews or simply google it.
• What is your experience working with Startups/SMBs/Enterprises?
  Tip: Ask about the size of companies they worked with, ask to give you examples of projects.

Process questions

‍

1. What values are important to you?
2. What methodologies do you work in?
3. What is the requirements collection and analysis phase like? Do you organize workshops with the client?
4. In what cycles is the increment, MVP, etc. delivered?
5. Who will be empowered to make decisions? Is such a person on the client-side or your side? (PO, PM, Analyst, etc.)
6. What does the testing, acceptance, and feedback phase look like?
7. How involved do I need to be and when (if at all)?
8. How will we communicate during a project to know the PPP (progress, plans, problems)?
   Tip: 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.
9. 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.
   Tip: First, nobody wants to deliver bad news so make sure they have a mechanism for it 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 – it’s best to be prepared for the challenges.
10. What do you expect from us and what should we expect from you during the cooperation?
    Tip: 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.
11. What measures will you take to deliver the product that will match our expectations and the market’s as well?
    Tip: See how they work on figuring out what you really need.
12. What collaboration tools do you use during the project?
    Tip: Tools aren’t that crucial, but it’s great if they use something other than email to communicate and collaborate quickly.
13. Do you use an instant communication system?
    Tip: It is great to communicate often and ask questions just around the time they appear.