How to choose a software development company

Choosing who builds your software is mostly choosing how your project will behave under pressure: when a requirement turns out to be ambiguous, when a change is needed, when something breaks. The questions below are designed to find that out before you sign.

Decide what you are buying

Different problems need different kinds of help:

• You know exactly what you need and have it written down: you are buying a build.
• You know the problem but not the solution: you are buying analysis first, then a build.
• A project is already in trouble: you are buying an assessment before anything else.
• You need ongoing capacity inside your own team: you are buying people, not a project.

Firms that are excellent at one of these can be poor at another. Be clear which you need.

Agency, freelancer or in-house?

A freelancer can be cost-effective for a contained piece of work, but you depend on one person’s availability, and the specification, testing and documentation are often lighter.

An agency or development company brings a team, continuity and process — at a higher rate. The question is whether the process is real or decorative.

Hiring in-house makes sense when the software is core and permanent and you can attract and manage the people. It is slow to set up and hard to scale down.

The questions that reveal the most

1. How do you scope a project before you quote it? Listen for a written specification and an explicit out-of-scope list. A quote produced after one conversation is a guess.
2. Can I see a specification you have written? Anyone can describe their process; few can show a document.
3. What will I own at the end? The answer should be: the code, the accounts, the credentials and the documentation, in your name.
4. How do you test? Look for automated tests derived from acceptance criteria, not “we test thoroughly”.
5. How are changes priced? Changes are normal. Unpriced, unrecorded changes are how budgets disappear.
6. Who will actually do the work? The people in the sales meeting are not always the people on the project.
7. What happens if you are no longer available? The answer should make you confident someone else could continue.

Red flags

• A fixed quote without questions about your process, your data or your other systems.
• No written scope, or a scope with no out-of-scope list.
• Vague answers about ownership of the code and accounts.
• Demonstrations that only ever use the vendor’s own sample data.
• No mention of testing, environments or deployment.

Writing a request for proposal

If you are going to tender, the quality of the answers depends on the quality of the request. Include your requirements, your current systems and integrations, your constraints, and what is out of scope — and ask each respondent to state their assumptions. Requests that only describe the outcome produce proposals that cannot be compared. Our guide on what drives the cost of custom software explains why.

Local or remote?

Building can be done remotely without much loss. Discovery is different: watching how the work is actually done, in the room with the people who do it, is where the best requirements come from. For a Vancouver or BC business, a team that can be on site for workshops and remote for the build is often the best of both. We are based in Vancouver and work across Canada and the United States.

If you are at the stage of defining what to buy, start with requirements analysis; if you already know, see how we approach custom software.