Four questions
- Who owns the code, and where does it live? Should be you, in your repository.
- How will it be tested? A real answer, not “thoroughly”.
- How does it get deployed? Should not involve uploading files.
- Can we speak to a client from three years ago? Reveals how the work ages.
The fourth is the most useful and the least asked. Anyone can show a system launched last month. A three-year-old one shows whether the work was built to last.
What good answers sound like
| Question | Good answer |
|---|---|
| Testing | Names what would be tested and why |
| Deployment | Version control, staging, repeatable process |
| Handover | Code, docs, training, credentials — all yours |
| Maintenance | A yearly figure, offered rather than avoided |
| Risk | Names specific risks and how they would be handled |
Warning signs
- Code held in the supplier's repository as standard
- No mention of testing or deployment in the proposal
- An estimate given before seeing your systems
- Reluctance to provide client references
- Everything described as straightforward
Reference calls are worth the time
Ask a past client three things: did it come in near time and budget, what happened when something broke, and could another developer take it over.
Those three answers are more informative than any portfolio, and past clients are usually candid.
Start with something small
A well-defined first piece of work — a few weeks, fixed price — tells you how a supplier actually works far better than any selection process.
It is a cheap way to find out, and any competent supplier will suggest it themselves.