How to choose a software development company you can trust

If you're working out how to choose a software development company, you've probably noticed that most of their websites say much the same thing. You only see the real differences when you ask pointed questions, read proposals closely and try working with a team before you sign up for the whole project. That effort matters more than shaving a little off the hourly rate. Pick the wrong software development partner and you can lose months, and sometimes pay to have the whole thing built again.

We wrote this for founders, operations directors and product owners who are outsourcing software development for the first time, or who've been let down before and want to do it differently. We're a software company ourselves, so do read it with that in mind.

What should you decide before you start looking?

A lot of bad choices are made before anyone picks up the phone. If you can't describe what you need, every company will sound convincing and every quote will be a guess. A few hours on the points below will make the rest of the process far easier.

• The problem, in one paragraph. Say who has the problem, what it costs them today and what changes once it's solved. "Our sales team spends two days a month rebuilding the same report by hand" is a better start than "we need a dashboard".
• What success looks like. Pick one or two measures you'd check six months after launch, such as fewer support calls or orders processed faster.
• The must haves for a first release. Split what you need on day one from what can wait. A smaller first version costs less, arrives sooner and shows you what users really want.
• A budget range and a deadline. Even a broad range lets a company suggest a sensible approach instead of guessing. Say whether the date is fixed, because of a trade show or a contract, or just a preference.
• Who decides on your side. Name one person who can answer questions and approve work each week. Nothing slows a project down like waiting for someone to say yes.
• How you want to work together. That could be a fixed project with a clear scope, a dedicated team that works as part of yours, or ongoing care and support. Our guide to software development engagement models explains the trade offs.

How do you build a shortlist?

Aim for three to five companies. With fewer, you have nothing to compare against. With more, choosing becomes a second job. The best places to start are people you know who've launched software recently, and review sites where you can read the full reviews rather than just the star rating.

For each company on your list, look for proof rather than promises:

• Case studies with specifics. Look for what the problem was, what got built, which technologies were used and what changed afterwards. A page of client logos with a vague story tells you very little. You can see how we write ours on our software development case studies page.
• Relevant experience. Your exact industry matters less than similar problems, such as payments, bookings, connecting to older systems, or apps that staff use out in the field.
• A clear description of how they work. You want a published process with named stages and what you receive at each one. If you can't find it, ask.

What questions should you ask on the first call?

You'll learn more on the first call than anywhere else, as long as you pay attention to how people answer as well as what they say. A good company will ask you about as many questions as you ask them. Here are the ones we'd put on your list:

1. Who exactly will work on my project, and will they stay on it? Ask about roles and experience, and whether the people on the call are the people who will build it.
2. How do you turn my idea into a plan and a price? Listen for a discovery step, a written scope and a clear way of handling changes.
3. How often will I see working software? A demo every one or two weeks is normal. A monthly status report with nothing to click on isn't enough.
4. How do you test? You want to hear about automated tests, code reviewed by a second developer and someone whose job is testing. "The developers check it" isn't an answer.
5. What happens when something goes wrong? Ask for a real example of a missed deadline or a bug that reached live users, and what they did next. If they give you a straight answer, that's a good sign.
6. Who owns the code, and where does it live? You want it in a repository (a shared store for code, such as GitHub) that you own and can access from the first week.
7. What happens after launch? Ask about warranty periods, support options and how a handover to another team would work if you ever needed it.

How should you read a proposal?

A proposal is a window into how a company thinks. Read the whole thing, and resist the urge to jump straight to the total at the bottom. A strong proposal usually includes:

• Your problem in their words, which shows they understood it rather than pasting your brief back to you.
• A scope broken into features, listing what's included and, just as important, what isn't.
• Assumptions written down, such as who supplies the content, which systems they'll connect to and what access they need from you.
• A plan in stages, with a rough timeline and what you'll receive at the end of each one.
• The team, described by role and how much of their time goes to your project.
• How change is handled, because every project changes. Look for a simple written way to agree new work and its cost before it starts.
• Risks, named honestly. If a proposal lists no risks at all, nobody has thought hard about your project.

Be wary of a detailed fixed price that lands a few hours after a short call. Nobody can price software they don't yet understand without asking you a lot of questions first.

What are the warning signs to watch for?

One of these on its own doesn't rule a company out. If you spot two or three together, slow down and ask more questions.

• A price far below the others, with no explanation of what's been left out.
• No questions about your users or your business, only about screens and features.
• Pressure to sign quickly, such as a discount that runs out this week.
• Reluctance to put the code in your account, or talk of licensing their "platform" to you.
• No named people, or no chance to meet the team lead before you sign.
• Promises about deadlines before anyone has agreed the scope.
• Slow or vague replies while they're still trying to win you over.

A company is usually on its best behaviour while it's trying to win your work, so treat the sales stage as a preview of the project.

How do you compare quotes fairly?

Quotes are hard to compare because every company assumes different things. One includes testing, design and project management, while another prices only the development. Very often, the cheapest quote is simply the one that leaves the most out. Before you look at any totals, put each quote into the same simple table.

Next, look at how each quote deals with the unknowns. A fixed price gives you a predictable budget when the scope is clear. Time and materials gives you room to change course while the scope is still moving. Each suits different projects, so match it to where yours is. Our guide on how much custom software costs explains what drives the numbers.

Finally, weigh up everything that matters beyond the price. Here's how we'd balance it if we were in your seat.

Example: how much each factor should weigh in your choice

• Quality of questions and understandingVery high
• The team who will actually do the workVery high
• Relevant past workHigh
• Clarity of scope and assumptionsHigh
• Total priceMedium
• Office locationLow

This is a suggestion rather than a formula, so adjust it to suit your project.

Should you start with a paid trial or discovery phase?

If your project is more than a few weeks of work, yes. A discovery phase is a short, paid piece of work before the main build, usually one to two weeks long, and up to four for a large system. The team studies your users and systems, agrees the scope with you and hands you a plan and an estimate you can rely on. Everything it produces should belong to you, so you're free to take it to another company if you'd rather.

It also tells you something no sales call can: what these people are actually like to work with, day to day. Here's how a typical discovery phase runs.

A typical discovery phase

1. WorkshopsGoals, users and rules.
2. ReviewCurrent systems and data.
3. PrototypeClickable key screens.
4. Key stepPlanScope, stages and estimate.
5. DecideBuild, change or stop.

If a full discovery phase feels like too much, ask for a small paid trial instead: one real feature, built and shown to you in a week or two. While it runs, notice the questions they ask and how clearly they keep you posted, and get someone you trust to look over the code.

What should the contract cover?

Your contract doesn't need to be long, but it does need to be clear. Have a lawyer read it, and check these points yourself as well.

• Code and design ownership. It should say that you own all code, designs and documents once they're paid for, including unfinished work if the project stops early.
• A confidentiality agreement. This is often called an NDA (non disclosure agreement). Get one signed before you share anything sensitive about your business or data. A serious company won't make a fuss about it.
• Scope and change process. Include the agreed scope, or a link to it, and how changes get requested, priced and approved.
• Payment terms. Tie payments to stages or to regular periods of work rather than a large sum up front.
• Access and accounts. Your code repository, hosting and third party services should sit in accounts you own, with the company given access to them.
• Warranty and support. Check how long bugs get fixed free of charge after launch, and what support costs after that.
• Leaving. Spell out how either side can end the agreement, how much notice is needed, and what the company hands over: code, documentation, passwords and a short handover session.

A checklist for choosing a software development partner

• We have written down the problem, success measures, must haves, budget range and deadline.
• We have compared three to five companies with relevant, specific past work.
• We have met the people who will do the work.
• They asked good questions and challenged at least one of our ideas.
• The proposal lists scope, exclusions, assumptions, stages and risks.
• We compared quotes line by line, not only by total.
• We have seen how they work through a discovery phase or small paid trial.
• The contract gives us ownership of all code and designs.
• A confidentiality agreement is signed.
• The code, hosting and accounts sit in our name.
• We know what happens after launch and how we could leave.

How does V6 Cube handle this?

You're reading this on our website, so it's only fair to tell you how we handle the same points. Hold us to them, and see our short answers to ten questions to ask any software company. We reply to every enquiry within one business day, and we're happy to sign a confidentiality agreement before you share anything sensitive. Before work begins, we agree a fixed estimate with you. You own all the code and designs we produce. Once we've agreed, projects usually start within one to two weeks.

We've worked with clients in more than 40 countries since 2017, with teams in four regions covering 24 time zones. You can work with us on a fixed project, as a dedicated development team that joins yours, or through ongoing care and support. Read how our software development process runs from first call to launch, or browse our software development services. If you'd like us on your shortlist, tell us about your project and we'll ask you the questions this guide says a good company should.