How to evaluate a technical partner
Most pages like this one exist to make the vendor look like the obvious choice. This section is more useful if it does not. Below are the questions worth asking any technical partner, including the ones where our answer might send you elsewhere.
- Who writes the code, and is it the people I have spoken to? A partner that quotes with senior staff and delivers with juniors is the most common failure mode in this category.
- What happens when a date is at risk, and how do I find out? The answer should involve you hearing it before your client does. If it does not, the arrangement will eventually cost you a relationship.
- Can I see real documentation from a finished project? Not a case study. The actual handover notes. This tells you more than any portfolio.
- What do you refuse to take on? A partner with no answer either has not thought about it or will say yes to work they cannot do.
- If I stopped working with you tomorrow, could my team maintain what you built? If the honest answer is no, you are not buying delivery, you are buying dependency.
Where we are the wrong choice
If you want developers billed hourly whom you direct day to day, you want staff augmentation and there are firms who do that well. We quote and deliver defined work rather than renting out time, and agencies expecting the former are usually frustrated by the latter.
If your technical work is steady enough to keep one person busy every week of the year, hiring is probably cheaper over a three-year horizon and gives you someone who knows your accounts deeply. The case for a partner is strongest when volume is uneven, which for most agencies it is.
And if you are optimising purely for the lowest possible cost, there are cheaper options offshore. What you would be trading away is review, documentation and someone still being there in six months. That trade makes sense for some agencies. It is worth making deliberately rather than discovering later.
What the first 30 days look like
There is no lengthy onboarding programme. A first project starts with a conversation about what is currently stuck, then a scoped pilot — usually a build, a stalled audit, an integration or a site that needs rescuing. Small enough that being wrong about us costs you very little.
During that project you find out the things that actually matter: whether we flag problems early or late, whether the documentation is real, whether the work needed fixing after handover, and whether communicating with us costs you management time you do not have. Those are the criteria we would use in your position.
If it works, the conversation about ongoing capacity is straightforward because both sides have evidence. If it does not, you have lost one project rather than a quarter.
