Four questions
- Who owns the code and where does it live? Should be you.
- How will permissions be tested? A real answer, naming cross-user access.
- How does it get deployed? Should not involve uploading files.
- Can we speak to a client from three years ago? Shows how the work ages.
The second question is unusually revealing. A supplier who has thought about testing that user A cannot reach user B's records has built business applications before.
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 references
- Everything described as straightforward
What a good proposal contains
| Section | Look for |
|---|---|
| Scope | What is in and explicitly what is out |
| Assumptions | Stated, so they can be checked |
| Risks | Named, with how each would be handled |
| Testing | What would be tested and why |
| Handover | Code, credentials, documentation, training |
| Maintenance | A yearly figure, offered |
Reference calls
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 better than any selection process.
Any competent supplier will suggest it themselves, and it de-risks the decision for both sides.