How do I evaluate a development partner beyond looking at their portfolio?
Portfolios show what shipped, not what happened. Evaluate on three things instead: how they respond when you describe a bad idea, whether they can explain a past project's failure mode specifically, and what they ask about your data before proposing a solution. A partner who quotes a solution before asking where your data lives has not scoped anything.
Screenshots prove very little
A portfolio tells you a project reached a state worth photographing. It does not tell you whether it came in on schedule, whether it still runs, whether the client could maintain it, or how many painful conversations produced it.
The more useful evidence is behavioral, and you can gather it in a single conversation if you ask the right things.
Four questions that separate people quickly
- Describe something a client asked for that you talked them out of. A partner with no examples either has no opinions or never voices them. Both are expensive.
- What broke on a previous project and how did you find out? Listen for monitoring and alerting. If the answer is the client called us, they build without instrumentation.
- What would you need to see in our systems before estimating this? Good answers name specifics: API access, record volumes, how many years of history, which fields are actually populated.
- What is the smallest version of this that would still be useful? Someone who can answer this thinks in slices and will not hold your project hostage to a big-bang launch.
Watch what they do with your bad idea
Bring a request that sounds reasonable but is subtly wrong — for example, asking to score every technician automatically and rank them. A serious partner will not just say yes.
They should push back on the framing: what standards, defined by whom, reviewed by which manager, and what happens when the data is thin for a new hire. That is the correct instinct. In evaluation work the outputs support human coaching decisions rather than replacing them, and a partner who does not raise that on their own will build you something you regret using.
Structural things worth confirming
Beyond conversation, verify a few concrete conditions. Code lands in your repository from week one, not at the end. There is a named person who knows the project besides the one you talk to. They can describe how they handle a vendor API change. And they are willing to start with a small paid piece of work rather than a long commitment.
That first small engagement is the highest-signal diligence available. You learn more from one delivered slice than from any number of reference calls — which is why we prefer to start integration engagements with a narrow, real deliverable and let the work speak. If you want to test that, describe the problem rather than the solution and see what comes back.
Topics: vendor selection · development partner · diligence · scoping
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.