How do I vet a software vendor, especially a new one?
Ask for evidence of habits, not years in business. Eight checks you can run on any agency, including us, and what a good answer and a warning sign look like.
- Years in business is a weak signal. Habits you can inspect are a strong one.
- The best question is: what did your last audit find, and what is still open?
- Ask to see a handover checklist and a release process before you sign, not after.
- A vendor that labels what is built, tested, deployed and unmeasured is easier to trust than one that says everything works.
Quick answer
Ask for evidence of habits, not years. Check what they test, how they release, what their last audit found and is still open, what a handover looks like, and how they handle change. A new vendor can pass all of this and an old one can fail it. We are new, so we show named work with an honest status label instead of claiming experience.
The short answer
Years in business tell you a company has survived. They don’t tell you how it builds. Habits do, and habits can be inspected before you sign.
Why buyers ask this
You’re about to run part of your business on someone else’s code. The fear isn’t that the vendor is dishonest. It’s that you won’t find the problems until real customers do, and then you’ll be dependent on the people who made them. A new company adds a second worry: no track record.
What good looks like: eight checks
| # | Ask | A good answer | A warning sign |
|---|---|---|---|
| 1 | What did your last audit or review find, and what is still open? | A specific pattern-level answer, and an honest “this one isn’t fixed yet” | “Nothing” |
| 2 | Show me your release process. | Steps, owners, and what gets checked before it reaches users | “We just deploy” |
| 3 | How do you test, and what happens under load? | Named kinds of test, including concurrent use | “QA at the end” |
| 4 | What is out of scope for my first release? | A written list with reasons | “We’ll figure it out as we go” |
| 5 | How do you handle something I ask for that isn’t in scope? | A written change request with cost and date effect | “No problem, we’ll add it” |
| 6 | Show me a handover checklist. | A real one: accounts, repos, environments, secrets, docs, who holds what | “We’ll send everything at the end” |
| 7 | What do you label as built, tested, deployed, measured? | Separate labels, used consistently | One word: “done” |
| 8 | Who owns the code and the data at handover? | A clear written answer | Vague or “standard terms” |
If a vendor can’t answer four or five of these, that tells you more than their portfolio does.
How we answer them, and where we’re still open
We started in December 2025, so we have no long record to point to. What we can show is named work, labelled honestly. None of it has a measured outcome yet.
Check 1, the last audit. On a clinic-queue platform we built, our own audits found problems before any real patient depended on the system. One was a queue update made as several separate writes, so a failure partway could leave it half-done. We moved it into a single transaction. It’s tested and not yet in production, and we say so. Another was a rate limiter that blocked nothing on the platform it was meant to protect. We found it by testing it, then moved the counter to the database. A third is that our release is still four manual steps, and a feature once reached users before its backend function existed. A check for that is on our list, not done. We tell you this because it’s the answer to check 1.
Check 6, the handover. For a marketplace client we produced a full handover checklist for their tech stack. We can describe how it’s structured, though not the client’s details, which sit under an NDA. A good handover covers accounts, repositories, environments, secrets, documentation and who holds what. We’ve written it out as a checklist you can use.
Check 7, labels. On the clinic platform we use five words, not one: built, tested, deployed, in production, measured. As of today, it’s built and tested on a demo clinic, deployed in part, not in production with real clinics, and not measured at all.
Where this doesn’t apply
These checks measure how a vendor works, not how well a specific build will turn out. A vendor can pass all eight and still misjudge your problem, so also run a scope check on your own problem. And a reference or a portfolio isn’t a substitute. If a vendor’s evidence is under NDA, ask for the work described honestly, with an accurate status label, rather than a polished claim.
Questions to ask any vendor, including us
Use the table above. If you only have time for three, ask: what did your last audit find and what’s still open, show me your handover checklist, and what’s out of scope for my first release?
Next: what should go in version 1 and what a tech handover should cover. Part of the guide Buying custom software and hiring a tech vendor.
The audit findings and status labels come from our clinic-platform brief; the handover checklist exists for a marketplace client under an NDA, so no client detail appears. Our start date is December 2025. The eight checks are our method, not an industry standard, and no figure on this page comes from a third party.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
