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.