How to choose a software partner

The proposal looked finished. The deck had logos. The price fit the spreadsheet. Three weeks later you still could not name the person who would run the work, and nobody would give you a client you could call.
That is how a bad partner gets hired. The slides are easy. The names are not.
I am not writing a scorecard. I am writing what I would tell a founder the week before they sign. Call someone who already paid them. Get one name for the lead. Ask what they do when the date slips. Ask who owns the code and the cloud accounts when the contract ends. If any of those answers is a maybe, you are not choosing a partner. You are renting a hope.
A track record you can actually call
A logo on a slide is not a reference. A case study with no person attached is not a reference. You want someone who will pick up the phone and talk about the work, including the week it went badly.
Ask for two. One recent. One that finished more than a year ago, so you can hear what happened after the team left. Call them yourself. Do not let the sales lead sit on the line and steer it.
The questions are short. Did they tell you when something was late? Was the lead the same person from the first week to the last? When it ended, could your team deploy without them? Would you hire them again?
If they will not give you a name this week, that is the answer. "Available after you sign" is a no.
A named lead
"The team" is not a lead. A bench that rotates is not a lead. You want one person who is on the account from the first week, who can say what is in and what is out, and who is still there when the date moves.
Ask for the name before you sign. Ask how many other accounts that person is already on. Ask what happens if they leave. A backup name is fine. A surprise substitution in week three means the company you bought is not the company that shows up.
Write the name into the statement of work. If the contract says "personnel may change at our discretion" and nothing else, you do not have a lead. You have a slot.
How they handle bad news
Every real project has a week where the date is wrong, the assumption was wrong, or a dependency did not show up. The partner you want says that in the week it happens. The partner you do not want says it in the week you notice.
Ask them to tell you about a project that slipped. If they cannot remember one, they are not telling you the truth, or they have not shipped enough to have one. Ask who you heard it from. If bad news only travels through a salesperson, the engineer who knows is not allowed to talk to you.
A good answer sounds ordinary. "We told the client on Tuesday that the integration would miss Friday. We cut the extra screen and shipped the path that mattered." A bad answer is a story where nobody was ever late.
Who owns the code and the cloud accounts
The repo is yours. The cloud account is yours. So are the domain, the app store accounts, the secret store, and the path that deploys. If any of those live in their company and "transfer at the end," you do not own the work until they feel like handing it over.
Write it down before kickoff, not in the last week. Your GitHub org, or a repo they push to that you can admin. Your AWS, Azure, or Google Cloud account, with their people as guests you can remove. Secrets in your store. Their admin comes off when the contract ends, that same week, not after a vague handoff.
If the contract says they own the code until the final invoice clears, read that twice. A dispute then becomes a lock on your own product. You can still hire them. Do not let them be the only key.
This is the same question as the night after launch. If you cannot name who can deploy once they leave, you did not buy a product. You rented uptime. That handoff is who owns production after launch.
| What you ask | What good looks like | Not good enough |
|---|---|---|
| Who can I call? | Two clients, with names, and you dial them yourself. | Logos. "References on request" after you sign. |
| Who is the lead? | One name, in the contract, with a backup. | "The team." Assigned later. Changed without asking. |
| How do you tell me bad news? | A real slip, told in the week it happened, by someone doing the work. | A story where nothing was ever late. News via sales only. |
| Who owns the code and the cloud? | Your org, your cloud account, your secret store. Their access comes off. | Their GitHub. Their AWS. "We will transfer it at the end." |
Red flags
You do not need a long list. These are enough to stop.
- No client you can call this week.
- The lead is "to be assigned."
- Bad news shows up as a surprise in a status deck.
- The repo, the cloud account, or the domain sits in their org.
- They will not say what they will not do.
- The only way to keep the product running is to keep paying them for the keys.
A polished deck does not cancel a blank row. If two of these are true, walk. You will not negotiate them away after the kickoff.
If you are already inside the work
Choosing is the week before you sign. Running the work is a different week. If the partner is already on the account and you are trying to keep the build pointed at something real, the older piece on this site is outsourcing software development. It is about how you manage the work once it has started. This one is about whether you should start.
If the build is already late because every small change takes a quarter, that calendar cost is its own subject. Read the real cost of technical debt.
If you want a person in the room while you choose, that conversation is CTO advisory. Thirty minutes is enough to tell whether the references, the lead, and the accounts are real. Or talk to an engineer and we will say if we are the fit, or if we are not.
Same idea, other angles
The week before you sign is the same week. The seat changes.
- Questions to ask a mobile app agency before you sign, on Maxiom Apps. Who builds it, who owns the code and the store accounts, how they test on real devices, and what happens after launch.
- How to compare developer staffing vendors, on Maxiom Dev. Seniority you can verify, time to start, replacement terms, and who you actually talk to.
- Choosing a healthcare software vendor, on Maxiom Labs. A BAA, a real HIPAA track record, who touches patient data, and how they handle the health record.
FAQ: how to choose a software partner
What should I ask before I hire a software partner?
Four things. Who you can call that already paid them. The name of the lead, and the backup. How they tell you when the date slips. Who owns the code and the cloud accounts on day one, not on the last day. If any answer is "we will sort that out," you do not have an answer.
What counts as a track record I can call?
A person, not a logo. Two is enough. One recent, one that finished long enough ago that you can ask what happened after the team left. You place the call. A slide of client logos is not a track record.
Why does the lead have to be a named person?
Because "the team" cannot be late, cannot be fired, and cannot be the one who tells you the truth. A name in the contract is someone you can ask for. A slot that gets filled later is how the proposal you bought becomes a different company.
How should a partner handle bad news?
In the week it is true, from someone doing the work. A slipped date, a wrong assumption, a dependency that did not show. If the only version of the project is the one in the status deck, you are hearing the news late.
Who should own the code and the cloud accounts?
You. Your source control, your AWS or Azure or Google Cloud account, your domain, your secret store. Their people are guests you can remove. "We will transfer it when we are done" means they hold the keys until they decide they are done.
What are the red flags?
No client you can call this week. A lead "to be assigned." Bad news that arrives as a surprise. The repo or the cloud account in their company. A refusal to say what they will not do. A product you cannot run unless you keep paying them for access.
Is this the same as running an outsourced project?
No. This is the week before you sign. Outsourcing software development is how you run the work once a partner is already on it. You can pass the first test and still manage the second one badly. Do not skip either.
What if the work is a mobile app, extra developers, or healthcare?
Same week, different seat. A phone or tablet product is questions to ask a mobile app agency before you sign. People who join your team are how to compare developer staffing vendors. A clinical system is choosing a healthcare software vendor.
When should I walk away?
When two red flags are already true and they want the signature this week. You will not fix a missing reference, a missing name, or a missing account in the kickoff. If you want someone to sit in that conversation with you, that is CTO advisory. If you can already point at the clients, the lead, and the accounts, you can sign, or you can walk, without us.
If you want that conversation, see CTO advisory or talk to an engineer. Thirty minutes is enough to tell whether the answers are real.
I write from the seat of a working engineering company, not a tool vendor. More at antoniochagoury.com.



