This decision is usually made on a deck and a rate. Four questions predict the outcome far better.
1. What would you look at in our data before proposing anything?
The strong answer asks for access, or at least for fifty real records, before recommending a shape. The weak answer arrives with a solution already drawn.
Every implementation is constrained by data that is messier than the documentation assumes. A partner who wants to see it first has been burned by that before, which is what you are paying for.
2. What would you refuse to build for us?
Restraint is the expensive skill and it is hard to fake in a first conversation.
Good answers are specific: this should stay manual while the process is still in debate, that needs a human approval because it is irreversible, this data is not clean enough to automate against yet.
Anyone who would build whatever you ask is describing their sales process, not their craft.
3. Who operates this after you leave, and what will they have?
The answer you want includes a runbook, credentials that do not depend on the partner's accounts, and a named internal owner from day one.
If the answer is a support retainer, you are being offered a dependency. That can be a reasonable purchase, but price it as one.
4. How are you paid, and what happens if we finish early?
Hourly rewards staying. Fine for discovery and exploratory work, poor for delivery.
Fixed scope rewards finishing and punishes change, so the scope has to be genuinely clear.
Retainer rewards whatever you define it to reward, which means you must define it. A retainer for availability is different from one for outcomes.
The question about finishing early is the useful one. Listen to whether the answer is comfortable.
References: ask for scale, not industry
A reference in your vertical is nice. A reference at your size and structure tells you far more.
A partner whose best work was a single location business will meet a thirty location rollout with a series of rebuilds. The failure mode is structural rather than about industry knowledge.
Start with a small paid project
One or two weeks, against a problem you actually want fixed, with the deliverable written down and a definition of done that is a business outcome rather than an execution log.
Watch three things while it runs: how many questions they ask before building, whether they document as they go, and whether you could hand the result to someone else at the end.
It costs a fraction of a bad annual contract and it answers what no reference can.
The warning signs
- A proposal before seeing any data
- Nothing they would refuse to build
- No handover plan, or one that begins after go live
- References only at a different scale
- Discomfort with the question about finishing early