The short answer
The right software development partner is the one that understands your problem before it proposes a solution, is open about how it builds and tests, and leaves you in control of what you paid for. In practice, that means five things: a real discovery process, a delivery approach you can see working, security built into development rather than bolted on, written ownership of code and accounts, and a clear arrangement for support after launch.
Price and portfolio matter, but they are poor predictors on their own. A low rate spent on the wrong scope is expensive, and an impressive portfolio tells you little about how a firm behaves when requirements change halfway through.
Five things to judge a partner on
1. How they discover and scope
Ask what happens before any code is written. A good partner will want to speak to the people who do the work, see the spreadsheets and systems involved, and understand the exceptions. Be cautious of a fixed quote produced after one call: either the scope is very simple, or the risk is hidden somewhere in the assumptions.
Good signs: they ask about your data, your integrations and who will own the software after launch. They are willing to recommend buying or integrating instead of building, as our build, buy or integrate guide explains.
2. How they deliver
Ask to see how a typical project runs week to week. You want short iterations, working software demonstrated regularly, a visible backlog you can reprioritize, and a named person on their side who is accountable for delivery. Ask how they handle a change request and how it affects cost and schedule.
3. How they build securely
Ask which secure development practices they follow and how they check their own work. Frameworks such as NIST's Secure Software Development Framework and the OWASP Application Security Verification Standard give you a shared language for this conversation. You do not need to be a security expert to ask: how are dependencies kept up to date, how are secrets stored, who reviews code before it ships, and how are access controls tested for each user role?
4. Who owns what
Under section 13 of the Copyright Act, the author of a work (or the author's employer) is generally its first owner, and an assignment of copyright is only valid if it is in writing and signed. So if you want to own the code an outside firm writes for you, the contract needs to say so. Check also:
- Source code lives in a repository your organization owns, or is delivered to it regularly, not only at the end.
- Cloud accounts, domains and app store listings are registered to your organization.
- Any reusable components the partner keeps are licensed to you on terms you understand.
- Third-party and open-source licences used in the software are listed.
This is general information, not legal advice. Have your lawyer review the agreement.
5. What happens after launch
Software needs security updates, monitoring and fixes for as long as it is in use. Ask what support looks like, what it costs, how requests are logged and prioritized, and how response targets are written into the service agreement. Ask what happens if you later want someone else to maintain it: a partner confident in its handover will be comfortable with that question.
Canadian considerations people forget
- Data residency and access. If developers or support staff outside Canada will be able to access personal information, that is a transfer for processing. The Office of the Privacy Commissioner's guidance on cross-border processing says you remain accountable and should be transparent about it. Ask where the team works and where test data lives.
- Real data in testing. Ask whether they use anonymized or synthetic data in development and test environments.
- French and accessibility. If you serve Quebec or need bilingual content, or if you must meet Ontario's accessibility requirements, confirm the partner has done this before rather than treating it as a later phase.
- Time zones. A partner whose working day overlaps yours makes decisions faster, especially during testing and go-live.
Rather talk it through? Bring your shortlist questions and we will answer them for your actual project, in writing. Talk to a Promatics specialist
A partner comparison worksheet
Score each firm from 1 to 5 on each line and write down the evidence, not just the number.
| Criterion | Firm A | Firm B | Firm C | Evidence |
|---|---|---|---|---|
| Asked about exceptions, data and integrations before quoting | ||||
| Listed assumptions and exclusions in writing | ||||
| Showed how iterations, demos and change requests work | ||||
| Explained secure development and code review practices | ||||
| Code, accounts and IP assigned to you in writing | ||||
| Clear handover: documentation, credentials, deployment steps | ||||
| Support agreement with defined response targets | ||||
| Answered privacy and data-location questions clearly |
- We spoke to someone who will actually work on the project, not only sales.
- We saw a sample of their documentation or handover material.
- Our lawyer reviewed the IP, confidentiality and exit terms.
Red flags worth walking away from
- A firm quote with no discovery and no written assumptions.
- Reluctance to put code in your repository until the final payment.
- "We will handle security" with no detail when you ask how.
- No clear answer on who supports the software after launch.
- Pressure to sign quickly, or a discount that expires in days.
Common objections, answered honestly
"A freelancer would be cheaper." Often true for small, well-defined work, and a good freelancer can be an excellent choice. The risk grows with the size and importance of the system: a single person is a single point of failure for holidays, illness and knowledge.
"We could build it ourselves with AI coding tools." For a prototype or an internal utility, that can work. For software that holds customer data, connects to your ERP or must be supported for years, you still need someone to own the design decisions, the testing, the security and the 2 a.m. problem. AI speeds up the typing; it does not take responsibility.
"Switching partners mid-project feels too risky." It is less risky when code, accounts and documentation are already yours. That is exactly why ownership belongs in the first contract.
What working with Promatics looks like
We start with discovery and a written recommendation. If building is right, we agree a first release, deliver it in short iterations with regular demonstrations, test it against your real business rules, and hand over code, documentation and infrastructure in your organization's accounts. Support after launch sits in a separate agreement with response targets written down. See software development for how we work across web, mobile and custom applications.
When to bring in help
If the software is small, internal and low-risk, a capable freelancer or in-house developer may be the right call. Bring in an experienced partner when the software will hold personal or financial information, connect to systems you depend on, serve customers directly, or need support for years. In those cases, the cost of choosing badly is far higher than the difference between quotes.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- Copyright Act, section 13 (ownership of copyright), Justice Laws Website, Government of Canada
- Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218), National Institute of Standards and Technology
- Application Security Verification Standard, OWASP Foundation
- Guidelines for processing personal data across borders, Office of the Privacy Commissioner of Canada
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.