How to Vet a Software Development Company Without Being Technical
Use a plain due-diligence process for scope, references, security, delivery, ownership, cost, change, support, and exit before you choose a software partner.
You do not need to read code to pick a software partner. You do need a clear decision, useful evidence, named owners, and terms that protect the business. A polished deck can show care, but it cannot prove that a team will deliver your system. Test the claims with the same process every time.
Define the Decision Before You Meet Vendors
Name the business problem, users, critical tasks, and desired change.
List current systems, data, rules, deadlines, limits, and known risks.
Separate must-have work from ideas that can wait.
Set the budget range, approval route, and people who will decide.
State what evidence would support a pilot, full project, or no purchase.
Do not ask a vendor to invent the goal and then grade its own answer. A short brief helps each team respond to the same need, and it makes price, approach, and risk easier to compare.
Use One Plain Scorecard
Give each bid the same test. Score the fit with your need. Score the proof. Score the team. Score the plan. Score the main risks. Score the full cost. Score the terms and exit path. Add notes for each mark. Do not let a low price hide a weak plan. Do not let a good sales call hide thin proof.
Check the Team and Its Evidence
Ask who will lead, design, build, test, secure, document, and support the work.
Confirm whether named people are employees, contractors, or proposed hires.
Request two relevant references and permission to contact them directly.
Ask what went wrong on a similar project and how the team handled it.
Review a sample plan, decision log, test record, release note, and handover.
- Certifications and partner labels matter at times. Check them with the group that gave them.
A portfolio shows what reached the presentation stage. It may not show who did the work. It may not show what the client gave the team. It may not show how the system runs, or how the deal ended. References should cover scope, change, and how the team talked to the client. They should also cover defects, invoices, handover, and support.
Ask the team to show its work. Ask who made each key choice. Call the client who gave the reference. Check what changed after launch. Write down each gap before the next call.
Keep the same notes for each firm. Share them with the full review team. Mark facts that still need proof. Set a date for the final choice. If no bid is safe, pause and fix the brief.
Review Discovery and Delivery
How will the team learn the real user tasks and current process?
Which assumptions will it test before a large build?
How are decisions, acceptance rules, risks, and changes recorded?
How often will you see working software rather than slides or status reports?
Who can approve a release, pause unsafe work, and accept a milestone?
What happens when an estimate, dependency, or requirement changes?
A useful team can explain tradeoffs in plain language. It should say what it knows, what it assumes, and what it must test. Jargon is not proof of skill. A confident fixed answer is not always safer than a bounded range.
Ask About Security and Data
Map data types, legal duties, access roles, vendors, regions, and retention.
Ask how the team handles identity, secrets, logs, backups, updates, and incidents.
Request its secure-development and dependency process.
Set testing and fix duties for the vendor and your own team.
Require prompt notice for material incidents and a clear response path.
- Match the depth of review to the real harm and business impact of the system.
No checklist makes software secure. The goal is to see if the supplier can repeat a sound process. Look for useful records, clear limits, and a way to fix faults. High-risk work may also need an expert to review law, privacy, security, access needs, or clinical care.
Make Ownership and Exit Clear
Client-controlled source repository, cloud accounts, domains, and key records.
Rights to custom code, designs, content, data, and approved third-party items.
A list of licenses, recurring fees, limits, and vendor dependencies.
Build, test, deployment, backup, restore, and support documentation.
Export formats, deletion duties, transition help, and exit pricing.
A process for returning or removing access when work ends.
Compare the Full Cost
Discovery, design, build, migration, testing, security, and accessibility.
Cloud, software, data, model, message, payment, and other usage charges.
Internal staff time, training, support, content, and process change.
Maintenance, monitoring, updates, incidents, and future vendor change.
Contingency for tested risks, not a hidden percentage with no reason.
Use a Paid Discovery or Thin Pilot
When the choice matters, test one hard part first. Do that before you fund the whole vision. Define the output, time, fee, access, rights, acceptance rules, and stop point. A good discovery may give you a process map, a risk list, and options for the build. It may also give you a prototype, an estimate range, and the next decision. It should not quietly tie you to the same vendor for every later phase.
Red Flags Worth Investigating
A guaranteed deadline or result before the team has seen the real system.
One fixed solution for every buyer or no discussion of simpler options.
No direct access to delivery leaders or relevant client references.
Vague ownership, security, support, change, or exit terms.
A low build price that excludes the services needed to operate the product.
Pressure to sign before risks, assumptions, and acceptance rules are written.
For the first project document, use How to Write a Software Project Brief.
The Short Answer
Vet a software company on evidence, not smooth talk. Define the decision and compare the same scope. Speak to references. Look at delivery and security records. Protect ownership, count the full cost, and test a thin slice. No process makes a project safe. A clear one makes risk and fit easier to see before you commit.
Need a software-partner decision baseline?
TTGC can map the problem, evidence, scope, risks, delivery options, ownership, cost, pilot, and stop rules. We do not guarantee delivery time, savings, adoption, performance, or return.
Sources
- CISA — Software Acquisition Guide: Supplier Response Web Tool. https://www.cisa.gov/news-events/news/cisa-unveils-tool-boost-procurement-software-supply-chain-security
- NIST — Secure Software Development Framework. https://csrc.nist.gov/Projects/ssdf
- NIST — Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework
- W3C — Web Content Accessibility Guidelines. https://www.w3.org/WAI/standards-guidelines/wcag/
