How to choose a software development company

Start with what you need

Before you talk to any company, write one page: who will use the product, what problem it solves, which three or four things it must do, and roughly when you need it. A clear brief makes every conversation shorter and every quote more comparable. It also shows you quickly which companies ask good questions.

Ask to see real work

Look at live products the company built and ask what its role was. Open them on your phone and use them. If possible, ask to speak to a client. A team confident in its work will show it. Be careful of portfolios that only show pictures.

Who will actually build it?

Ask whether you will speak to the engineers and designers doing the work, or only to an account manager. Direct access means faster answers and fewer misunderstandings. Ask who the people on your project are, and whether they stay on it from start to finish.

How will you see progress?

Look for regular demos of working software, not only status reports. Progress you can click through is the best protection against surprises. Ask how often you will see a demo and how changes to the plan are handled.

Who owns the code?

You should. Source code, design files and cloud accounts should be created in your name and handed over with documentation, so you are never locked in to one company. Put this in writing before the project starts.

How do they treat quality and security?

Ask how the team reviews code, tests the product and checks for security problems. Good teams treat these as part of the normal workflow, not an extra at the end. Ask what happens if a serious bug is found after launch.

What happens after launch?

Ask about bug fixes, monitoring, updates and support, and what they cost. A product is never really finished, so agree how it will be looked after, or how it will be handed to your own team.

Working across time zones

Remote teams work well when there are regular calls in overlapping hours, a shared task board and clear written updates. Ask how a team handles this before you start. Teams that have worked with clients in several countries usually have a routine that works.

Red flags to watch for

A few warning signs deserve a pause.

• A price with no questions asked and no plan behind it.
• Pressure to sign quickly.
• No way to speak to the people who will build the product.
• Vague answers about who owns the code.
• No plan for testing, security or support after launch.
• A portfolio the company cannot explain or demonstrate.