On this page
Choosing a software development company is one of the highest-leverage decisions a founder, CTO or product leader makes. A good partner ships a product you can grow for years. A poor one leaves you with a codebase nobody wants to touch, a missed launch and a budget spent twice.
Most vendor websites look alike, and most proposals promise the same things. This checklist is about the questions that actually separate partners, the red flags to watch for, and how to compare proposals so you are not simply choosing the lowest number.
Start with your own brief
You cannot compare partners fairly until you know what you are asking for. Before you contact anyone, write one or two pages that cover:
- The problem. Who has it, how they solve it today and what it costs them.
- The first release. The smallest version that is useful to real users.
- Constraints. Deadlines, budget range, compliance requirements, systems you must integrate with and technology you must keep.
- What happens after launch. Whether you will build an in-house team, keep the partner, or need both.
A clear brief gets you comparable proposals. A vague one gets you guesses.
Questions to ask every candidate
Who will actually do the work?
Ask to meet the engineers and the technical lead who would work on your project, not only the sales team. Ask about their experience with problems like yours. If a company cannot tell you who would be on your team, you will find out after you sign.
How will we see progress?
Good partners show working software early and often. Ask how often you will see a demo, what you will receive between demos, and whether you will have access to the task board, the repository and the deployment pipeline. Weekly demos of working software are a reasonable expectation.
Who owns the code and the accounts?
You should own the source code, designs, documentation and every cloud, app store and third-party account. The simplest arrangement is that the partner works in your repositories and your cloud accounts from day one, so there is nothing to hand over later. Be cautious of anyone who wants to host your product in their own accounts without a clear exit plan.
How do you handle changes in scope?
Scope will change. Ask how change requests are estimated and approved, and ask for an example. In a fixed-scope engagement, the answer should be a written estimate for each change. In a dedicated-team engagement, it is usually a re-prioritized backlog.
How do you test and deploy?
Ask what automated testing they write, how code is reviewed, and how a change gets from a developer’s laptop to production. You are listening for code review on every change, automated tests for important logic, and an automated deployment pipeline rather than someone copying files to a server.
What happens if someone leaves?
People change jobs. Ask how the partner documents the system, shares knowledge across the team and replaces an engineer without losing momentum.
How do you handle security and privacy?
If you handle personal, health or payment data, ask how they would approach HIPAA, SOC 2, GDPR, PIPEDA or the Australian Privacy Act, whichever applies to you. A credible partner talks about access control, encryption, audit logging and keeping real personal data out of development environments, not only about “security best practices.”
Red flags
- A firm price before they understand the problem. A detailed quote after a 20-minute call is a guess, and the gap is usually recovered later through change requests.
- No access to the code until the end. You should see the repository from the first week.
- Everyone is “senior.” Ask for real experience and examples. A team with no junior members at all is unusual.
- No questions about your users or business. Partners who only ask about features tend to build exactly what was written down, including the mistakes.
- Reluctance to start small. A good partner is comfortable proving themselves on a discovery phase or an MVP before a large commitment.
How to compare proposals
Proposals are hard to compare because each vendor makes different assumptions. Put them side by side on the same points:
| Question | What to look for |
|---|---|
| What exactly is in scope? | A feature list with acceptance criteria, not a paragraph |
| What is out of scope? | An explicit list, including hosting and licences |
| Who is on the team? | Named roles and seniority, and time allocation |
| How is the price structured? | Fixed scope, monthly team or time and materials |
| What are the risks? | Honest assumptions about integrations and unknowns |
| What happens after launch? | Support, maintenance and handover options |
The cheapest proposal is often the one with the most unstated assumptions. Ask each vendor to list what they have assumed, and the numbers usually move closer together.
Choosing an engagement model
There are three common ways to structure the work:
- Fixed scope gives you cost certainty for a well-defined piece of work, such as a discovery phase or an MVP.
- A dedicated team works full time on your product under your priorities, billed monthly. It suits products that will keep evolving.
- A retainer covers maintenance, support and advice for a live product.
Many companies start with a fixed-scope discovery or MVP to test the relationship, then move to a dedicated team. Our pricing page explains each model and typical budget ranges, and our cost guide covers what drives the number.
Working with a partner in another country
Many companies in the US, Canada and Australia work with offshore partners to reach senior talent faster and at a lower cost. It works well when the partner is clear about time-zone overlap, communication, data residency and contracts. We cover each of these in our guide to outsourcing software development to India.
Next step
If you have a brief, or even half of one, send it to us. A senior engineer will read it, ask the questions above in reverse and tell you honestly whether we are a good fit.
