How to choose a software development company: 12 questions

To choose a custom software development company, ask it twelve specific questions before you sign and judge the answers rather than the sales deck: how it scopes your needs, how it sets the price, who writes the code, what happens after launch and how you could leave. A good company answers with facts you can check. A vague answer on any of these points should count as a no.

"Top 10 software companies" lists rarely help: most are published by agencies or by directories selling placement, and the order reflects that. What follows is a set of questions, each with the answer that should reassure you and the one that should worry you. It applies to any vendor, including us.

First, know what you are buying

A software company can sell you three quite different things: time (time and materials, billed by the hour or day), an outcome at a fixed price, or the use of software it runs for you on a subscription. The same application can be bought any of these ways, with the risk sitting in very different places. If that distinction is not clear yet, read our comparison of fixed price and time and materials before the first call: half of the questions below depend on it.

If you have not yet decided between a company, a freelancer or a no-code tool, that choice comes first. We cover it in a separate article.

Method: how the company understands your problem

1. How will you scope the project before pricing it? A good answer names a concrete step: workshops, a prototype, a written scope document. A bad one is a price on the first call. Nobody can price a business application seriously without knowing its rules, and a figure given too early tends to come back as change requests.

2. What will I see before I pay for development? A mock-up, a clickable prototype, screens with realistic data: something your users can look at and criticise. It is the best way to check that the company understood your business and to know exactly what the price covers. The differences between mock-ups, prototypes and MVPs are explained in this guide.

3. Do you deliver in one block or in usable stages? Regular releases you can actually use let you correct course early. A project that shows nothing for six months puts all the risk on its last week.

Price: what you will really pay

4. Is the price fixed, or an estimate billed on time spent? Both models are legitimate, but they are not the same contract. A "fixed price" expressed as an estimated number of days is often time and materials in disguise: ask what happens when the days run out.

5. What happens when I ask for a change? A good answer describes a process: the change is priced, you accept it or not, then it is scheduled. A bad answer is "we will sort it out". Changes are normal; what costs money is changes that are never priced.

6. What is not included? Hosting, maintenance, data migration, training and connectors to your existing tools can each be included or quietly left out. Our method for comparing software quotes and our article on what drives the cost of a custom business application give you the full grid.

Team: who works on your project

7. Who will write the code, and where? In-house, subcontracted or offshore: you need to know, because that person is the one who will understand your application a year from now. The answer belongs in the contract. If you are comparing vendors across borders, our guide to outsourcing to a European studio lists what else to check.

8. Who is my contact, and who makes decisions on your side? A project manager relaying everything to a team you never meet, or one person who understands both your business and the technology: both can work, with very different levels of friction.

Code and technology: what you will be able to do with it

9. Which technologies, and why? A standard, documented, widely used stack means another team can take over. A proprietary framework or a closed platform ties you to the vendor. Ask whether another team could pick up the code, and how.

10. Who will own the code, and what will I be allowed to do with it? The answer depends on the contract and must be written there. Under US copyright law, software written by an outside contractor is generally not a "work made for hire", and a transfer of ownership must be in writing and signed (17 U.S.C. §§ 101 and 204). We cover the UK, US and French rules in our article on source code ownership. At LPR Studio, the rights depend on the model you choose and are defined case by case in the contract.

After launch: operations and exit

11. Who hosts, monitors and updates the application? A business application has to be backed up, monitored and patched for as long as it is in use. Ask who does it, at what cost and how fast they respond to an incident.

12. If we stop working together, what do I get back? The code, your data in a readable format, access to the hosting accounts, the documentation: that list should exist before you sign, not at the moment you part ways. A company confident in its value has no reason to dodge the question.

The grid at a glance

When a software company is not the answer

Hiring a company is not always right. If an off-the-shelf product already covers most of your needs, configuring it will cost less. If you already have an in-house team that only lacks capacity, a short-term contractor may be enough. And for a throwaway tool used by three people for a few weeks, a no-code tool often does the job. A good vendor will tell you so.

Where to start

Send the same description of your need to two or three vendors, ask them these twelve questions and compare what they show you rather than what they promise. At LPR Studio, our first answer is a free visual prototype, presented in a video call within 5 working days: you judge how well we understand your business before any discussion of price. Our three models and our approach are described on the home page.