Hiring a software development partner is one of the most expensive decisions a non-technical buyer ever makes, and most of the advice about it is written by the vendors themselves. This checklist tries to be the exception: twelve things worth verifying before you sign, useful whoever you end up hiring — including nobody.
None of these items require you to be technical. They require you to ask direct questions and pay attention to how directly they get answered.
-
1.Shipped products you can actually try
Screenshots and case-study PDFs are marketing; a live product is evidence. Ask for something the partner has built that you can sign up for, click through, and break. If they build for clients only, ask for a client build you can at least demo. A team with nothing usable to show is asking you to be the first verification of their work.
-
2.Who actually writes the code
Many firms sell you their senior people and deliver subcontractors. Ask directly: who will be in the repository day to day? Where are they? Are they employees? Will the people in the sales meeting appear in the standups? Subcontracting is not automatically bad, but undisclosed subcontracting tells you how the rest of the relationship will go.
-
3.A real security posture
Ask how they handle secrets, access control, dependency updates, and vulnerability reports — in their own products, not hypothetically. A partner that can't describe its own security practices in concrete terms will not invent good ones for your project.
-
4.Source-code and IP ownership, in writing
You should own the code you pay for, full stop — repository access from day one, not a zip file at the end. Read the IP clause before you sign. Watch for licenses back to the vendor, "reusable components" carve-outs broad enough to swallow the project, and anything that makes leaving expensive.
-
5.A plan for post-launch operations
Software is not finished at launch; it is merely started. Who monitors it? Who gets paged? Who applies security patches and pays the cloud bill? A good partner raises this before you do. If the engagement model ends at handoff, make sure you have a team ready to catch what gets handed off.
-
6.Communication cadence you can live with
Agree upfront on the rhythm: how often you see working software (not slide decks), who your direct contact is, and how quickly questions get answered. The best predictor is the sales process itself — a partner who is slow and vague before you sign will not speed up after.
-
7.References from comparable projects
Ask for references from projects of similar size, stack, and stakes — then actually call them. Two questions matter most: "What went wrong, and how did they handle it?" and "Would you hire them again?" Every project has problems; you are hiring for how they behave when problems arrive.
-
8.How they scope and estimate
Good partners estimate in ranges, state their assumptions, and propose a small first milestone or paid discovery to shrink the unknowns. Be suspicious of precision that arrives before understanding: a to-the-day timeline quoted in the first meeting is a number invented to win the deal.
-
9.Willingness to say no
Somewhere in the process, a good partner should push back — on a feature that adds risk without value, a deadline that guarantees corner-cutting, or a build-it-all-at-once plan that should be staged. A vendor who agrees with everything is not aligned with you; they are avoiding friction until the contract is signed.
-
10.Sensible technology choices, explained
Ask why they recommend the stack they recommend. The right answer connects choices to your team, your hiring market, and boring long-term maintainability. The wrong answer is whatever is newest — resume-driven development is a real cost that lands on you years after the vendor is gone.
-
11.Documentation and handoff quality
Ask to see documentation from a past project: a README that gets a new engineer running locally, deployment runbooks, architecture notes. If another competent team cannot pick the project up, you do not own working software — you own a dependency on one vendor.
-
12.Transparent, predictable pricing
However the engagement is priced — time and materials, fixed bid, retainer — you should be able to predict your invoice. Ask what happens when scope changes and what a change order costs. The red flag is not any particular model; it is a model you cannot explain back to your own finance team.
The pattern behind the twelve points
Every item on this list is a version of the same test: does the partner behave, before the contract, the way you need them to behave after it? Evidence over promises. Specifics over adjectives. Pushback over flattery. A vendor who passes that test with a small first milestone has earned a bigger one; a vendor who fails it in the sales process will not improve once the invoices start.
Take the list into every conversation, and hold every candidate to it equally.
Disclosure
This checklist is published by TetraCore, a software studio in Bowling Green, Ohio that builds custom software and operates six SaaS products of its own. We obviously hope we pass these twelve points — and we would rather you apply them to us and everyone else than hire anyone, including us, without asking. If you want to run the checklist against our services or read about the studio, everything is on this site.