What to Look For Before Hiring a Technology Partner

Ask why, not just what

You do not need to evaluate a technology stack on technical merit, and you should be suspicious of any process that requires you to. What you do need is a clear reason for each significant choice, expressed in terms of your constraints rather than the partner's preferences: your team's existing skills, your budget for running costs, the systems you must integrate with, and how much change you expect in the next two years.

A good partner will answer a 'why' question with a trade-off. 'We would use a managed database rather than self-hosting because you have no infrastructure staff, and the cost difference at your volume is under two hundred a month.' A weaker partner will answer with a preference — 'it's what we always use' — or with a list of buzzwords that do not connect to anything you said.

Pay particular attention to reversibility. Ask which decisions would be expensive to undo in a year, and what it would take. Every project accumulates lock-in; the question is whether the partner is choosing it deliberately or by habit.

Security and data handling

Security questions intimidate non-technical buyers, but you do not need to audit code to learn a great deal. You need to know where your data lives, who can reach it, what happens when something goes wrong, and what evidence the partner can give you when a customer or regulator asks.

• Where your data is stored and processed, and under which jurisdiction
• Access control for their team and yours, including how access is removed when people leave
• How dependencies are patched and how quickly a disclosed vulnerability is addressed
• Backup frequency, retention, and whether restores are actually tested
• Incident response: who tells you, how fast, and what the first twenty-four hours look like
• Evidence they can supply for your compliance obligations, and what they will not sign

Ownership: accounts, code and credentials

The most damaging disputes in technology engagements are almost never about quality. They are about ownership. A buyer discovers, midway through a difficult separation, that the cloud account is in the partner's name, the domain renews on the partner's card, and the source history lives in a repository they cannot access.

Establish ownership on day one, in writing, and verify it rather than assuming it. Cloud accounts, DNS, app store listings, analytics, error monitoring and source repositories should all be owned by your organisation with the partner invited in. This is standard practice among mature firms and costs nothing to arrange at the start.

Documentation and handover

Assume, as a planning default, that a different team will maintain this system within three years. That assumption changes what you ask for. Documentation stops being a nice-to-have deliverable and becomes the mechanism that keeps your options open.

How progress is demonstrated

Ask to see working software at a fixed cadence, in an environment you can click through yourself. Demonstrations of running software are the only progress report that cannot be padded. A partner who prefers status documents to demos may be managing perception rather than delivery.

Agree what happens when an estimate slips, because at some point one will. The healthy pattern is early disclosure with options: reduce scope, extend time, or add cost. The unhealthy pattern is silence followed by a large surprise near the deadline.

1. 1Can we see working software every two weeks in an environment we control?
2. 2What does your definition of 'done' include — tests, documentation, deployment?
3. 3How do you handle a discovered requirement that was not in the original scope?
4. 4What is your process when an estimate is going to be missed?
5. 5Who has authority to accept work on our side, and what does acceptance mean?

Life after launch

Launch is the beginning of the cost, not the end of it. Agree support hours, response targets by severity, and how change requests are prioritised against maintenance. Also agree who pays for dependency upgrades and security patches, because that work is invisible, unavoidable and frequently unbudgeted.

Software that nobody maintains becomes a liability faster than most buyers expect. A modest ongoing arrangement — a fixed number of hours a month covering patches, monitoring and small changes — is almost always cheaper than the rescue project that follows two years of neglect.