How to choose a technology consulting partner: 7 checks

To choose a technology consulting partner, check seven things before you sign: who will do the work, what proof they have of similar work, how they engineer, how they handle security, who owns the code, how the price can change, and how you can leave. A firm that answers all seven in writing is a safer choice than a firm with a better pitch.

The sections below turn each check into questions you can put to a shortlist, along with the warning signs that tend to show up early.

Start with the outcome, not the vendor list

Before you compare firms, write one page that states the business result you want, the date that matters, the systems involved and your constraints, such as budget range, regulation and where data must stay. Send the same page to every firm. Proposals become comparable, and a firm that replies with a generic deck has told you something useful.

Decide what kind of help you are buying. Advice on direction, a team that builds a product, engineers who join your team and a service that runs a system are four different purchases. The checks below apply to all of them, whether the work is AI and data, digital product engineering or cloud.

Seven checks to choose a technology consulting partner

1. The people. Ask for the names, roles and time allocation of the delivery team, not the sales team. Interview the lead engineer or architect yourself.
2. The proof. Ask for a walk-through of one comparable project: the architecture, what went wrong and what changed as a result. A call with a past client’s technical lead tells you more than a page of logos.
3. Engineering practice. Ask to see how they work: a code review, the test approach, the deployment pipeline, and how AI coding tools are used and reviewed.
4. Security. Ask where your code and data will live, who can reach them and what independent evidence backs the answer.
5. Ownership. Ask what the contract says about code, data, models and anything the firm brings with it.
6. Price and change. Ask what is included, how changes are priced and what you receive at each payment.
7. Reporting and exit. Ask what you will see every week and what the firm must hand over if you end the contract.

The first three checks are about capability. The last four are about risk, and they are the ones buyers most often skip.

How to verify security claims

Certificates and audit reports are evidence, not proof, and you should know what each one covers. ISO/IEC 27001, whose current edition dates from 2022, sets the requirements for an information security management system. Conformity means the organization has a system in place to manage risks to the data it owns or handles. A SOC 2 report comes from the AICPA’s SOC suite of services. It is an examination by a CPA of a service organization’s controls relevant to security, availability, processing integrity, confidentiality or privacy.

Ask for the certificate scope or the report itself, then check the date and whether the scope includes the team and systems that will touch your work. After that, ask the practical questions:

• Will code and data stay in your repositories and cloud accounts, or in theirs?
• How is access granted, reviewed and removed when someone leaves the project?
• Are the engineers’ devices managed, and how are secrets and credentials stored?
• What happens in an incident, and how quickly are you told?
• Which subcontractors or third-party AI tools will see your code or data?

If the work involves regulated data, bring your own security and compliance advisers into this conversation. You may also need to tighten controls on your side, which is cloud security and compliance work in its own right.

Who owns the code and the data

Do not assume that paying for software means you own it. In the United States, the Copyright Office explains in Circular 30 on works made for hire that a commissioned work is a work made for hire only when it falls within one of nine listed categories and the parties have signed a written agreement saying so. This is one reason technology contracts usually deal with ownership through explicit written terms. The rules differ from country to country.

Questions to settle before signing:

• Does the contract transfer all deliverables to you, and at what point?
• Which existing tools, libraries or accelerators will the firm bring, and under what license can you keep using them?
• Which open source components will be used, and under which licenses?
• Who owns trained models, prompts, evaluation sets and data derived from yours?
• Will the code sit in your repositories from the first day?

This is general information, not legal advice. Have your own lawyer review the ownership and confidentiality terms.

Pricing, reporting and the way out

Ask each firm which commercial model it proposes and why. Fixed scope, time and materials, a dedicated team and a managed service each place risk in a different spot, and the guide to technology engagement models covers the trade-offs. Whatever the model, get clear answers on these points:

• Inclusions. What the price covers, and what it leaves out, such as testing, project management, cloud costs and support after launch.
• Change. How a change is estimated, who approves it and how it affects the date.
• Payments. Whether milestones are tied to working software you can inspect, not to calendar dates.
• Reporting. A regular demo of working software, plus a written status that compares budget spent with progress made.
• Exit. The notice period, and the handover the firm owes you: documentation, credentials and time for knowledge transfer.

A firm that is confident in its work will not need a contract that makes leaving hard.

Warning signs, and how to test before you commit

Most problems are visible during the sales process if you look for them.

• A fixed quote or a return on investment figure arrives before anyone has asked about your data, systems and constraints.
• Every problem leads to the same platform or product.
• The senior people in the pitch cannot say who will do the work.
• Nobody will show you code, tests or a pipeline.
• Ownership terms are vague, or the code will be hosted in the firm’s accounts.
• The firm resists a reference call or a small first engagement.
• Every answer is yes. A good partner tells you what it would not do.

The most reliable test is a small paid piece of real work, such as a short discovery phase or one thin feature built end to end. Judge the firm on the quality of its questions, how it handles a surprise, the state of what it hands over and whether its estimate held. You learn more from this than from any proposal, and you keep the output whichever firm you choose.

How YLinkTech helps

YLinkTech is a technology consulting and engineering firm that works across AI and data, product engineering, cloud and technology talent. We would rather be assessed on the checks above than on a pitch. Our delivery steps and engagement models are published, we build in your repositories and cloud accounts, and most engagements can begin with a short, scoped assessment or discovery sprint. If you are comparing partners, tell us what you need to deliver and we will say plainly whether we are the right fit.

Frequently asked questions

Sources

• ISO: ISO/IEC 27001:2022 Information security management systems
• AICPA & CIMA: System and Organization Controls: SOC Suite of Services
• U.S. Copyright Office: Circular 30, Works Made for Hire

This article is general information, not professional advice. See our Disclaimer.