How do you actually vet a software development company?
Ignore the portfolio and the pitch deck: both are marketing artifacts, curated and unverifiable. Vet with twelve specific questions across five areas, code ownership, delivery process, security practice, AI-code policy, and references, and verify every answer against an artifact: a contract clause, a live repository, a CI pipeline run, a reference call.
If you are a non-technical founder starting from zero, read The Non-Technical Founder's Guide to Hiring a Development Partner first, it covers engagement models, budgets, and where to find candidates. This piece assumes you already have a shortlist and goes deeper: the questions that separate an engineering firm from a body shop. One pattern holds throughout: a competent firm answers each question immediately and offers evidence unprompted; a weak one improvises, generalizes, or takes offense.
Questions 1-3: Who owns the code, and what do you get if you walk away?
Ask three things: when does IP assignment happen, per paid invoice, or only at final payment? Whose accounts hold the code, cloud, and domains from day one? And what exactly does handover include? The only acceptable answers: assignment as you pay, your accounts, and a written handover artifact list.
- ▸Question 1, IP timing. The contract should assign ownership of work product as each invoice is paid, not on project completion. Otherwise a mid-project dispute leaves the vendor holding your codebase as leverage. Watch for clauses that carve out broadly defined "reusable components" or "background IP", narrow them to named libraries with a perpetual license to you.
- ▸Question 2, account ownership. Repositories live in your GitHub or GitLab organization with the agency added as collaborators; cloud infrastructure runs in your AWS, Azure, or GCP account with billing you can see; domains and DNS sit in your registrar account. "We'll host it for you" is convenience for them and lock-in for you.
- ▸Question 3, the handover list. Infrastructure as code, environment variables with a secret-rotation step, CI configuration, architecture notes, and an inventory of every third-party service with a named account owner. A firm that cannot produce a past handover checklist has never really handed anything over.
Questions 4-6: How do they build and ship, week to week?
Ask: show me the CI pipeline of a current project; how does code reach production, environments, review, rollback; and what is your testing discipline? The answer you want is a live screen-share of a merge request running tests, linting, and a deployment, not a process described in adjectives.
- ▸Question 4, the pipeline demo. Any serious firm can show a pipeline on a real project, names redacted, within a day. Manual FTP or SSH deploys, or no CI at all, are disqualifying for anything you intend to operate for years.
- ▸Question 5, the release path. Listen for staging or preview environments, mandatory code review, and a rollback method they can name. Follow up with: when did you last roll back, and why? Real teams have a story.
- ▸Question 6, testing. Automated tests written by the same engineers who write the features, running in CI and able to fail the build, not a manual QA pass bolted onto the end of the project.
In the same conversation, ask who exactly will work on your project: names, seniority, and whether the people in the sales call ever touch your code. The senior-sells, junior-builds bait-and-switch remains the single most common way these engagements go wrong.
Questions 7-9: What does their security practice look like inside the repo?
Ask: what happens when a secret is committed to git? How do you handle authentication and dependency updates? And have you taken a client through a penetration test or an enterprise security audit, can you show a redacted report? Firms with a real practice answer with tools and incidents; the rest answer with adjectives.
- ▸Question 7, the committed secret. A good answer names detection (secret scanning, pre-commit hooks) and then rotation, because a pushed credential is burned even if the commit is deleted. "We would remove it from history" alone is the wrong answer.
- ▸Question 8, the boring controls. Managed identity providers instead of hand-rolled authentication; dependency scanning with Dependabot, Renovate, or similar, plus a patch cadence they can actually state; code review that covers security-relevant changes.
- ▸Question 9, scars. A firm that has survived a client's penetration test or vendor audit has artifacts: a redacted findings letter, a remediation log. Retrofitting security after launch costs multiples, the argument is laid out in Secure by Design: Why Bolting On Security Later Always Costs More.
Questions 10-11: What is their policy on AI-generated code?
In 2026, every development company uses AI coding assistants; the differentiator is whether a policy governs them. Ask: which AI tools do you use, and what of my code and data reaches third-party models? And how is AI-written code reviewed differently? Both "we don't use AI" and "no policy needed" are disqualifying answers.
- ▸Question 10, tools and data flow. You want named tools on enterprise tiers with training on your data contractually excluded, a clear statement of whether your proprietary code is sent to external model APIs, and a willingness to put both in the contract.
- ▸Question 11, verification. Human review on every AI-assisted change, tests as the gate, static analysis in CI, and a specific answer for hallucinated dependencies and invented APIs. Public research through 2025 and 2026 has repeatedly found that a large share of unreviewed AI-generated code contains exploitable weaknesses; the operational consequences are covered in The Hidden Risks of Shipping AI-Generated Code to Production.
- ▸One contractual follow-up: who is liable if AI-authored code causes a security or IP problem? Mature firms have seen the clause; immature ones have never thought about it.
Question 12: How do you run reference calls that actually reveal something?
Ask the firm for three references, including one project that went sideways, willingness to provide that one is itself the signal. On the calls, skip "were you happy" and ask: did estimates hold, who fixed production incidents and how fast, what did handover actually include, and what would you not hire them for again?
- ▸Call; do not email. Written testimonials are marketing.
- ▸If the reference client has a technical person, talk to them rather than the CEO.
- ▸Corroborate the team: were the named engineers actually the ones building it?
- ▸Ask what year two looked like, maintenance cost and responsiveness after the invoice pressure ended. That is where cheap builds surface, a pattern documented in The Hidden Costs of Cheap Software Development (and How to Avoid Them).
Which red flags should end the conversation immediately?
Walk away when a firm refuses to show a real pipeline or repository, ties all IP transfer to the final invoice, quotes a fixed price for a complex build with no discovery phase, cannot name the engineers who will do the work, or has no answer on AI-code policy. Each one predicts a specific, expensive failure.
Also treat as terminal:
- ▸Pricing dramatically below every other bid. The difference gets paid later, usually by you, in rework and security debt.
- ▸Insistence on hosting everything in their accounts "to keep things simple."
- ▸References available only as written quotes on their website.
- ▸"We keep contracts light, we work on trust." Trust is what the contract is for.
How do pricing model and geography fit into the decision?
They matter less than the twelve answers, but they shape risk. A firm that passes this vetting on a time-and-materials contract with weekly demos is a safer bet than a mediocre one on a fixed price. The contract trade-offs are covered in Fixed Price vs Time and Materials: Which Contract Saves You Money?.
Whatever the model, insist on the same operational cadence: weekly demos of working software, your accounts, your visibility into the board and the repository. Geography changes hourly rates and overlap hours, not the standard you should hold, a team in Tunis, Tallinn, or Toronto should pass the exact same twelve questions before you sign.
How TuniCyberLabs helps
TuniCyberLabs is an engineering firm with EU governance in Estonia and Cyprus and engineering in Tunisia, and we encourage prospects to run these twelve questions on us. The answers come back as artifacts: repositories in your organization from day one, a live CI pipeline demo, a written AI-tooling policy, and reference calls with named clients. If you are comparing shortlisted vendors, our services page shows how we structure delivery, bring us the hardest project on your list.