Ask about the work, then examine the evidence
A useful partner-selection conversation goes beyond a technology list. Ask how the team learns the business, challenges assumptions and makes delivery decisions visible. Request an example artifact with confidential information removed: a discovery note, acceptance criterion, release checklist or handover guide. A polished portfolio may show visual ability while saying little about maintainability or everyday collaboration.
Use one scenario with every candidate
For a fictional service business, describe a request that must move from quotation to approval and invoicing. Ask each candidate what they would clarify, what they would leave outside the first release and which integration could block progress. Compare their reasoning against the same scenario. The strongest answer may identify an operational change before proposing custom software.
Discuss uncomfortable situations early
Ask what happens when an estimate proves wrong, a dependency slips or a key developer leaves. Explore who owns source code and accounts, how you inspect completed work and what another team would receive at handover. A lower headline price can exclude testing, migration or operation; a larger team can introduce coordination costs. Compare explicit scope and responsibilities rather than treating either size or confidence as proof.
Compare a small piece of real reasoning
Prepare a common evaluation pack for the quotation-to-invoice scenario. Include a short process description, a sanitized example, the people who decide and the constraints you already know. Give candidates the same material and separate genuine questions from assumptions they have filled in themselves. You are looking for how they expose uncertainty, not whether they can instantly produce the most confident estimate. A sensible refusal to estimate an unknown integration can be more useful than an unexplained number.
Ask each candidate to show how one decision would move through delivery. For example, if the customer can revise an approved quotation, who identifies the accounting consequence, proposes alternatives and confirms the chosen rule? Follow that rule into an acceptance example and a visible work item. This exercise reveals whether business reasoning survives the handoff between sales, design and engineering. Keep the exercise bounded; request permitted existing artifacts or agree the terms of a small paid assessment rather than expecting substantial unpaid implementation.
Make a comparison note that distinguishes claims, evidence and unresolved questions. A reference conversation, where permission exists, can discuss communication during a difficult change rather than only the final launch. A sample handover can show how another operator finds setup instructions, credentials ownership and the current release. Evaluate missing evidence openly; do not turn brand recognition, headcount or an impressive presentation into a proxy for suitability. Before choosing, ask who will actually work on the engagement and how responsibility changes if that person becomes unavailable. The resulting decision may favor a smaller focused scope, a different working arrangement or no custom build at all. Those are valid outcomes of a selection process that is examining the work honestly.
A comparison sheet grounded in evidence
| Decision area | What would count as useful evidence |
|---|---|
| Understanding the workflow | The candidate identifies the quotation-change consequence and records the agreed business rule without silently inventing missing facts. |
| Making progress reviewable | A sample connects a user outcome, acceptance case and delivered result so the business can inspect progress without reading every commit. |
| Handling disrupted delivery | The proposed response names decision owners, communication and scope choices when a dependency or key person becomes unavailable. |
| Preserving continuity | A permitted handover example and explicit responsibility list explain how the business retains usable code, accounts and operating knowledge. |
Make selection a mutual assessment
Bring a short problem brief to Orvun Labs’s custom-software conversation. Agree a useful next artifact and its cost before committing to a whole product. References should be real and shared with permission; do not ask a candidate to expose another customer’s private material.
- What decisions will the business need to make each week?
- What is included in delivery and what remains an assumption?
- How will code, accounts and documentation be transferred?
- What would make this team decline the project?