How to choose a software company: 10 questions for the first meeting
When choosing a software company, what really matters is how well they understand your business, how clearly they write down the scope, and how plainly they explain what happens after delivery. The surest way to find out is to ask the right questions in the first meeting. The ten questions below will help you get to know both the company and your own project better.
We are a software studio too, and we are asked most of these questions ourselves. We are glad of it. Projects with clients who ask questions usually end with fewer surprises.
Why one criterion is not enough
Most companies judge a software firm on two things: price and portfolio. Both matter. Both can also mislead on their own.
- Price cannot be compared unless the scope is the same. Two proposals for the “same” job may in fact describe two different jobs.
- A portfolio shows what was made, not how it was made. Behind a handsome screen there may be a structure that is hard to maintain.
So think of the meeting not as a presentation but as a two-way examination. Whilst you try to understand the company, a good company is trying to understand you. A team that asks no questions and says “yes, we can do that” in the first minute may not yet have seen the hard part of the job.
Ten questions to ask in the meeting
1. “Could you describe our business in your own words?”
Ask this at the end of the meeting. If the company can explain your need back to you more simply than you put it, you are on the right track. If it cannot, the code it writes will very likely solve a different problem.
2. “Have you done similar work before? Can I see it live?”
Ask for a live product or a published site rather than screenshots. A live reference shows speed, usability and whether it is still being maintained. Most of our own work — such as Meta Cty, our sales automation platform — can be reviewed live; that is a deliberate choice.
3. “How do you write the scope?”
A good proposal states, point by point, which screens, which user roles and which integrations will be built. More importantly, it also states what is out of scope. We cover this in detail in how to read a software proposal.
4. “How do you break the work into parts?”
Delivering a large project in one go is risky. In a process that moves forward piece by piece, you have something working at the end of each stage. If something is going wrong, it shows early. Ask what the first delivery will be, and why they would start there.
5. “Who will own the source code?”
This is the question that causes the most arguments later. Will the source code be handed over to you? If so, at what stage? Is documentation included? We hand over the source code at delivery on request. Whichever model is chosen, it must be in writing.
6. “Will you sign a non-disclosure agreement?”
If your idea, your customer data or your internal processes are sensitive, you can ask for an NDA before going into detail. It is an ordinary request, and we sign one when asked. A company that avoids an NDA or brushes the subject aside may show the same ease later in matters involving your data.
7. “Who will write it, and who will I be talking to?”
The person in the meeting and the person doing the work may be different. That is not a problem — but you should know. Who will be your contact throughout the project, and who will answer a technical question? And how quickly will you hear back? With us it is within two business days at most; what matters for you is that the timeframe is stated at the outset.
8. “What happens after delivery?”
Software does not end at delivery. There will be security updates, small bugs and new needs from users. Ask whether the company offers monthly maintenance, what it covers and what happens in an emergency. If maintenance is never mentioned, you may find yourself on your own when the first problem appears.
9. “Where will the software run, and where will the data live?”
In the cloud or on your own server? In whose name will the domain and server accounts be opened? Is the data backed up? If you process personal data, these questions are not only technical but legal as well. Having the accounts opened in your name makes life easier should you ever want to change company.
10. “What happens if the scope changes?”
There is hardly a project that does not change. A good company knows this and tells you at the outset how change requests will be handled: the new request is described in writing, its impact is discussed, and it is done after approval. That rule protects both sides.
How to weigh the answers
Once you have asked the questions, look at the manner of the answers as well as the content.
| Good sign | Warning sign |
|---|---|
| They ask you questions and try to understand your flow | They say “we can do that” to everything in the first minute |
| They give the scope in writing, point by point | They give a single total figure on one line |
| They say clearly what is out of scope | They say “we’ll talk about the rest later” |
| They show live references | They share only screenshots |
| They put source code and maintenance in writing | They skate over these subjects |
| They suggest a packaged product for some jobs | They suggest writing everything from scratch |
The last row matters. An honest software company will sometimes tell you that your work does not need custom software. For standard work such as accounting or email marketing, a packaged product often makes more sense. To make that call, see the six questions in off-the-shelf or custom software.
How to prepare for the meeting
Being ready for the company’s questions matters as much as asking your own. The better the preparation, the more accurate the proposal.
- Write down today’s flow. How does the work run today? Which spreadsheets, which programs, which manual steps?
- Mark where it gets stuck. Where is the most time lost? Where do mistakes happen most often?
- Decide who will use it. How many roles are there, and who should see what?
- List the systems to connect. Accounting, payments, messaging, CRM.
- Separate the essentials. Put what version one must have and what can come later on two separate lists.
Share this list before the meeting, and the first conversation becomes a working session rather than an introduction.
A concrete example: order tracking
Picture a wholesaler. Orders come in by phone and message, are typed into a spreadsheet by hand and then entered again into the accounting program. Suppose that, in the meeting with a software company, it asks: “Could you describe our business?” and “What will the first delivery be?”
A good answer sounds like this: “Today the same order is written down twice, and that is where the errors come from. In the first phase, let’s move order entry onto a single screen and send it to accounting automatically. Reports and a customer panel can come in the second phase.” That answer shows the company has understood the problem, prioritised the work and kept the risk small.
A weak answer goes: “Let’s set up a full ERP system for you.” It may even be right. But a big solution offered before the problem is understood usually ends in big disappointment.
Frequently asked questions
What is the most important criterion when choosing a software company?
There is no single one, but we put “understanding your business” first. If a company has not understood your need, however strong its technical skill, it will do the wrong thing well. Having the scope in writing and talking through what happens after delivery come close behind.
How many companies should I get proposals from?
Talking to a few companies helps you understand your own need better. What matters is not the number but comparing proposals on the same scope. That is why giving every company the same list of needs works.
A freelancer or a software company?
For small, one-off jobs, an independent developer may be enough. If maintenance, continuity and an orderly handover of source code matter, a team that commits to these in writing is the safer choice. Whichever you choose, the ten questions above apply just the same.
How can I judge a company’s technical ability?
Look at a live product; try its speed and how it handles. Ask the company to explain why it made a particular architectural decision. A technically strong team can explain a complex subject simply.
You are welcome to put these questions to us about your own project. We describe what we do and how we work on our custom software and SaaS page; or, if you prefer, write to us with a short outline of what you need.