Credentials are table stakes; behaviour is the differentiator
Most established suppliers can build competently. What separates a relationship worth keeping from one you tolerate is how they behave when things are uncertain, when they disagree with you, and when something goes wrong.
Here is what we think good looks like, written partly so you can hold us to it.
1. They tell you what not to build
A partner whose every response is enthusiasm is a supplier optimising for scope. The valuable ones say “that feature will cost £8,000 and we do not think you will use it”.
This is also self-interested in the right way: projects that deliver value produce referrals, and projects stuffed with unused features produce a client who feels overcharged.
2. You see working software fortnightly
Not status reports, not percentages. Something running that you can click. Fortnightly at worst, and from early in the project rather than at the end.
The frequency of working demonstrations is the single most reliable predictor of a project going well. Everything else can be presented favourably; running software cannot.
3. Bad news arrives early
Every project hits something unexpected. The difference is whether you hear about it in week four when it is a schedule adjustment, or week ten when it is a crisis.
A supplier who brings you problems with options attached is doing the job. One whose updates are uniformly positive until they suddenly are not is managing your perception rather than your project.
4. They document as they go
- Architecture decisions, briefly, with the reasoning
- How to deploy it, tested by someone else following the instructions
- What the important business rules are and where they live
- Credentials and dependencies, in a form you can take elsewhere
Documentation produced at the end is written under time pressure by someone already thinking about their next project. Documentation produced as they go is accurate.
5. They make themselves replaceable
The strongest signal of a good partner is that they actively reduce your dependency on them: code in your repository, accounts in your name, documentation good enough for someone else, and no artificial obstacles to leaving.
This sounds commercially foolish and is not. Clients stay with suppliers who could be replaced and choose not to be, and those relationships last far longer than the ones held together by lock-in.
What we ask of clients in return
- One person who can make decisions, available for about half a day a week
- Questions answered within a day or two, because unanswered questions become assumptions
- Honesty about constraints, including the political ones
- Attendance at demonstrations, with actual feedback
- Realism about scope changes — they are fine, and they have a cost
Projects where both sides do their part finish earlier and cost less than the same scope where either side does not. That is not a platitude; it is the most consistent pattern we see.