Choosing a software partner is one of the most expensive decisions a growing company makes. It is also one of the hardest to judge, because you often only see the quality of the work when it is too late. Portfolios and sales presentations tell you little. How a team works tells you almost everything.
These twelve questions work whether you are comparing agencies in Casablanca, freelancers in Lisbon or consultancies in Montreal.
Understanding your needs
1. Did they ask more questions than they answered? A good team spends the first meeting trying to understand your business, your users and your constraints. A team that proposes a solution in the first thirty minutes is selling, not solving.
2. Can they explain your problem back to you? Ask for a written summary of the project. If the summary is vague or generic, the estimate will be too.
3. Do they tell you what not to build? Pushing back on scope is a sign of experience. Agreeing to everything is a sign of an estimate that will grow.
Technical quality
4. Who will actually do the work? Meet the developers, not just the salesperson. Ask about their experience and how many other projects they are working on.
5. How do they make and record technical decisions? Look for written plans or decision records. “We’ll use the latest framework” is not a plan.
6. How do they test and release? Ask about code review, automated tests, test environments and how an update reaches the live system. Manual, late-night releases are a warning sign.
7. How do they handle security and personal data? They should be comfortable talking about access control, the storage of passwords and keys, backups, and laws such as Morocco’s Law 09-08 or the GDPR.
Delivery
8. How often will you see working software? The right answer is every one or two weeks, on a test site you can use yourself, not a slide showing a percentage.
9. How are changes handled? The scope will change. There should be a simple, written process for estimating and approving changes.
10. What happens after launch? Maintenance, support, monitoring and response times should be defined before you sign, not negotiated during an outage.
Ownership
11. Who owns the code, the accounts and the data? The answer should be “you, from day one”: the code stored in your company’s account, cloud accounts in your name, domain names registered to you.
12. Could another team take over tomorrow? Ask to see the documentation from a past project. If a new developer could not get the system running from it, you would be locked in.
A simple scoring method
Score each candidate from 0 to 2 on every question, and count the “Ownership” and “Delivery” questions twice. The totals will not make the decision for you, but they turn a gut feeling into a discussion your team can base on evidence.
Before you sign
- Start with a paid discovery phase or a small first milestone. It is the cheapest way to test the relationship.
- Check that the contract covers intellectual property, acceptance criteria and exit terms.
- Name one contact person on your side who can make decisions quickly.
If you would like an independent review of the proposals you have received, including ones that do not come from us, our technology consulting team can help.