Choosing a development partner is one of the few decisions in a software project that you cannot easily reverse. A good partner compensates for gaps in your brief. A poor one turns a clear brief into a stalled project. The checklist below helps you tell them apart before you sign.
Before you speak to anyone
You will judge partners better if you know what you need. Write a one-page brief covering the business outcome you want, the people who will use the software, the systems it must connect to, your deadline and your budget range. Name the person in your company who will make decisions during the project. Partners can only move as fast as your answers.
The questions worth asking
Most sales calls cover the same ground: portfolio, technology, price. The questions below go further, and the way a partner answers them tells you more than the answers themselves.
Experience and fit
- Which projects of yours are closest to ours, and what went wrong on them? Every real project has setbacks. A partner who describes them openly, and explains what they changed afterwards, has learned from them.
- What would you question in our brief? Good partners push back. If they accept every assumption without a question, they either have not read it carefully or plan to discover the problems later, on your budget.
The people
- Who exactly will work on our project, and how senior are they? Ask to meet the lead engineer and designer, not only the sales team.
- Will any of the work be subcontracted? Subcontracting is not always a problem, but you should know who writes your code.
- What happens if a key person leaves mid-project? Look for documented code, shared knowledge and a named replacement plan.
How they work
- How often will we see working software? Every two weeks is a good rhythm. Monthly status reports without a demo are a warning.
- How do you handle changes to scope? You want a written process that shows the effect of each change on time and cost before work begins.
- How do you test? Ask about automated tests, code review and who signs off a release.
Commercials and ownership
- Who owns the code, designs and data? The answer should be you, in writing, with access to every repository and account from the start.
- What is included in the price, and what is excluded? Exclusions reveal where the extra invoices will come from.
After launch
- What does support look like after go-live? Ask for response times, what a support plan covers and what it costs.
- Can we speak to a client whose project finished at least a year ago? A reference from a long-standing client tells you whether the partner stays accountable.
Communication and time zones
A partner in another country can work as smoothly as one down the road, if the communication is designed for it. Ask how many working hours overlap with yours, who your single point of contact will be and how quickly they reply during those hours. Agree the rhythm up front: a weekly demo, a shared channel for day-to-day questions and a written summary of decisions.
Pay attention to how the partner communicates before you sign. Replies that arrive late, miss your questions or promise more than the brief asked for tend to continue once the project starts.
Red flags in a proposal
Watch for these when proposals arrive.
- A precise price with no discovery. An exact figure based on a short brief means the partner has either padded it heavily or not thought it through.
- No assumptions listed. Every estimate rests on assumptions. If a proposal does not state them, you will learn them later, one change request at a time.
- Vague team descriptions. "A dedicated team of experts" tells you nothing. You want roles, seniority and time allocation.
- Intellectual property that stays with the vendor. Some contracts license the code to you rather than transferring ownership. That limits what you can do with your own product.
- No mention of testing or security. If quality assurance is missing from the plan, it is probably missing from the price too.
- Silence about life after launch. A partner who has not planned for support is planning to leave.
Comparing proposals fairly
Proposals rarely describe the same scope in the same way, so comparing totals is misleading. Put them side by side against the same criteria and weight what matters to you.
| Criterion | What to look for | Suggested weight |
|---|---|---|
| Understanding of the problem | They restate your goal in their own words, with sensible challenges | High |
| Team and seniority | Named roles, relevant experience, realistic allocation | High |
| Process and visibility | Regular demos, clear change control, direct access to the team | High |
| Scope and assumptions | Explicit inclusions, exclusions and risks | Medium |
| Price and payment terms | Payments tied to delivered milestones | Medium |
| Support after launch | Defined response times and a clear plan | Medium |
Convert each proposal to person-weeks where you can. Two proposals with similar totals but very different effort usually describe two different products.
References that tell you something
Generic praise from a reference is useless. Ask specific questions instead. How did the partner react when something went wrong? Did the final cost match the proposal, and if not, why? Would the reference hire them again for a larger project? The pauses before the answers are often as informative as the answers.
Start small
If you are still torn between two partners, pay one of them for a short discovery phase: a week or two of workshops, technical investigation and a written plan. You will see how they think, how they communicate and how they handle disagreement, at a fraction of the cost of the full project. If the relationship does not work, you keep the plan and can take it elsewhere.
We run every project this way, starting with discovery and a fixed-price proposal. If you would like to see how we would approach your brief, start a project or read how we think about fixed price and time and materials contracts.
Written by the engineering team at Aventra Global LLC, Dubai.