Nuzhat Rubab Zahra
Choosing a software development company is a bet on people you have not worked with yet. Portfolios and proposals all look good. The difference shows in how a firm answers specific questions about who will do the work, how they handle change, and what happens when things go wrong. These are the questions we would ask if we were on your side of the table.
Before you talk to anyone: define the outcome
Write a one-page brief before contacting firms. Describe the problem, who the users are, what success looks like in measurable terms, your constraints (deadline, budget range, compliance, existing systems), and what already exists. Resist specifying every feature. A good partner will challenge your assumptions, and a brief that is all solution leaves no room for that.
The same brief, sent to every firm, also makes their responses comparable.
Questions about the people
- Who exactly will work on our project, and can we meet them before signing?
- How senior are they, and what share of their time will be ours?
- Who is our day-to-day contact, and who is accountable if the project slips?
The most common disappointment in outsourced software is a senior team in the sales meeting and a junior team on the work. Named people with relevant experience, met in advance, are the best protection against it.
Questions about process and scope
- How do you run discovery, and what do we get at the end of it?
- How do you handle changes to scope once work has started?
- How often will we see working software, not just status reports?
- How do you estimate, and how have your recent estimates compared with what actually happened?
Listen for specifics. A firm that shows working software every week or two, and can explain how it re-plans when priorities change, will surface problems while they are still cheap to fix.
Questions about quality and security
- How do you test, and what is automated?
- How do you handle security, access to our data, and credentials?
- What do your code review and deployment processes look like?
Good answers are concrete: automated tests running on every change, peer review before anything merges, deployments through a pipeline rather than by hand, least-privilege access to production data, and secrets kept out of the codebase.
Questions about ownership and handover
- Who owns the code and intellectual property, and will the code live in our repository from day one?
- What documentation will we receive?
- What happens after launch: support, response times, and how ongoing work is arranged?
- If we part ways, how does handover to another team work?
You should never be in a position where your software is held in someone else's account. Code in your own repository, infrastructure in your own cloud accounts, and documentation that another team could pick up are the basics of a healthy engagement.
Questions about track record
- Can we speak to clients with projects similar to ours, including one where things did not go to plan?
Every firm has had a difficult project. How they describe it, what they learned, and whether that client would still recommend them tells you more than any case study.
Red flags
- A fixed price for a vague brief, offered without questions.
- No access to the code until the final payment.
- Senior people in the pitch, unnamed people on the work.
- Agreeing to every requirement and deadline without pushback.
- No testing or deployment process they can describe in plain terms.
- Reluctance to provide references.
Comparing proposals fairly
Score each proposal against the same criteria, and weigh the answers to the questions above alongside the document itself.
| Criterion | What good looks like |
|---|---|
| Understanding of the problem | Restates your goal in their own words and challenges at least one assumption |
| Team | Named people with experience relevant to your project |
| Plan | Phased, starting with discovery, with working software early |
| Quality | Automated testing, code review, and CI/CD described concretely |
| Ownership | Code and infrastructure in your accounts from the start |
| Support | A clear model for support and ongoing work after launch |
How we answer these questions
Our engagements almost always start with a short, paid discovery that ends in a plan you own, whether or not you continue with us. We work alongside in-house teams and transfer knowledge deliberately, so you are not dependent on us. And we stay after launch to support and evolve the work. If you are comparing partners, we are happy to answer every question on this list on a call.
Judge a software partner on how specifically they answer questions about people, process, quality, and ownership, not on how polished the proposal looks. Specific answers now predict fewer surprises later.
Frequently asked questions
Meet the people who will do the work, ask how they run discovery and handle scope changes, check how they test and deploy code, confirm the code will live in your repository, and speak to references from similar projects.
At minimum: scope or the process for defining it, deliverables and milestones, how changes are handled, payment terms, ownership of code and intellectual property, confidentiality, support after launch, and how either side can end the engagement. Have a lawyer review it.
Fixed price suits small, well-defined work. For anything with real uncertainty, time and materials with a budget cap per phase is usually fairer, because a fixed price on a vague brief either carries a large risk margin or leads to disputes over scope.
Location matters less than communication, overlap in working hours, and process. Remote teams deliver well when they share several working hours with you, write decisions down, and show working software often.
Working on something like this?
See how our Strategy & Consulting practice works, or talk to us directly. No pitch.
