Choosing a software partner is difficult because every proposal describes a competent, collaborative, agile team. The useful differences appear when you ask how the work will actually run: who makes decisions, how uncertainty affects the estimate, what quality means in practice, and who is still there when the first production issue arrives.
A portfolio matters. So do references. But the first conversations should help you see the team’s judgement, not only its sales process.
The twelve questions worth asking
- What business outcome would you use to guide product decisions?
- Which assumption in our brief feels most dangerous or expensive?
- What would you deliberately leave out of the first release?
- Who will actually work with us, and can we meet them before signing?
- How do product, design, and engineering decisions stay connected?
- What is included, excluded, and assumed in the estimate?
- How will we see working progress and current spend each week?
- How do you handle a change that affects scope, time, or cost?
- What quality, security, accessibility, and performance checks are part of delivery?
- Who owns the code, infrastructure, accounts, data, and documentation?
- What happens during an incident or critical production issue?
- How will you leave our team stronger and less dependent on you?
The exact wording of the answer matters less than the specificity. Strong teams describe a real operating model. Weak answers stay at the level of “best practices,” “transparent communication,” and “industry-leading quality” without explaining what you will see or who is accountable.
Healthy answers and warning signs
What to listen for
A focused way to test assumptions, map constraints, and decide what not to build.
A paid prelude that produces documents but does not change a decision.
Ranges, assumptions, exclusions, dependencies, milestones, and a plan to reduce uncertainty.
A very precise number built from a very imprecise brief.
Direct contact with the senior people responsible for product and technical choices.
The experts disappear after the pitch and all communication moves through an account layer.
Concrete practices tied to the product’s risk: review, automated checks, accessibility, security, observability, and release controls.
A promise that the QA phase near the end will catch everything.
Your organisation controls the important accounts, code, data, and documentation from the start.
Critical infrastructure or knowledge is held in supplier-owned accounts with no clear exit path.
Security belongs in procurement, not only development
Ask how the team identifies risk, manages secrets and access, reviews dependencies, handles vulnerabilities, protects environments, and communicates incidents. CISA’s Secure by Demand guidance is explicitly designed to help software buyers ask better security questions throughout procurement and operation.
For application assurance, the OWASP Application Security Verification Standard provides a useful open basis for specifying and testing security requirements. Your project may not need every control at the highest level, but the partner should be able to match rigor to risk rather than offer “secure” as a blanket adjective.
The first conversation should already be useful
A good partner does not need to give free strategy away, but the conversation should sharpen the problem. You should leave with better questions, a clearer risk, or a more focused next step. If the meeting is mostly credentials and a rush toward estimation, you have learned something about how future ambiguity may be handled.
Compare teams on the same evidence
A small amount of structure makes very different proposals easier to judge.
- 01
Share the same problem brief
Describe the outcome, users, current process, constraints, timing, and known dependencies without dictating every feature.
- 02
Meet the delivery leads
Speak with the people who would own product and technical decisions, not only the people responsible for winning the work.
- 03
Run one working session
Use a real workflow or risky assumption. Notice who listens, who reframes, and whether trade-offs become clearer.
- 04
Check references around difficulty
Ask former clients what happened when scope changed, a release slipped, or production behaved unexpectedly.
Choose the team you want beside you when the plan stops being tidy. That is when a partner becomes visible.
Fit matters more than size
A large supplier can provide capacity and breadth. A smaller senior team can provide focus and direct accountability. Neither is universally better. Match the team to the risk, pace, stakeholder environment, and level of product ownership you need.
At Kalytex, the people shaping the work stay close to the client and the product. You can read more about how we work, review our selected work, or explore the services we bring into an engagement. The useful next step is a direct conversation, not a funnel disguised as one.
