How to choose a software development company: 10 questions to ask

Short answer: look past the portfolio and ask how the team works. The right partner explains how they will understand your business, shows you working software every week or two, puts the scope and payments in writing, gives you ownership of the code and has a plan for after launch.

Custom software is an investment your business will depend on for years. Most projects that go wrong do not fail because of the technology. They fail because of unclear scope, poor communication or a contract that left the client without control. The ten questions below help you see how a team really operates, and the sections after them show you how to prepare, compare proposals and spot red flags.

Before you talk to anyone: prepare a one-page brief

You will get better answers, and more comparable proposals, if every company receives the same information. One page is enough.

• The problem: what is slow, manual, costly or impossible today.
• The users: who will use the software (staff, customers, partners) and roughly how many.
• Must-haves for version one: the few features without which the product is useless. Keep “nice to have” in a separate list.
• Connections: systems it must talk to, such as your accounting software, CRM, payment provider or website.
• Constraints: deadlines, languages, accessibility, and any rules about where data must be stored.
• Decision-maker: the one person on your side who can approve scope and priorities.

If you are not sure whether you need custom software at all, say so. A good company will tell you when an existing product would serve you better.

1. How will you understand my business before you build?

Good teams start with discovery: your goals, your users and how work actually happens today. If a company quotes a full platform after one short call, the quote is a guess.

Look for: a discovery phase, questions about your processes, and a written summary of what they heard.

What discovery should produce: a prioritized list of features, simple screen sketches or a clickable prototype, a note on technical risks, and an estimate broken into phases. These documents are valuable even if you choose another team, so ask whether you keep them.

2. How do you manage the project?

Look for: short cycles (sprints), a shared board where you can see every task, and a demo of working software every one or two weeks. Agile done well means you never wait months to see progress.

When our engineering partner coached Banco G&T Continental, internal projects were delivered 10 times faster, partly by using Kanban where Scrum was not the right fit. The method should serve the project, not the other way around.

Jargon worth knowing

• Sprint: a fixed period, usually one or two weeks, at the end of which the team shows finished, working features.
• Backlog: the ordered list of everything still to be built. You should be able to see it and change the order.
• Scrum and Kanban: two agile methods. Scrum works in sprints with planned goals; Kanban is a continuous flow of tasks, useful for maintenance or support work.
• MVP (minimum viable product): the smallest version that solves the core problem for real users. It is a starting point, not a cheap version.

3. Who will I talk to, and in which time zone?

Look for: one named project lead who answers your questions, in your time zone, and who can make decisions.

Ask specifically: how quickly they reply to messages, whether you will meet the developers, and what happens if your project lead goes on holiday or leaves the company. Continuity is one of the main reasons to hire a company over an individual.

4. Can I see similar work, and talk to a client?

Look for: case studies with real challenges and results, and a client willing to take your call.

When you call the reference, ask: Did they deliver what was agreed? How did they handle problems and changes? Would you hire them again for something important? The answer to the last question tells you more than any portfolio.

5. How do you handle changes to the scope?

Priorities change as you learn. Look for: a clear process for swapping features of similar size inside the agreed scope, and a written change request for anything bigger.

A worked example: halfway through a booking platform, you realize customers need to reschedule online. A good team estimates the new feature, shows you which existing items of similar size could move to a later phase, and lets you decide. A poor one either says yes to everything (and the deadline slips silently) or sends an unexpected invoice at the end.

6. How is pricing structured?

Look for: a written proposal with scope, timeline and milestone payments tied to delivered work, not everything upfront.

The three common models

Model	How it works	Best for
Fixed price	One price for a defined scope	Small, clearly specified projects
Time and materials	You pay for the time actually spent	Evolving products, ongoing work
Phased or per sprint	A fixed amount per phase or sprint, with scope reviewed at each step	Most custom products

With any model, the proposal should say what is included (design, testing, project management, deployment), what is not (hosting, third-party licences, content) and how extra work is approved. Our article on what a website costs in Canada explains many of the same cost drivers.

7. Who owns the code?

Look for: a contract that transfers the source code and intellectual property to you, and access to the repository, hosting and third-party accounts in your name.

This matters more than many owners realize. Under Canada’s Copyright Act, the author of a work is generally its first owner, and an assignment of copyright is only valid if it is in writing and signed by the owner of the right. Code written by an outside company is not automatically yours just because you paid for it, so make sure the assignment is written into the contract. Ask a lawyer to review the agreement if the software is central to your business.

Also check: that domain names, app store accounts, cloud hosting and services such as payment providers are registered to your business, with the developer invited as a user rather than as the owner.

8. How do you test and secure what you build?

Look for: testing built into every sprint, a staging environment where you review before launch, secure sign-in, and care with personal data under Canadian privacy law (PIPEDA).

Ask specifically: Are passwords and sensitive data protected? Who has access to production? How are backups handled, and have restores been tested? How quickly are security updates applied to the libraries the software uses? Our guides to cybersecurity basics and cloud backup and disaster recovery explain what good looks like.

9. What technology will you use, and why?

Look for: mainstream, well-supported technologies chosen for your needs, explained in plain language. For Tulindero, a real estate platform with a property map, owner accounts and buyer matching, that meant a modern web framework, a managed database and a mapping service. For Himigo Leagues, a tournament platform, it meant secure payments through Stripe and sign-in with Google, Apple or LinkedIn.

Why mainstream matters: if you ever change providers or hire your own developers, you want technology that many people know. Be cautious of a company that proposes its own proprietary framework, because it can tie you to them.

10. What happens after launch?

Look for: a warranty period for fixes, a clear maintenance plan and a team that stays available as your product grows.

A good maintenance plan covers: security and library updates, monitoring so problems are caught before customers report them, backups, small improvements, and a clear way to request and prioritize new features. Ask how support requests are submitted and how urgent issues are handled.

Freelancer, agency or in-house team?

Option	Strengths	Watch out for
Freelancer	Flexible, good for small, defined tasks	One person’s availability, limited design and testing
Development company	Full team, continuity, one accountable party	Make sure you get a named lead, not a rotating queue
In-house team	Deep knowledge of your business over time	Hiring takes time, and a small team has gaps

Many businesses start with a company to build and launch the product, then add an in-house developer later. That transition is easy only if you own the code and the documentation is good, which brings you back to question 7.

How to compare proposals side by side

Put each proposal into the same checklist before you look at the price:

• Does it restate your problem correctly, in your words?
• Is the first version clearly defined, with “later” features listed separately?
• Are design, testing, project management and deployment included?
• Are payments tied to delivered milestones?
• Does the contract assign code and IP to you in writing?
• Is there a named project lead in your time zone?
• Is post-launch support described, with what it includes?

The cheapest proposal often leaves out testing, project management or support, which you pay for later. The best proposal is the one where you understand exactly what you get.

Red flags

• A fixed price for a large platform after one conversation
• No demos until the end of the project
• Vague answers about who owns the code
• Nobody you can reach in your time zone
• Everything paid upfront
• Accounts, domains or hosting registered in the developer’s name
• Pressure to sign quickly, or a proposal that promises everything with no trade-offs

What a good first month looks like

Once you sign, you should see momentum quickly. In a healthy project, the first weeks include a kickoff meeting, access to the shared board and backlog, agreement on how you will communicate, finished discovery documents and, soon after, a first demo of real, clickable software. If a month passes with only status emails and no working software, raise it early.

How we answer these questions

We run our whole company on agile, with sprints, a demo every one or two weeks and retrospectives, and we bring the same discipline to every client project. You work with one project lead in Toronto, under one Canadian contract, backed by a senior engineering team. See our process, our custom software service, or ask us these ten questions yourself.

Frequently asked questions

Should I hire a freelancer or a software development company?

A freelancer can work well for small, well-defined tasks. For a product your business depends on, a company gives you a team with design, development and testing, continuity if someone leaves, and one party accountable for the result.

What is agile development and why does it matter to me?

Agile means building in short cycles, usually one or two weeks, and showing working software at the end of each one. You see progress early, can change priorities as you learn and catch problems while they are small.

Who should own the code of my custom software?

You should. Make sure the contract states that the source code and intellectual property transfer to you, and that you get access to the code repository and all accounts.

Is a fixed price or time and materials contract better?

A fixed price works when the scope is small and clearly defined. For larger or evolving products, time and materials with a capped budget per phase, or a fixed price per sprint or milestone, usually gives you more control and fewer disputes.

What should I prepare before contacting a software development company?

Write down the problem you want to solve, who will use the software, the must-have features for a first version, any systems it must connect to, your timeline and the person who will make decisions. A rough budget range also helps a good team propose the right scope.

How long does it take to build custom software?

It depends on the scope. A good team will not give you a firm date before discovery, but should show you a first working version early and demo progress every one or two weeks after that.