How to choose a custom software development company: 12 questions

Search for "custom software development company" and you will get hundreds of results that say the same things: agile, scalable, client-first, on time. The websites cannot tell you which team will still answer the phone six months after launch. A short call with the right questions can.

These are the twelve questions we would ask if we were hiring a software company ourselves, what a good answer sounds like, and what should make you walk away.

Shortlist three, ask all twelve questions of each, and compare the answers side by side.

About their work

1. Can we see something similar that you built and that is live now?

A good answer is a link to a working product, or a screen share of one, with an explanation of what was hard about it. Screenshots and a list of logos are weaker. If their best example is a very different kind of product from yours, ask how they would handle the parts they have not done before.

2. Can we speak to a client you worked with over a year ago?

Recent clients are still in the honeymoon period. Someone who has lived with the software for a year can tell you about bugs, support and how changes were handled.

3. Who will actually work on our project?

You want names and roles, and ideally a short call with the lead developer. Be careful when the people in the sales meeting are not the people who will build it, and nobody can say who will.

About how they work

4. What happens in the first two weeks?

Look for a concrete discovery process: workshops to map your process, a written scope, rough screens, and a plan broken into milestones. A team that wants to start coding on day one will be guessing at what you need.

5. How often will we see working software?

Every one or two weeks is a good answer, on a test link you can click through yourself. Monthly demos, or "at the end", leave too long for misunderstandings to grow.

6. How do you handle a change in scope?

Changes will happen. You want a clear written process: the change is described, estimated, and approved by you before anyone works on it. Be wary of both extremes, a team that says yes to everything for free and a team that bills for every small clarification.

7. How do you test before release?

Listen for automated tests on the parts that matter, a staging environment that mirrors production, and a checklist before each release. "Our developers test it" on its own is not enough for software your business depends on.

About ownership and after launch

8. Who owns the code, and when do we get it?

You should own the code you paid for, have access to the repository throughout the project, and hold the admin credentials for hosting, domains and third-party accounts. Any hesitation here is a serious warning.

9. What does support look like after launch?

Ask how long bugs are fixed for free, how quickly they respond to an outage, and what a monthly support plan costs. Get the response times in writing.

10. What happens if we want to move to another team later?

A confident company will say the code is documented and standard enough that another team could pick it up. If the answer involves a custom framework only they understand, you would be locked in.

About money

11. Can you break the quote down by feature?

A breakdown lets you cut or delay features sensibly if the total is too high. A single number with no detail hides the assumptions, and those assumptions are where disputes start.

12. How are payments tied to progress?

Milestone payments linked to working, tested software are fairer to both sides. Be careful with requests for 50 percent or more up front on a large project.

Red flags that should end the call

• They quote a firm price before understanding your process.
• They agree with everything and ask very few questions.
• They cannot show you live work or put you in touch with a past client.
• They are vague about who owns the code.
• The price is far below every other quote without an obvious reason, such as a smaller scope.

Comparing your shortlist

Pick three companies, send all three the same written description of what you need, and ask each for a quote broken down by feature. Then ask all twelve questions on a call. Score the answers side by side. The cheapest quote is rarely the one with the best answers, and the most expensive one is not automatically better either.

We are happy to answer all twelve for our own work. Send us your description and we will start with the discovery questions we would need answered before quoting.