Choosing a software development partner is not simply buying engineering hours. You are selecting the team that will translate business knowledge into decisions, protect sensitive systems, manage delivery risk, and leave you with software that can evolve after launch.
Portfolios and polished presentations help establish relevance, but they do not reveal how a team behaves when requirements conflict, an integration fails, or new evidence changes the plan. Ask the following twelve questions before signing. Strong answers should include specific practices, examples, and artifacts—not only assurances.
Look for interviews, workflow observation, data analysis, prototypes, and validation with representative users. A team should distinguish a requested feature from the underlying job it must accomplish. The U.S. Digital Services Playbook places understanding people’s needs and addressing the whole experience at the beginning of successful digital delivery.
There should be a named person on your side with enough authority and availability to set priorities, answer business questions, and accept outcomes. The partner should provide product leadership, but it should not quietly make consequential business decisions in a vacuum. Ask how decisions, assumptions, and unresolved questions will be recorded.
A dependable team identifies the riskiest assumptions early. It may run a technical proof of concept for an integration, prototype a complex workflow, inspect sample data, or test usability before committing to the roadmap. Ask what discovery produces and which decisions those artifacts support.
Expect working software at frequent intervals, not months of invisible progress followed by a reveal. Demos should connect completed work to acceptance criteria and business outcomes. Ask how often releases reach a staging environment, how feedback enters the backlog, and how forecasts change when new evidence appears.
Ask about peer review, automated tests, exploratory testing, accessibility, performance, supported browsers and devices, and defect handling. Then ask to see anonymized examples: a pull-request checklist, test report, release checklist, or definition of done. Quality should be a delivery system, not a final testing phase.
Strong teams discuss threat-relevant requirements, access control, secrets, dependencies, environments, logging, backups, and incident response before launch. CISA’s Secure by Demand guidance encourages customers to evaluate the security practices of technology suppliers. NIST’s SSDF provides another useful baseline for secure development.
Ask who owns remediation, how vulnerabilities are reported, what is included after release, and whether sensitive information ever enters source control or support tools.
Integration answers should cover authentication, data ownership, failure handling, retries, monitoring, reconciliation, vendor limits, and test environments. Ask what happens when a third-party service is unavailable or changes its API. “We can connect to it” is not an operating plan.
Healthy reporting makes decisions and risk visible. Ask for a sample weekly update. It should explain what changed, what was demonstrated, what comes next, which decisions are needed, and where the forecast moved. A large percentage-complete number can hide more than it reveals.
Change is normal because teams learn during delivery. The contract and working process should distinguish clarification, defect correction, reprioritization, and genuinely new scope. Ask who estimates a change, who approves it, and how its effect on time, cost, and other priorities is communicated before work begins.
Confirm ownership and access for source code, repositories, cloud accounts, data, domains, certificates, analytics, design files, documentation, and deployment pipelines. Your organization should not depend on one vendor-controlled credential to operate its own product. Clarify licensing for third-party and open-source components as well.
Launch planning should include migration, training, support, monitoring, backups, recovery, rollback, and responsibility during the early-life period. Ask which service levels are offered, what counts as an incident, how support is priced, and how routine maintenance differs from new development.
A professional partner plans for eventual transition. Ask how documentation is maintained, how another team would reproduce environments, how credentials and data are transferred, and what handover assistance is included. A clear exit path is not a sign of mistrust; it is sound operational governance.
The evidence does not need to expose another customer’s confidential information. It should show that the claimed process exists in practice.
Before proposals arrive, assign weights to the criteria that matter: relevant domain experience, discovery quality, technical approach, security, delivery transparency, team continuity, ownership terms, support, and total cost. Score each candidate against the same evidence. Price matters, but a cheaper proposal that omits migration, testing, security, or support is not equivalent.
The 18F De-risking Guide emphasizes iterative delivery and productive vendor partnership. One practical takeaway is to structure the relationship so both sides can learn, demonstrate progress, and change direction before risk accumulates.
Before signing, meet the proposed product and engineering leads—not only sales. Give them a real workflow or architectural constraint and listen to the questions they ask. The best partners do not pretend uncertainty is absent. They make it visible, reduce it methodically, and explain tradeoffs in business language.
Y-CTU helps organizations plan, design, build, integrate, and operate custom software with clear ownership and measurable delivery. Bring us your goals, constraints, and hardest technical questions. We will show how we would investigate them and what evidence you should expect before committing to a larger build.
Editorial image: real photograph by Mizuno K via Pexels; enhanced and branded by Y-CTU.
