Short answer: Ask fifteen questions across five areas: approach (domain experience, risk assessment, discovery process, out-of-scope definition), team (who works on it, what you must contribute, communication rhythm, first demo), commercials (pricing model, change requests, payment milestones), ownership (source code, exit scenario, hosting) and support (response commitments). The most expensive mistake is not choosing the wrong vendor, it is choosing without asking these.
Put the same list to every shortlisted supplier. The differences become obvious when the answers sit side by side.
Approach and scope
1. What have you built in our industry?
Good answer: describes a comparable project concretely, including which process it solved and where it got difficult.
Red flag: "We're very experienced." Experience is evidenced by a reference you can actually call.
2. What do you think is the riskiest part of our project?
This tests whether they listened. Nobody solves a project in a 45-minute call, but a competent team shows instinct for where trouble lives. Red flag: "No risks, this is all standard."
3. How do you run discovery and analysis?
Good answer: a defined process including department interviews, process maps, screen wireframes and a signed analysis document.
Red flag: skipping analysis to keep the quote low. Projects that start without analysis end in scope disputes.
4. How do you state what is out of scope?
A proposal needs an exclusions list as much as an inclusions list. A vendor who will not provide one is setting up a future change-order conversation.
Team and working method
5. Who exactly will work on this, and at what seniority?
The senior team at the sales call is not always the delivery team. Ask for names and roles in writing.
6. How much time do you need from us?
Good answer: a concrete expectation, such as eight to ten hours a week from the project owner and four to six from key users during analysis.
Red flag: "You won't need to do anything." This is the clearest predictor that the wrong software will be built.
7. What is the communication and reporting rhythm?
Weekly call, shared issue tracker, working demo every two weeks. Projects that report monthly by email drift out of control.
8. When will we see the first working version?
Vendors delivering incrementally typically show something real within three to six weeks. Months of silence is a risk signal.
Commercials
9. What pricing model do you use?
| Model | Advantage | Risk | Fits |
|---|---|---|---|
| Fixed price | Budget certainty | Rigid scope | Well-defined projects |
| Time and materials | Flexibility | Budget uncertainty | Exploratory work |
| Dedicated team | Continuity, direct control | Pay for reserved capacity | Ongoing product work |
10. How are change requests handled?
Good answer: written change request, impact analysis on time and cost, then implementation after approval.
Red flag: "We just do the small things." Undefined goodwill becomes a dispute six months in.
11. What are the payment milestones tied to?
Payments should be tied to accepted deliverables rather than calendar dates. A milestone without an acceptance criterion is a future invoice argument.
Ownership and dependency
12. Who owns the source code, and when is it delivered?
Three separate matters: ownership of the IP, licence to use, and actual delivery of the code and repository. All three belong in the contract. Client ownership of custom-built code is a standard request.
13. What happens if we stop working with you tomorrow?
Good answer: repository access, technical documentation, database schema, deployment instructions and a defined transition period.
Red flag: deflection. An undefined exit is how dependency is created.
14. Where is the software hosted, and who controls the data?
Confirm hosting region, backup frequency and location, the sub-processor list, and how GDPR responsibilities are split. Get it in the contract, not the sales deck.
Support
15. How does support work after go-live?
Support scope, response times, which requests are free fixes versus billable work, and the annual maintenance fee all need to be explicit. "Call us if there's a problem" is not a support model.
Extra questions when the vendor is offshore or nearshore
- What are the actual overlap hours with our working day, and who is available in those hours?
- What is the contract currency and how long is the rate valid?
- Which legal entity are we contracting with, and under which jurisdiction and governing law?
- What is the data transfer mechanism if personal data will be processed outside our region?
Comparing proposals
The lowest quote is frequently the most expensive one, because the gap usually sits in scope. Put every proposal into the same table with these ten lines:
- Analysis and design
- Development, by module
- Integrations, named individually
- Data migration
- Testing and defect resolution
- Training
- Go-live support
- Annual maintenance fee
- Source code delivery, yes or no
- Total duration and number of phases
Two questions are enough in a reference call: did something go wrong during the project and how was it handled, and knowing what you know now would you choose them again?
Seven red flags
- Gives a firm price without doing analysis
- Sends a proposal without asking any questions
- Provides no out-of-scope list
- Deflects on source code and exit terms
- Says "you won't need to do anything"
- Avoids giving references
- Contract contains no response-time commitment or acceptance criteria
[To fill before publishing: Codefacture's own public answers to all fifteen. Discovery process, standard IP terms, source code delivery policy, support response tiers, contract currencies and governing law. Vendors that publish concrete commitments get quoted, vendors that publish adjectives do not.]
Frequently asked questions
How do I choose a software development company?
Compare scope rather than price. The stronger vendor has a defined analysis process, provides a written out-of-scope list, is explicit about source code ownership and exit terms, commits to support response times, and can give references you are able to call.
Is it risky to work with a small development agency?
Size alone is not the signal. What matters is the time the team actually gives your project, their documentation discipline, and whether a handover scenario is defined. Small teams often communicate faster, larger firms offer more continuity.
Is offshore development cheaper?
Hourly rates can be lower, but time-zone gaps, language friction and regulatory differences can raise the total. Compare total engaged cost including analysis, QA, documentation and support, and check how many hours of genuine overlap you get with your own working day.
What clauses must be in a software development contract?
Nine: scope and out-of-scope, acceptance criteria, milestone-based payment, change management, IP assignment and source code delivery, confidentiality, data protection responsibilities, support commitments, and termination and handover terms.
Next steps
Ask us these fifteen questions too. Related reading: how to write a software requirements document and engagement models compared.