Guide
How to choose a custom software development company
You are not buying a finished product you can try first. You are choosing the people who will learn how your business works and turn it into software. These are the things that tell a good partner from a risky one, before any money changes hands.
Judge them by their questions
In the first conversation, notice who does the talking. A good vendor spends it asking how the work moves today: who does what, where it gets stuck, what happens when something goes wrong, and which rules exist only in someone’s head.
A vendor who arrives with a solution before hearing the problem is selling what they already have. That can be fine, if what they have fits. Their questions are how you find out.
Ask to see working software
Slides and a list of technologies say little. Ask to see a system they built and still support, running, and ask them to show you the screen that solves a problem like yours. Then ask what they would do differently now. A team that runs its own software in daily use answers that easily.
Get ownership and the way out in writing
These questions feel awkward at the start and matter most at the end. Settle them before you sign.
- Who owns the source code, and who owns the data
- Where the system is hosted, and in whose account
- What documentation you will receive
- How another developer could take over if you ever needed one
- What support costs after go-live, and how quickly you can expect a response
Understand how you will work together
Ask how often you will see working software, and who your contact is from day to day. Ask how a change of mind halfway through is handled and priced, because there will be one. Ask what they need from your team, and when: the time your people spend explaining and testing is part of the project.
Near or far matters less than you think
A company in your own city is easy to visit, but most of a software project happens on screens anyway: calls, shared screens and software you try in your browser. What matters more is whether they will come on site when it counts, such as connecting devices or watching a shop floor at work, and whether they can talk to your team in the language it works in.
Warning signs
Any one of these deserves a direct question. Two or more are a reason to walk away.
- A firm price before anyone has asked how your business works
- Nothing to show you until the very end of the project
- Vague answers about who owns the code and the data
- Everything is possible, and nothing is ever a trade-off
- Pressure to sign before the proposal is written down
Questions
Common questions
Should we choose a company in our own city?
Location helps, but it should not decide. Choose the team that understands your problem and communicates well, then check that they will travel when a project needs someone on site.
How many companies should we talk to?
Two or three is usually enough to compare how each one understands the problem. Compare their questions and their written proposals, not only their prices.
What should a written proposal contain?
The scope in plain language, how the work will be phased, what you need to provide, the cost and how it is worked out, who owns the code and the data, and what support looks like after go-live.
Related