Most software evaluations are conducted on the least informative material available: a portfolio of finished work, a proposal written to win, and a demo built to impress.
None of these predict the thing that actually determines the outcome — how the partner behaves when the project becomes difficult. And it will. Data will be messier than expected, a requirement will turn out to be wrong, and a deadline will collide with a discovery nobody anticipated.
This article is a set of questions that reveal that behaviour in advance. We are a software partner, so read this with that in mind — though several of these questions are ones we would rather be asked, because they make bad-fit engagements visible early.
Ask what they will do before they build
The single most predictive question: what happens in the first two weeks?
If the answer is "we gather requirements and produce a specification", that is a partner who will build what you describe. If what you describe is complete and accurate, fine. In our experience it never is — operations run on workarounds and undocumented exceptions that do not appear in any requirements meeting, which is why we document how the work is actually performed rather than collecting a specification.
Better answers involve spending time in the operation, watching the work, and coming back with observations you did not tell them.
A partner who is willing to disagree with your brief before starting is worth more than one who agrees with all of it.
Ask what they would not build
"What in our request would you push back on?"
A partner with no answer either has not thought about it or is unwilling to say. Every substantial brief contains something that should be scoped differently, deferred, or solved without software.
The related question: "What would you recommend we buy instead of build?" A partner who can identify nothing reusable in your requirements is either not looking or is billing by the hour. There are mature products that solve real problems, and a good partner knows where theirs is not the answer — a judgement covered in off-the-shelf or custom.
Ask about deployment, not just delivery
Most failures are rollout failures, not engineering failures. So ask how the system reaches the business.
How is it deployed? A single cutover on a planned date, or gradually with the old system running in parallel? Parallel running costs duplicated effort briefly and is far cheaper than an outage in a live operation.
What is the migration plan? If migration is a line near the end of the timeline, it has been underestimated. It is usually the largest source of risk, as covered in moving years of records without losing them.
Who trains the staff, and for how long? Training measured in weeks suggests a system too complex for the people who must use it under pressure.
What happens if it goes wrong on day one? There should be a rollback answer.
Ask about after
Software projects are sold as builds and lived as relationships.
Who maintains it, and at what cost? Get the ongoing figure before signing, not at renewal.
What happens when we need a change in a year? Rate, lead time, and whether there is a queue.
What if the people who built it leave? This applies to their team and to yours. Systems that only one person understands are a risk regardless of which side that person is on.
Can we take it elsewhere? Ask directly about code ownership, documentation, and whether another firm could reasonably pick it up.
Ask the data question early
Can we export everything, in standard formats, whenever we want?
The answer should be immediate and unqualified. Hesitation, or an answer about proprietary formats and export tooling, is telling you that your switching cost will rise over time — and that cost becomes a negotiating position against you at every renewal.
A partner confident in the work does not need lock-in to retain clients.
What a portfolio does and does not tell you
A portfolio proves capability existed on some project, once, possibly with a different team.
More useful:
Ask about a project that went badly. What happened, what they would do differently. A partner with no such example is either inexperienced or not being straight with you. The quality of this answer is the most diagnostic thing in most evaluations.
Ask to speak to a client from two years ago, not a recent one. Recent clients are still in the honeymoon. Two years in, someone knows what maintenance actually costs and how change requests are handled.
Ask who specifically will work on it. Firms sell with senior people and staff with junior ones. Ask who, and whether that is contractual.
Warning signs
- Agreement with everything. A brief with no pushback is a brief nobody examined.
- A fixed price before understanding the data. Either padded heavily or about to become a change-order argument.
- Vagueness about maintenance cost. It exists. Someone is planning to tell you later.
- No questions about your operation. A partner who does not ask how the work happens will build against assumptions.
- Guaranteed timelines before seeing the data. Migration timelines depend on data quality, which nobody has looked at yet.
- Reluctance on export. The clearest signal available.
What we would say about ourselves
We start by documenting the operation rather than collecting requirements, because the process as described and the process as performed reliably differ. We deploy gradually alongside existing systems. Your data stays exportable in standard formats.
We also say no. If a business is single-location with simple stock and one person holding the whole picture, we say the existing arrangement is doing its job. If a mature vertical product already encodes a genuinely unusual regulatory structure, we say buy that instead. Ten deployments have not changed that position — a partner who concludes every enquiry needs them is selling, not advising.
Frequently asked questions
Should we run a formal tender?
For larger commitments it imposes useful discipline. The risk is that tenders reward proposal-writing, which is a different skill from delivery. Balance it with the behavioural questions above.
How much should this cost?
Wide enough range that any figure here would mislead. More useful: ask each partner to break down build, migration, training and first-year maintenance separately. The shape of that breakdown is more informative than the total.
Is a bigger firm safer?
Bigger reduces the risk of the firm disappearing and increases the risk of your project being staffed by whoever is available. Ask who specifically, either way.
Should we ask for a fixed price?
For a well-defined scope, reasonable. For anything involving migration of data nobody has profiled, a fixed price is either padded or a dispute in waiting. A fixed price for the first phase, with the rest scoped after, is usually the honest structure.
What if we have no technical person internally?
Then the behavioural questions matter more, because you cannot evaluate the technical answers. Ask about deployment, migration, maintenance, ownership and export — all answerable without technical knowledge, and all predictive.
Where to start
Before contacting anyone, write down how your operation actually works, including the workarounds and the parts that live in people's heads. That document is your real brief.
Then ask every partner the same five questions: what happens in the first two weeks, what would you push back on, how do you deploy, what does maintenance cost, and can we export everything.
The answers will differentiate them more than any portfolio. And if you want a straight read on whether your operation needs a system at all, get in touch — including if the answer is no.