10 Questions to Ask Before You Hire a Software Development Company

Choosing a software development company is a bit like hiring a contractor to build a house you can't yet picture. You're going to spend a lot of money, and most of what you'll be shown at the start is a presentation. The portfolio looks good, the proposal looks confident, and every firm says it's committed to quality.

The way to tell them apart is in the details of how they answer. Here are ten questions that tend to separate teams who have done this many times from those who are still learning on your budget.

1. "Who exactly will work on my project?"

The people in the sales meeting are often not the people who write the code. That's fine, but you should know who is. Ask for names and roles: who leads, who designs, who builds, who tests. Ask how many of them are employees and how many are subcontractors.

Also ask whether the team changes mid-project. A product built by four different people over six months tends to read like it.

2. "Can I speak to a client with a similar project?"

Case studies on a website are written by the vendor. A phone call with a real client is not. Ask for one or two references, ideally with a project of similar size, and ask them what went wrong and how it was handled. Every project has a rough patch. How it was dealt with tells you more than how smooth it was.

3. "What do you need from me, and when?"

Delays blamed on developers are often delays waiting for decisions, content, logins or approvals from the client. A good team tells you this up front: you'll need to review designs within two working days, supply sample data by week three, and nominate one person who can say yes or no.

If the answer is "nothing, just relax", be a little careful. That is rarely how it works.

4. "How do you handle changes once we've started?"

You will change your mind. Everyone does, because seeing something real teaches you things a document couldn't. So the question isn't whether changes happen, it's what they cost and how they're agreed.

Look for a simple process: the change is described, its effect on cost and time is stated, and you approve it before work begins. Be wary of both extremes, "we never charge for changes" and "every change is a new quote".

5. "What is not included in this price?"

This one question saves more money than any negotiation. Ask directly about:

• the admin panel (you will almost certainly need one)
• testing and bug fixing after delivery
• hosting, domain and third-party services such as SMS or payments
• content migration from your current system
• training for your staff
• support after go-live

A proposal that lists exclusions clearly is usually more trustworthy than one that says "everything included".

6. "Who owns the code and the accounts?"

The correct answer is that you do, from the moment you've paid, and that everything runs in accounts under your name. Anything vaguer should be clarified in writing before you sign. We wrote a separate piece on this: who owns your software.

7. "How will I see progress?"

"We'll keep you updated" is not a process. Ask what you'll actually see and how often. Good answers sound like a working version you can click through every one or two weeks, a shared board where you can see what's done and what's next, and a short regular call.

If the first time you see the product is the final delivery, you've taken on all the risk.

8. "How do you test, and who does it?"

Ask whether there is someone whose job is testing other than the person who wrote the code. Ask what happens before a release goes live and how a bad release is rolled back. You don't need technical detail, you're listening for whether there is a routine or whether testing is "we check it before sending it".

9. "What happens after launch?"

Software needs looking after. Servers need updates, certificates expire, a payment provider changes its API. Ask what support looks like, how fast they respond to a serious problem, and what it costs. We explain what to budget in what software maintenance costs.

10. "What would you leave out?"

This is the best question on the list. A team that says yes to every feature is selling. A team that says "we'd drop these three for version one, and here's why" is thinking about your business. It's also a sign they've seen what happens when first versions are too big.

Reading the answers

You are not looking for perfect answers. You're looking for specific ones. "We usually do two-week cycles and you'll see a working build at the end of each" is specific. "We follow best practices and agile methodology" is not.

Also notice who asks questions back. The firms worth hiring tend to ask about your customers, your numbers and your deadline before talking about technology.

If you'd like to prepare before those conversations, our guide to preparing software requirements will help you walk in with a clear brief. And if you'd like to talk to us, we're happy to answer all ten of these on a call: get in touch.