How to hire a software consultancy for an industrial business

If you run a plant, a yard or a distribution center, you have probably been burned by a software project before. A package that did not fit. A custom build that ran late, then ran away from the original scope. A vendor who owned the only copy of the code.

Buying software help is a different skill from running operations. This guide covers what to ask, what to watch for, and how to set up the paperwork so you stay in control.

Do you need a consultancy at all?

Sometimes you do not. Be honest about the alternatives.

• Off-the-shelf software is the right answer when your process is close to standard. Do not custom-build what you can buy.
• Your in-house IT can handle a lot, if they have the time. The usual constraint is capacity, not skill.
• A freelancer works for a well-defined, small piece of work, but you carry the risk if they disappear.
• A consultancy makes sense when the problem spans systems (ERP, scale, shop floor, customers), when you lack the time or skills in-house, or when you need someone to design and then build.

A good consultancy will tell you if you do not need one.

What should you ask before you sign?

Ask these and listen to how specific the answers are.

1. Have you worked in operations like mine? You are not looking for a name list. You want someone who knows what a scale ticket, a BOM or a dock appointment is without a lengthy explanation.
2. Who will actually do the work? The people in the sales meeting and the people writing code are often different. Ask to meet the latter.
3. What happens in the first month? A good answer involves interviews, looking at your actual systems and data, and a written output. A bad one is a proposal.
4. How do you handle a system nobody understands? Legacy and undocumented systems are normal. They need a method.
5. What will you show me, and when? Working software every week or two beats a status report.
6. What do you need from my team? If the answer is “nothing,” they have not thought about it.
7. What happens if we stop? You should be able to leave with your code, your data and enough documentation for someone else to continue.
8. What would you advise us not to build? This tells you whether they sell hours or solve problems.
9. Can I talk to a client? Fair to ask of any established firm. A newer firm should be upfront that it has fewer references and explain how it manages that risk instead of dodging.

What are the red flags?

• A large quote before they have looked at your systems. Nobody can price your project from a thirty-minute call.
• Vague scope with a time-and-materials budget and no cap or checkpoints. The meter runs while the target moves.
• Pressure to decide quickly, or discounts for signing this week.
• A proprietary platform you must keep using. If the software only runs on their framework or their hosting, you are renting.
• No questions about your people. Software that operators will not use does not matter how good it is.
• Jargon in place of answers. If you leave a meeting unsure what they will deliver, assume they are too.
• Promises about AI results with no mention of data. Ask what the model will be trained on and how you will measure it.
• Reluctance to put ownership terms in writing.

How should the engagement be structured?

A shape that tends to work for industrial businesses has phases with decision points, so you can stop or change course at low cost.

Phase	What happens	Typical shape	Your decision
Assessment	Interviews, system and data mapping, written findings, prioritized roadmap	Short (a few weeks), fixed fee	Proceed, change scope, or stop with a useful report
Build	Working software delivered in increments	Fixed scope or phased, with weekly demos	Approve each phase before the next
Run	Support, monitoring, iteration	Monthly retainer	Renew or end
Advisory	Technology leadership as needed	Monthly	Renew or end

Starting with a paid assessment is not a sales trick. It is how both sides find out whether the project is worth doing before anyone commits to a build. If the assessment says “do not build this,” you saved real money.

Fixed price or time and materials?

Neither is always better.

• Fixed price suits work with a clear scope. The risk is that vague scope hides in a fixed price, and the consultancy protects itself with change orders for everything.
• Time and materials suits exploratory work. The risk is no ceiling. Ask for a cap, weekly burn reporting and a checkpoint at each milestone.
• Phased fixed scope is often the best fit: fix the price of the next phase, not the whole program.

Whatever you choose, write the acceptance criteria in terms an operator would recognize: “a clerk can enter an inbound load in under two minutes,” not “the module is complete.”

Who should own the code and the data?

You should. Put it in the contract, not in an email.

Check these clauses:

• Code ownership: work product is assigned to you on payment. Any pre-existing tools the consultancy reuses are licensed to you permanently for use in your system.
• Repository access: your code lives in a repository you control, from day one, not one you get at the end.
• Data ownership and location: your data stays yours and sits in accounts under your control.
• Open technology: common languages, databases and cloud services that another firm can pick up. Be wary of niche frameworks.
• Documentation: architecture notes, setup steps and a runbook delivered as part of the work.
• Third-party licenses: a list of any paid components and who holds those licenses.
• Credentials and access: admin access to cloud accounts is yours.

Ask yourself one test question: if the consultancy closed tomorrow, could someone else keep this running? If not, fix the contract.

What else belongs in the contract?

• Clear acceptance criteria and a process for sign-off
• A change process, so scope changes are priced before work starts
• Confidentiality and data handling terms appropriate to your customers
• Security expectations: access control, backups, who can see production data
• Termination terms that let you leave with everything, with a reasonable notice period
• Named key people, and what happens if they leave the project

Have your own counsel read it. A short contract that is specific beats a long one that is vague.

How do you run the relationship well?

Assign one internal owner with authority to make decisions. Hold a short weekly review where you use the software, not read about it. Put an operator in that review, not just a manager. Keep a written list of decisions so scope does not drift unnoticed.

And pay attention to the first month. How a firm behaves when it finds something messy in your systems tells you more than any pitch.