Ten questions to ask when choosing a software company

When an organisation looks for a software company, it usually ends up with three or four proposals. The prices differ and so do the timelines, but the texts are very similar. They all say “agile methodology”, “scalable architecture” and “end-to-end solution”.

These words do not set one company apart from another. What does is the answers to the questions asked at the first meeting. In this post I list those questions. As a software company we are asked them too, and we want to be.

1. How do you work out the scope?

A good company does not name a price at the first meeting. It first tries to understand what needs to be built. Who will use it, how the work is done today, which systems it needs to talk to, what data it will handle.

A price given without answers to these questions is not an estimate. It is a hope. If the proposal does not say how the scope was worked out, ask.

2. Do you write down what you don’t know?

Every project starts with unknowns. How much data will come from the old system, whether an integration’s documentation is up to date, how users will react to the new screen.

A company that states these openly in its proposal is showing you where the risk is. A proposal that buries them all inside a fixed price makes the risk invisible. The risk does not go away. It just surfaces later.

3. How will we decide the delivery is accepted?

Most disputes in software projects come from the question “does it work?”. The reason is not technical. Nobody wrote down at the start what “works” means.

Ask this question yourself. For every feature, it should be written down when it counts as done. We cover this in detail in our post on acceptance criteria.

4. How often will we see something working?

Not seeing software for six months when it is due in six months is the breeding ground for the most expensive misunderstandings. Ask to see a clickable version at regular intervals. Every two weeks or every month, but regularly.

5. Who will keep the source code and intellectual property?

The contract should give a clear answer to this. Is the source code transferred to the organisation, or is only a licence to use it granted? What happens if the company closes down or you part ways?

If the answer is not written down, the day you want to change company you may be left with nothing but a running program.

6. Who will look after it after delivery?

Software is not finished on the day it is delivered. Operating systems get updated, security flaws turn up in libraries, users bring new needs. Ask about the scope, duration and price of maintenance at the proposal stage. How quickly a fault will be dealt with should also be in writing.

7. How do you protect the data?

If the software will process personal data, you can tell at the first meeting how the company approaches that data. Is it logged who accesses which data? Where are the backups, which country are the servers in, who are the subcontractors?

If a company answers these questions with “don’t worry”, move on to one whose answers are concrete. Data security is an obligation the law places on the data controller. Having someone else build the software does not remove that obligation.

8. Who will work on the project?

The person who comes to the sales meeting may not be the person who writes the code. That is natural. But you will want to know who will work on the project, who will make decisions and who will answer you. A company that introduces its team by name finds this question easy to answer.

9. How did you do similar work before?

Instead of a reference list, ask them to talk you through one project. Where did they struggle, what did they change, what was the result? A company that can describe the hard part of a project has really done it.

They may not be able to name the client for confidentiality reasons. That is normal. But they should be able to describe the process.

10. Is there a reason we shouldn’t do this project?

The last question is a little unusual, but it tells you a lot. A good company sometimes says “you don’t need custom software for this, this off-the-shelf product will do the job”. Sometimes it says “this scope won’t fit this budget”. Hearing this shows you are talking to someone who tells the truth even at the cost of losing the work.

We look at the choice between an off-the-shelf package and custom software in a separate post.

How much does being nearby matter

For an organisation in Ankara, working with a software company in Ankara is an advantage, but not a requirement. A few face-to-face workshops in the first weeks help the scope get understood faster. So does looking at a system in use on site together.

After that, what matters is not distance but how orderly the communication is. Keeping decisions in writing, seeing regular versions and getting answers on the same day do more good than being in the same building.

In short

What sets a software company apart is not the price in its proposal but its answers at the first meeting. A company that gives concrete answers on scope, acceptance criteria, source code, maintenance and data security will also work concretely throughout the project.