What Good Looks Like in a Technology Partner

A good technology partner makes your business more capable and independent — whether you keep working with them or not. This is a practical guide to how to evaluate a technology partner: seven principles, the specific questions to ask, and the evidence to demand before you sign. Use it on any vendor before you commit.

Most technology partners look identical at the pitch stage. Every firm arrives with a polished deck, a set of impressive logos, and confident language about outcomes. The pricing structures are hard to compare. The case studies are vague. And the questions you don’t know to ask are usually the ones that matter most.

Knowing how to evaluate a technology partner for the first time is genuinely difficult. You can’t benchmark what you haven’t seen before — and most evaluation guidance either comes from the vendors themselves or treats all technology services as interchangeable. They aren’t. IP Australia’s guidance on IP ownership in contracted work is a useful starting point, but the commercial and operational risks go further than IP alone.

The framework below is what we use with clients who ask how to evaluate a technology partner — whether they’re comparing options for AI automation, workflow automation, or strategic technical oversight. We give it to them before they’ve made a choice, and we invite them to use it on us. Every principle traces back to an outcome for the business, not a feature of the vendor. Marketing decks look identical. Outcomes don’t.

Two ways to use each principle: the Ask them question opens the conversation. The Make them show you items close it. Anyone can answer a question well in a pitch meeting. Not everyone can produce the evidence. Push every vendor from telling to showing — that’s where the differences become visible.

01. They protect what makes you defensible

The outcome you want: Your IP stays a moat. Nothing that makes your business valuable leaks, gets copied, or sits exposed on someone’s laptop.

Most technology builds accidentally erode the thing they were meant to protect. A rules engine gets ported to a browser. A calculation gets exposed through a public API. A customer-facing document reveals the logic that produces it. By the time you notice, competitors have caught up, and what once separated you is now the industry baseline.

A good partner filters every architectural decision through whether it exposes your IP. Rules engines run server-side. Customer-facing outputs are flattened, watermarked, and signed. Customers see the result, not the derivation. Access is role-based and audit-trailed by default, not bolted on after the fact.

Watch for: Vagueness about IP protection. Any suggestion that calculation logic will be exposed to a browser, a customer, or a third-party integration. “We’ll figure out security later.” No distinction between what the platform shows internally and what it shows externally.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “Walk me through the specific architectural decision that keeps our IP from leaving the building.”

Make them show you:

• A redacted architecture diagram from a previous build showing where the sensitive logic lived and how it was isolated. If they can’t produce one, they haven’t done this before.
• A reference call with a client whose IP they protected. Ask that client directly: did anything leak? What did the vendor do when a design decision risked exposure?
• Their standard contract clauses on IP ownership and confidentiality — before you ask for them.

02. They amplify your people, not replace them

The outcome you want: Your top experts do more of what only they can do, and less of what shouldn’t require them. The bottleneck shifts, or dissolves entirely. The people who make your business valuable stay valuable — and get to spend their time on work that actually needs them.

Most knowledge-heavy businesses hit a ceiling set by one or two people’s calendars. The tempting move is to build a platform that routes around the bottleneck — automating the expert out of the loop. That decision fails every time. The expert is still needed; you’ve just made them harder to reach.

A good partner designs for your experts as first-class users. They understand the difference between routine work (which should flow through the platform) and judgement work (which should route to the expert with everything they need to decide in minutes, not hours). They give your experts control over the rules that govern that routing.

Watch for: Any suggestion the platform will “handle approvals” or “automate expert review.” Any workflow that still requires your expert to sign off on every routine transaction, leaving the throughput cap unchanged. Any design that hides the expert’s contribution behind the platform rather than making it visible.

Ask them: “What does our expert’s day-to-day workflow look like after the platform is live? Walk me through it.”

Make them show you:

• A reference call with a client’s actual expert — the person whose workflow changed, not the CEO who signed the deal. Ask the expert directly: is your day better or worse than before the platform?
• A case study from a build where a key person was the bottleneck and what their role looks like now. If every case study is about headcount reduction, that tells you their philosophy.
• A before-and-after workflow diagram from a real engagement showing where the expert sat in each.

03. They share the delivery risk with you

The outcome you want: You pay for delivered work, not for promises. You can see exactly what you’re paying for and why — line by line, month by month. If the vendor stops delivering, you stop paying. Neither side is locked in.

The traditional consulting commercial model transfers all delivery risk to the client. Time-and-materials with no cap. Fixed-fee that quietly becomes variable when scope shifts. Large upfront payments before value comes back. Opaque invoices where you can’t tell what you actually bought. The vendor gets paid whether or not the work is delivered on time, to spec, or to standard. That is not a partnership.

A good partner structures things so their business only works if they keep delivering. Every invoice is traceable to a specific piece of work, agreed in advance. Acceptance criteria set before the build starts, not after. Clear exit terms with modest notice periods. If the work stops delivering, either side can walk without penalty.

Watch for: Time-and-materials with no cap. Large upfront payments before delivery begins. Fixed-fee contracts where every scope discovery becomes a change-request invoice. Invoices that arrive as a single line item with a large number. Any arrangement where you cannot clearly connect a payment to a deliverable.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “If we stopped seeing value from your delivery in month three, what would happen commercially? And can you walk me through exactly how your invoicing works — what we’d be paying for and when?”

Make them show you:

• A redacted invoice from a real engagement. Can you understand it without the vendor explaining it? Line items, team allocation, what was delivered that month?
• An example — a real one, with dates — of an engagement where they paused, reduced, or refunded because delivery slipped. If it’s never happened, either they’re perfect or the contract never allowed it.
• Their standard exit terms in writing, before negotiation starts.

04. They design for change, not around it

The outcome you want: When your business evolves, the platform bends. Scope changes get absorbed, not weaponised. You’re never held hostage to a mid-flight decision.

Additionally, most builds hit scope changes six weeks in. Either the vendor discovers new complexity, or you learn something you didn’t know at the start. A rigid partner turns that moment into a negotiation, and every adjustment becomes an invoice. A good partner expects it.

A good partner builds in small, self-contained units. Scope locks at each unit’s start, but honesty runs throughout. They tell you when a change is small enough to absorb and when it’s large enough to warrant a proper conversation, in writing, before anything moves. They surface complexity as soon as they see it — not after the invoice cycle.

Watch for: Any change process that turns every scope conversation into an invoice. Rigid arrangements that punish adjustment. Vague language about “we’ll re-plan” without a defined mechanism. Vendors who go quiet when complexity emerges and resurface with a change order.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “What happens if we discover more complexity halfway through the build? Give me a specific example of how that played out with a previous client.”

Make them show you:

• A change log from a real engagement showing which changes were absorbed at no charge and which were re-scoped. The ratio tells you their real philosophy.
• A reference call with a client whose scope shifted materially mid-build. Ask them: how did the conversation go? Did it feel collaborative or transactional?
• Their written change-management process, if one exists. No written process usually means the process is “whatever the vendor decides at the time.”

05. You own the outcome, top to bottom

The outcome you want: The code, the IP, the platform, the data. Yours. You can extend it, replace it, or take it elsewhere. You are never renting access to your own asset.

Some technology partners build platforms that only they can maintain. This arrangement makes the client technically the owner but practically the tenant. Six months in, extending the platform means going back to the same vendor, at the same rate, without any alternative.

A good partner delivers full source code ownership from the start. A shared repository with your team credentialled from day one. Documentation produced as a work artefact, not an afterthought. Another partner could pick up the codebase within a week if you needed them to.

Watch for: Any licencing arrangement where you rent access to your own platform. Code that lives only on the vendor’s infrastructure. Exit terms that make leaving expensive, slow, or contingent on the vendor’s cooperation.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “If we ended the engagement tomorrow, what could we take with us and what would stay?”

Make them show you:

• The repository access structure from a current engagement (redacted). Who has access? Is the client’s team credentialled, or is access “available on request”?
• A sample of their documentation from a previous build. Could a new developer, with no contact with the vendor, understand it?
• The strongest proof there is: a reference call with a client who left them and took the platform to another partner — and whether the vendor gave that reference willingly.

06. They fit into your existing ecosystem

The outcome you want: The vendors, tools, and partners you already trust keep working. The new platform doesn’t ignite turf wars with your incumbents. Your business runs while the platform is being built, not in spite of it.

Moreover, very few technology decisions happen in isolation. Most businesses already have an ERP, a CRM, an incumbent development partner, existing licences and contracts. A partner that ignores that ecosystem isn’t proposing a technology solution — they’re proposing a disruption.

Additionally, a good partner maps your existing ecosystem during discovery. They define the integration boundary with your incumbents in writing before the build starts. Where their scope overlaps with someone else’s, they clarify who owns what — and put it in the contract.

Watch for: Any suggestion that your existing vendors need to be replaced. Vagueness about integration boundaries. “We’ll take over that work.” Refusal to engage directly with your incumbents. Any pattern of the vendor complaining about an incumbent to you rather than solving it with them directly.

Ask them: “How do you plan to coordinate with our existing vendors during this build?”

Make them show you:

• The name of an incumbent vendor they’ve worked alongside on a previous engagement — then call that vendor, not just the client. The incumbent’s view of them is the least-varnished reference you’ll get.
• A written integration boundary document from a previous build. If they’ve never produced one, the boundaries were never defined.
• An example of a scope overlap with an incumbent and how it was resolved — specifics, not principles.

07. They stay after the build

The outcome you want: Someone answers when something breaks. Support is a model with names, response times, and a price — not a favour you have to negotiate at 5pm on a Friday. The team that built your platform doesn’t vanish the day it goes live.

Furthermore, most consultancies specialise in the build phase only. The engagement ends, the team rolls onto the next client, and six months later — when something breaks, or a browser update kills a feature, or you need one small addition — you are starting a new commercial conversation with no guaranteed outcome.

When you evaluate a technology partner, one of the clearest signals is what their post-build model looks like. A good partner puts this in the proposal, not in a follow-up conversation. Named support contacts, defined response times for different severities, a clear price for ongoing support versus warranty — in writing, before you sign.

Watch for: No mention of what happens after go-live. Support “available on request” with no defined model. Warranty terms that are vague or absent. Any vendor whose proposal ends at the launch date. A support price that only appears after you’ve signed the build contract.

Ask them: “It’s six months after go-live and something breaks on a Friday afternoon. Who do I call, what happens next, and what does it cost?”

Make them show you:

• Their standard support agreement — response times, severity definitions, pricing — before you sign the build contract, not after.
• A reference call with a client who is 12 or more months post-launch. Ask them: what happened the last time something broke? How long did it take? What did it cost?
• The name of the person who would own your account after go-live. If the answer is “we’ll assign someone,” the model doesn’t exist yet.

How to Evaluate a Technology Partner Using This Framework

To get the most from this guide on how to evaluate a technology partner, take the “ask them” question from each principle and sit down with every vendor you’re considering. Ask the same questions, in the same order. Do not fill in silences. Do not accept marketing generalities in place of specific answers.

Then push past the answers. Every principle carries a “make them show you” list — references you can actually call, artefacts they can actually produce, clients who were in your position 12 or 18 months ago. Anyone can answer a question well in a pitch meeting. The evidence is where vendors separate.

Two questions worth asking every vendor, regardless of principle:

“Can you show me a client who is no longer working with you, and would they take a call from me?”

“What would you build differently if you knew from day one that we might not renew?”

In practice, the differences in how partners respond to these questions will be diagnostic. Any partner who is uncomfortable with them is telling you something about what the rest of the engagement will feel like.

You are welcome to use this framework on us.

If a partner hesitates to be evaluated against it, that hesitation is itself an answer.

The one-sentence version

Every principle in this guide to how to evaluate a technology partner is a version of the same question.

Does this partner make your business better off, whether you keep working with them or not?

Typically, the vendors who fail this test optimise for lock-in: of your IP, your capital, your expertise, your ecosystem. Every commercial and architectural decision is quietly designed to make leaving harder. However, the vendors who pass it optimise for your leverage. You should end the engagement stronger, more capable, and freer than you started.

If they have done their job well, you should have more options at the end, not fewer.

Specific Questions Worth Answering Before You Sign

How to evaluate AI consulting partners for ecosystem fit

Ecosystem fit means the partner can work within your existing stack without requiring you to replace it. The test is not whether they know your tools — it is whether they ask about them before proposing anything.

Ask them to name the tools your business already uses. Ask how their solution will connect to them. Ask what the integration boundary looks like and who maintains it after go-live. A partner with genuine ecosystem experience will answer in specifics: which APIs, which middleware, which authentication approach. A partner without it will describe the capability in general terms and defer the detail to later.

The third test: ask what happens if you need to add a new tool in 12 months. If the answer requires their ongoing involvement, that is a dependency, not a solution.

What a CTO should prioritise when evaluating AI partnership options

In order: IP ownership, documentation quality, skills transfer, and exit terms.

IP ownership determines whether the models, prompts, training data, and workflows built during the engagement belong to your business or the vendor. If the vendor retains ownership of the AI logic they build for you, you cannot move, modify, or rebuild it without them.

Documentation quality determines whether your team can understand, maintain, and extend what was built. Ask for a sample handover document from a previous project. If it is thin or relies on tribal knowledge, plan accordingly.

Skills transfer determines whether your technical team grows from the engagement or becomes more dependent on the vendor. The right partner runs sessions with your developers, not just presentations to your leadership. Exit terms determine the cost of switching. If the commercial structure makes leaving expensive, factor that into the risk assessment before you sign.

How to evaluate discovery workshop capability in a software or AI partner

The output of a discovery workshop should be a scope document your team can read without the vendor in the room. If it requires interpretation, it is not finished.

Good discovery capability shows up in four ways. First, the workshop runs to a structured agenda with named outputs, not an open conversation. Second, the partner captures requirements in your language, not theirs. Third, the scope document distinguishes between what is fixed, what is flexible, and what is out of scope. Fourth, there is a change control process explained before the build starts, not negotiated after the first change request lands.

Ask to see a sample statement of work or scope document from a previous engagement. Ask who runs the discovery — a consultant or a developer. Ask what happens to requirements that emerge mid-project.

What a typical automation engagement looks like: discovery, build, testing, and handover

A well-run automation engagement has four distinct phases, each with a clear output before the next begins.

Discovery runs for one to three weeks. The output is a documented process map, a list of automation candidates ranked by effort and business impact, and a scope with acceptance criteria written before the build starts. If acceptance criteria come after the build, there is no agreed definition of done.

Build is iterative with client checkpoints, typically every one to two weeks. You should see working software at each checkpoint, not status updates. Testing uses the acceptance criteria from discovery. Your team runs user acceptance testing, not just the vendor’s QA. Any issue raised during testing maps to a specific criterion from the scope.

Handover includes working code in your repository, documentation your team can follow, a training session for the people who will use or maintain the system, and a defined support window. A handover that consists of a video call and a shared folder is not a handover.

How to protect your business IP and data when working with an AI or automation consultant

The contract governs this. Read the IP assignment clause before you sign anything.

The specific questions to ask: who owns the models, prompts, training data, and workflows built during the engagement? Where is your data stored and processed? What happens to your data if the engagement ends? Is there a data deletion clause?

The practical test: ask the vendor what you would take with you if the engagement ended tomorrow. The answer should be everything built for you, stored in your systems, with no ongoing dependency on theirs. If the answer is conditional or unclear, that is your answer.

Red flags to look for when scoping an AI automation project with a new partner

They cannot give a fixed price or estimate without a paid discovery, but the discovery scope itself is also undefined. One paid discovery is reasonable. An undefined chain of them is not.

The proposal is written in capability language rather than outcome language. Features and platform descriptions are not a scope. Outcomes, acceptance criteria, and timelines are.

They do not ask about your existing systems or team capability in the first conversation. References they offer are from their own network, not from clients in a situation similar to yours. Exit terms are absent from the proposal. IP ownership is deferred to legal review without a stated intent in the commercial terms.