Choosing a software development partner is closer to hiring a senior team than to buying a product. You are trusting someone with your processes, your data and, often, a system your business will depend on for years. Yet the decision is frequently made on a short presentation, a portfolio of screenshots and the lowest price.
The proposals you receive will look similar. The differences that matter only appear when you ask the right questions and listen carefully to how they are answered. This article sets out those questions, grouped by what they reveal, and the warning signs to watch for.
Before you talk to anyone: prepare your side
A good partner can only respond well to a clear brief. Before inviting proposals, write down:
- The business problem, in a paragraph, and what success would look like a year after launch.
- Who will use the system, and roughly how many people in each role.
- The systems it must connect to (accounts, HR, banks, buyer portals, machines).
- Your budget range and any fixed deadlines, with the reason for each.
- Who on your side will own the project and make decisions.
Share the same brief with every candidate. It makes the answers comparable and shows partners you are serious.
Questions about understanding
1. How will you learn our process before quoting a fixed price?
A partner who gives a firm price for a significant system after one meeting is either guessing or planning to make it up through change requests. Look for a structured discovery phase: workshops, site visits, process mapping and a written scope you can review.
2. What would you not build, and why?
This question is revealing. A thoughtful partner will suggest using an existing product for part of the work, postponing a feature, or simplifying a process before automating it. A partner who agrees to everything has not yet thought about your problem.
3. Who have you built something similar for, and can we speak to them?
Ask for references for comparable work, not only the best-known logo. Speak to the client directly and ask what went wrong and how the partner responded. Every project has problems; the response is what you are buying.
The best answer to "can you build this?" is usually another question about your business.
Questions about delivery
4. Who exactly will work on our project?
Meet the project lead and senior developer, not only the sales team. Ask how much of their time is committed to you and what happens if someone leaves.
5. How often will we see working software?
Regular demonstrations of real, working features, every two weeks or so, are the single best protection against surprises. Ask to see an example of a demo plan or release note from a past project.
6. How do you handle changes in scope?
Changes are normal. What matters is a simple, written process: the change is described, its effect on cost and time is estimated, and you approve it before work starts.
7. How do you test, and how do we accept the work?
Ask what testing the partner does before you see a release, and how acceptance will work: agreed criteria, a testing period with your users, and a clear list of what counts as a defect.
Questions about ownership and risk
8. Who owns the source code, the database and the documentation?
The contract should say clearly that, on payment, you own or have full rights to use and modify the code, data and documentation, and that you can receive them at any time. Check how third-party components and the partner's reusable libraries are licensed to you.
9. Where will the system be hosted, and who controls the accounts?
Domain names, cloud accounts and app store accounts should be registered in your company's name, with the partner given access, not the other way round.
10. How do you protect our data during development?
Ask whether developers work on real data or anonymised copies, how access is granted and removed, and how credentials are stored. A partner who treats your test data casually will treat production data the same way.
Questions about after launch
11. What support do you provide after go-live?
Look for a defined warranty period for defects, then a support agreement with response times, a way to log issues, and a clear price for enhancements. Ask who answers the phone when the system stops on a Thursday evening.
12. If we part ways, how would the handover work?
A confident partner will answer this calmly: documentation, a walkthrough of the code, deployment instructions and credentials. Hesitation here is worth noting.
Warning signs
- A fixed price with no discovery and no written assumptions.
- Nobody asks to see your current process in person.
- The people in the sales meeting will not be the people doing the work.
- Vague answers about code ownership or hosting accounts.
- No mention of testing, training or support until you ask.
- Pressure to sign quickly because of a discount or a "slot" in the schedule.
Comparing proposals fairly
Put the proposals side by side and score them on the same criteria, weighted by what matters to you:
- Understanding of your problem, shown in their own words.
- Approach: discovery, phasing, demos, testing and acceptance.
- Team: named people, relevant experience and continuity.
- Ownership and risk: contract terms, hosting and data handling.
- Support: warranty, response times and enhancement pricing.
- Total cost over several years, not only the build price.
Price matters, but it should be one line on this list, not the whole list. The cheapest proposal often becomes the most expensive project once missing work is added back.
Consider starting small
If you are unsure, commission a short, paid discovery from your preferred partner before committing to the full build. You will learn how they work, receive a scope document you own, and keep the freedom to take that scope elsewhere if the relationship does not feel right.
Where RAED fits
We are happy to be asked every one of these questions, and we encourage clients to ask them of anyone they consider. Our projects start with discovery, run on regular demos, and give clients ownership of their code and data.
