Most software development partnerships fail not because the code is bad, but because the evaluation was bad. The company looked good in the demo, gave a competitive quote, and had a polished website — and none of that told you whether they could actually deliver what you needed at the quality you required.
This is a 12-question checklist I use when I talk to potential clients who have been burned before. Each question is designed to surface one specific risk. Work through it before you sign anything.
Before You Start: What You're Actually Evaluating
You're not evaluating the company's portfolio. You're evaluating whether this specific team can execute your project with the constraints you have — timeline, budget, technology stack, and risk tolerance.
Portfolio work was done by different people in different conditions with different clients. What you need to understand is how this team operates when things go wrong, when scope changes, and when the original estimate turns out to be wrong. That's what these questions probe.
The 12-Question Checklist
01
Can you show me the code for one of your active projects?
Not a demo. Not a screenshot. The actual repository — even a limited read-only view of a recent PR or the project structure. Good teams are comfortable showing code. Teams that can't have something to hide about their technical practices.
Red flag:"We can't share code due to NDAs" — every NDA has exceptions for qualified prospects under a mutual NDA. If they won't show any code at all, their code quality is likely the reason.
02
What does your CI/CD pipeline look like for client projects?
Ask them to walk you through the pipeline: what tests run on every commit, what the merge requirements are, how deployments are triggered, and how rollbacks work. Teams with real delivery discipline can answer this in 90 seconds. Teams without one will describe a loose process that sounds like "we test before deploying."
03
Who will actually be working on my project — and are they available now?
Many development companies sell you with senior profiles and deliver with junior staff. Ask to meet the specific engineers who will be assigned, verify their current availability (not "in two weeks"), and ask what happens to your project if one of them leaves. If they can't answer clearly, the bench is thinner than they're showing you.
Red flag:You're introduced to "the team" for the proposal call and then meet a completely different set of people on the kickoff call. This is the most common bait-and-switch in offshore development.
04
What is your pricing model — and what specifically is not included?
Time-and-materials contracts with no scope ceiling are where offshore projects most often blow up. Ask for a milestone-based structure with fixed deliverables and fixed costs per milestone. Then ask specifically what is not included: bug fixes post-delivery, design iterations, third-party API failures, requirement clarifications. Get every exclusion in writing before you compare quotes.
05
Who owns the IP — and when does ownership transfer?
The correct answer is: you own it, and it transfers with each milestone payment. Any arrangement where IP is held back until final payment, or where the company retains reuse rights in the codebase, is a negotiating liability. Insist on a work-for-hire clause with milestone-triggered IP transfer. If they push back, understand exactly why before agreeing.
06
Can I talk to a current client — not one you selected for me?
Every company has three reference clients they know will say nice things. Ask instead for a recent client from the last six months on a project similar to yours — and ask to choose them from a list rather than having the company pick. The resistance to this request tells you more than any reference call will.
07
What happens when a deadline is missed?
Ask for a specific answer: who notifies you, how far in advance, what the revised plan looks like, and whether there are any financial consequences or remedies. Good partners have a defined escalation process. Weak partners will answer this with vague reassurances about commitment and communication — which tells you they've never thought about what they owe you when things go wrong.
08
What is your security posture for handling client code and data?
Ask specifically: where is code stored, who has access, how are secrets managed, are development machines encrypted, and how are former employees' access removed. For healthcare or fintech projects, ask whether engineers sign data handling agreements. If they can't describe a documented security practice, your IP and data are not being protected properly.
Red flag:"We take security seriously" is not a security posture. If they cannot describe specific controls — access management, secret handling, encryption at rest — the answer is they don't have them.
09
What does your documentation look like at project handoff?
Ask for a sample from a previous project: architecture diagrams, API documentation, deployment runbooks, environment setup instructions. If the documentation is thin or non-existent, you will be dependent on them for every future change. Good partners treat documentation as part of the deliverable because they know the engagement has a defined end.
10
What credentials, certifications, or government registrations does the company hold?
For Indian software companies, the verifiable credentials that matter: DPIIT recognition under Startup India (verifiable on the government portal), AWS or Azure certifications for cloud work (verifiable on the respective provider's portal), GST registration and CIN number (verifiable on the MCA portal). If a company has none of these and operates internationally, you have no way to verify they are who they say they are.
11
How do you handle requirement changes mid-project?
This is where most projects break down. The right answer describes a change control process: requirements changes go through a defined assessment, get priced and scoped, are approved in writing, and are reflected in revised milestone dates and costs. Any partner who says "we're flexible" without describing a process is setting you up for scope creep that either delays the project or blows the budget.
12
What does the first two weeks of engagement actually look like?
Ask for a day-by-day breakdown of what happens between contract signing and the first deliverable. Which documents do they need from you? When does architecture review happen? When does the first code commit land? When is the first standup? Partners who have done this before can describe it precisely. Partners who haven't will give you a vague "we'll do discovery and start building."
How to Use This Checklist
Run every potential partner through all 12 questions before you compare quotes. Price is the last thing you should be evaluating — a cheap partner who can't answer questions 1, 3, and 5 will cost you far more in rework, legal exposure, and lost time than a more expensive partner who has clear answers to everything.
A $40,000 project with a partner who fails questions 5 and 8 is not a $40,000 project. It's a $40,000 down payment on a much larger problem.
Weight the answers by consequence. Security posture (Q8) and IP ownership (Q5) are binary — if the answers are wrong, walk away regardless of everything else. Communication under pressure (Q7) and documentation (Q9) are high-value but negotiable with strong contract language. Price model (Q4) is always negotiable if the rest checks out.
What to Do After the Checklist
If a partner clears all 12 questions, the next step is a paid scoping engagement — not a free proposal. Ask them to scope your first milestone in detail for a fixed fee of $500–$1,500. This tells you more about how they work than any evaluation call, and it ensures the first proposal you receive is based on real analysis rather than a number designed to win the deal.
If they refuse the paid scoping engagement, that is useful information too.
A Note on T-Mat Global
T-Mat Global was built specifically to pass this checklist. We are DPIIT recognized (DIPP248437), AWS Certified, founded by a former T-Mobile USA System Design and Architecture team engineer, and currently delivering three active enterprise projects across three countries. Every engagement is milestone-priced, IP transfers with each milestone, and we operate with documented CI/CD pipelines, security controls, and architecture documentation as part of every delivery.
If you want to run this checklist against us, send it to hr@t-matglobal.com. We will answer every question in writing and give you a proposal within 24 hours.