On this page
To choose a software development company, check three things before you compare prices: software of theirs that runs in production and that you can open, who will own the code and the accounts, and how they release changes without breaking what works. Then look at the people, the hours you share, the contract and the price. A company that passes the first three rarely fails on the rest; a company that cannot show them is a risk at any price.
This guide turns that into twelve checks you can run yourself, in calls and in writing, with what a good answer sounds like and how to verify it. It ends with a scorecard to put two offers side by side. It applies whether the company is in your own city or in another country; for the questions specific to working across borders, see nearshore vs offshore and, for US buyers, outsourcing to Europe from the US.
Before you talk to anyone
Write down what you need. Not a full specification, but the process today, who will use the software, the systems it must talk to, and a few real examples: an export, a spreadsheet, a form. Send the same description to every company, so their offers answer the same question. Our software requirements template holds those questions with room for your answers.
Decide also what you will not compromise on: hosting in the EU, a language your users need, a deadline that is real, a budget ceiling. Say them in the first call.
The work: checks 1 to 3
1. Software of theirs that runs today. Ask to see a platform they built, live, in the call: logged in, with demo data, the way users see it. A portfolio of screenshots shows design; a running system shows that they deliver and keep it running. Ask how long it has been live and how many people use it.
2. A client who uses it every day. Ask for one reference you can call, not an email address that answers with a paragraph. Ask the client what happens when something breaks, and how fast.
3. The repository from the first commit. The code should live in a repository in your organisation, or be mirrored to it, from day one. A company that hands over the code at the end, or after the final payment, holds your project hostage, even with good intentions.
The engineering: checks 4 to 6
4. Accounts in your name. Domains, cloud accounts, app store accounts, email services: in your company's name, with the supplier invited as a user. Moving them later is slow and sometimes impossible.
5. How a release goes. Ask them to describe the last release: was there a backup before it, how long was the system unavailable, how would they have gone back? A good answer names the steps and the seconds. On the transport platform we run, a release switches over in 2 to 6 seconds with a backup and a way back.
6. Automated tests. Ask how much of the core logic is covered by tests that run on every change. Not every screen needs a test; the rules your business depends on do.
The people: checks 7 and 8
7. The builders are in the calls. Ask who will write the code, and make sure they are in the second call at the latest. Layers of account managers between you and the developers add delay and lose detail.
8. Enough shared working hours. Two shared hours a day is workable with a disciplined written process; six to eight is working as one team. Check the overlap for your city and theirs in our time zone overlap calculator, including the weeks when daylight saving differs.
The contract: checks 9 to 12
9. Intellectual property and law. The contract should assign all intellectual property in what is built for you, in writing, and say which law applies and which courts decide. In Europe ownership of software moves by assignment, not by the US idea of work made for hire. Our software development contract template lists the clauses.
10. Data. Where will the software and its backups be hosted, and is there a data processing agreement? For personal data of people in the EU, the GDPR asks for both.
11. How changes are priced. Every project changes. Ask how: a new line with its own price, agreed before work starts, or more hours on the next invoice?
12. After go-live. Who keeps it running, how fast do they respond to a problem, what does that cost, and how do you leave if you want to: documentation, access, a handover?
Twelve checks, two offers side by side
1. Software of theirs you can open, running today
Offer A: cheaper hourly rate: screenshots only
Offer B: fixed price per module: two live platforms, shown in the call
2. A client you can call who uses it every day
Offer A: cheaper hourly rate: references by email
Offer B: fixed price per module: meets it
3. The repository is yours from the first commit
Offer A: cheaper hourly rate: handed over at the end
Offer B: fixed price per module: meets it
4. Cloud accounts and domains in your name
Offer A: cheaper hourly rate: their account, transfer on request
Offer B: fixed price per module: your account
5. Releases with a backup and a way back
Offer A: cheaper hourly rate: not described
Offer B: fixed price per module: written down per release
6. Automated tests on the core logic
Offer A: cheaper hourly rate: missing
Offer B: fixed price per module: meets it
7. The people who build are in the calls
Offer A: cheaper hourly rate: an account manager
Offer B: fixed price per module: meets it
8. Enough shared working hours
Offer A: cheaper hourly rate: 2 hours
Offer B: fixed price per module: 7 hours
9. Written assignment of all IP, clear governing law
Offer A: cheaper hourly rate: IP on full payment
Offer B: fixed price per module: meets it
10. Hosting region and processing agreement
Offer A: cheaper hourly rate: region not stated
Offer B: fixed price per module: EU, agreement attached
11. Changes priced before work starts
Offer A: cheaper hourly rate: billed by the hour
Offer B: fixed price per module: a new line per change
12. Support and exit after go-live
Offer A: cheaper hourly rate: support undefined
Offer B: fixed price per module: response time and exit written down
Both offers are invented to show the scorecard at work. The empty scorecard is in the text above: copy the rows and score your own shortlist.
A scorecard for your shortlist
Score each company on every check: 2 when they meet it and showed it, 1 when they meet it on paper, 0 when they do not. Weigh the first three double.
| Check | What a good answer looks like | How you verify it |
|---|---|---|
| 1. Software running today | a live system shown in the call | log in, click through, ask how long it has run |
| 2. A daily user to call | a name and a number | call and ask about the last incident |
| 3. Repository from day one | your organisation, from the first commit | ask for access in week one |
| 4. Accounts in your name | domain and cloud registered to you | check the registrar and the cloud billing |
| 5. Releases | backup, downtime in seconds, a way back | ask for the release notes of the last change |
| 6. Tests | the core rules covered and run on every change | ask to see the test run |
| 7. Builders in the calls | the developers in the second call | name them in the contract |
| 8. Shared hours | enough for your way of working | calculate it for both cities |
| 9. IP and law | written assignment, named law and courts | read the clause |
| 10. Data | hosting region and processing agreement | ask for the agreement before signing |
| 11. Changes | priced before work starts | ask for an example of a change and its price |
| 12. After go-live | response time, cost, exit | read the support terms |
Red flags
| Red flag | What it usually means | What to ask instead |
|---|---|---|
| A price before questions | the estimate is a guess, and you will pay for the guess | "What do you need from us to price this per module?" |
| No live work to open | delivery or upkeep is not their strength | "Can you log in to a system you built and show it?" |
| The code arrives at the end | your project depends on their goodwill | "Can we create the repository in our organisation today?" |
| Everything is possible | nobody has thought about scope, time or budget | "What would you leave out of the first version?" |
| Only an account manager in the calls | details get lost between you and the builders | "Who writes the code, and can they join the next call?" |
| A best-of list with themselves on top | marketing, not evidence | "Who can I call that uses your software every day?" |
Comparing the prices
Only now look at price. Hourly rates differ by country and by what the hour includes; see developer rates by country. A fixed price per module shows who believes their estimate: it puts the risk on the supplier. Compare the price of the same modules, add your own time as product owner, and check what is included after go-live. What custom software costs per type of project is in custom software development cost.
Choosing a supplier, briefly
How do I choose a software development company?
Ask to see software of theirs running in production, make sure you own the code and accounts from day one, and check how they release changes. Then compare people, shared hours, contract and price.
How many companies should I ask for a quote?
Three is usually enough: send each the same written description, so the offers answer the same question.
Should I choose a fixed price or time and materials?
A fixed price per module suits work you can describe; the supplier carries the estimate. Time and materials suits work that changes every week, with someone on your side deciding priorities.
Is a software company abroad riskier?
Not by itself. The same twelve checks apply; add shared working hours, governing law and where your data is hosted to the questions.