Choosing a software development partner is one of the few decisions in a project that is hard to undo. Once work starts, switching teams costs time, money and knowledge. Yet many businesses choose on the strength of a portfolio and a quote, and only find out how a team really works after the contract is signed.
This checklist covers what we would want to know if we were in your position. Use it in your first calls with any company you are considering, including us.
1. Start with your problem, not their portfolio
A polished portfolio tells you a team can build something attractive. It does not tell you whether they understand your problem. In the first conversation, notice who does the talking. A good partner asks about your users, your current process, what is not working today and how you will know the project has succeeded. If the conversation moves to technology and features before anyone has asked about your business, take note.
Before you speak to anyone, write down in plain language what you want to change and why. One page is enough. It gives every company the same starting point and makes their answers easier to compare.
2. Look at work they still support
Launching software is the start of its life, not the end. Ask which of the projects they show you they still maintain today. A team that looks after its own work for years has had to live with its design decisions, and that usually shows in how carefully it builds. Visit the live sites. Are they still working, up to date and fast?
3. Ask who will actually do the work
The people in the sales meeting are not always the people who write the code. Ask who will lead your project, who will build it and how experienced they are. Ask whether you can speak to them directly during the project. Also ask what happens if a key person leaves. A team with shared code reviews and documentation can absorb that. A team that depends on one developer cannot.
4. Understand how requirements and changes are handled
Every project changes as it goes. What matters is how change is managed. Ask how requirements are written down and agreed, who signs them off, and what happens when you want something different halfway through. Ask how a change affects cost and timeline, and how you will be told. Clear answers here prevent most of the disputes that sour projects.
5. Check how they test and release
Ask what happens between a developer finishing a feature and that feature reaching your users. You want to hear about code review, testing against the agreed requirements, a separate test environment, and a chance for you to try the software before it goes live. Ask how a release is done and how it is rolled back if something goes wrong. If releases depend on one person copying files to a server, that is a risk to your business.
6. Settle code ownership, access and documentation early
Make sure the contract says who owns the code, the designs and the data. Ask where the code will be kept and whether you will have access to it during the project, not only at the end. Ask what documentation you will receive and who will hold the passwords and accounts for hosting, domains and third-party services. You should be able to move to another provider in future without starting from scratch.
7. Talk about security and personal data
If your software will hold customer or employee data, raise it in the first call. Ask how access to your systems is controlled, whether real personal data will be used during testing, how backups are handled and what happens if there is a security incident. If you operate in India, ask how the team approaches the Digital Personal Data Protection Act, 2023. A team that has thought about these questions will answer them calmly and specifically.
8. Agree how you will communicate
Ask how often you will see progress, in what form, and who your day-to-day contact is. Regular demonstrations of working software are worth more than long status reports. If you work across time zones, agree overlap hours at the start.
9. Choose a pricing model that fits the work
A fixed price suits work that can be clearly defined up front. A dedicated team or time-and-materials arrangement suits products that will evolve as you learn. Neither is better in general, but the wrong one for your situation causes friction. Ask the company which model they would recommend for your project and why.
10. Plan for life after launch
Ask what support looks like once the software is live: how issues are reported, how quickly they are handled, how security updates are applied and what it costs. Ask whether there is a warranty period for defects found after launch.
Warning signs
- A firm price and timeline before anyone has understood your requirements.
- Reluctance to let you speak to the people who will build your software.
- No clear answer on who owns the code or where it is kept.
- Claims, numbers or certifications that cannot be backed up when you ask.
- No mention of testing until you raise it.
A short checklist to take into your calls
- Did they ask about our business before talking about technology?
- Which of their projects do they still support?
- Who exactly will work on our project?
- How are requirements agreed and changes handled?
- How is work reviewed, tested and released?
- Who owns the code, and when do we get access?
- How will our data be protected?
- What does support look like after launch?
If you are weighing up partners for a project and would like a second opinion, we are happy to talk it through on a free consultation call, with no obligation to work with us.