Hiring a software development partner is one of the highest-leverage decisions a business leader can make — and one of the riskiest. Get it right and you accelerate by months. Get it wrong and you inherit a codebase nobody can maintain, a burned budget, and a team that's already moved on to the next client.
The problem isn't a shortage of options. It's that every agency's website says the same thing: "world-class engineers," "agile methodology," "transparent communication." The words have been drained of meaning.
What you need are questions that cut through the pitch deck. Questions that reveal how a partner actually operates when things get complicated — because they always do.
Here are ten we recommend asking before you sign anything.
1. Who exactly will work on my project?
This is the single most important question, and the one most often dodged. Many firms sell you on senior architects during the proposal phase, then staff the project with mid-level or junior developers once the contract is signed.
Ask for names. Ask for LinkedIn profiles. Ask whether those people are full-time employees or subcontractors. Ask what happens if one of them leaves mid-project.
At Amexis, every engineer on your project has been with us for years, not weeks. We don't bench-staff. The people in the room during the sales conversation are the people writing your code.
2. What's the average tenure of your engineering team?
High turnover is a red flag that's easy to miss. If a firm churns through developers every 12–18 months, your project will bear the cost of constant onboarding, lost context, and inconsistent code quality.
Look for teams where engineers stay for three, five, even ten years. That kind of retention doesn't happen by accident — it signals good leadership, interesting work, and a culture that respects craft.
3. How do you handle scope changes?
Every non-trivial project encounters scope changes. The question isn't whether they'll happen — it's how the partner deals with them.
Some firms treat every change request as a new statement of work with its own negotiation cycle. Others say yes to everything and let the timeline silently expand. Neither approach serves you.
What you want is a partner who has a clear, lightweight process: assess the impact, present options, let you decide, and adjust the plan. No drama, no surprise invoices.
4. What does "done" mean to you?
This question exposes more about a company's culture than any case study. For some firms, "done" means the feature works on a developer's laptop. For others, it means deployed, monitored, documented, and performing under load.
Push for specifics. Does "done" include automated tests? Performance benchmarks? Security review? Deployment to production? Handoff documentation? If they can't articulate a definition, they don't have one.
5. Can I talk to a client whose project didn't go perfectly?
Any firm can give you a glowing reference. The revealing references are the ones where something went wrong — a missed deadline, a technical pivot, a budget overrun — and the partner handled it well.
If a firm can't (or won't) connect you with a client who experienced a rough patch, that tells you they either don't have long-term relationships or they're not confident in how they handle adversity.
6. How do you staff projects — dedicated teams or shared resources?
Shared-resource models mean your developers are context-switching between multiple clients. That's fine for small maintenance tasks, but for anything requiring deep focus — a new product build, a complex integration, a migration — you want dedicated attention.
Ask how many projects each developer is assigned to simultaneously. If the answer is more than one, understand exactly how their time is split and what happens when priorities conflict.
7. What's your approach to technical debt?
Every codebase accumulates technical debt. The question is whether your partner treats it as something to manage intentionally or something to ignore until it becomes a crisis.
Good partners will proactively flag technical debt, explain the tradeoffs in business terms, and propose a plan for managing it. They won't gold-plate everything on day one, but they won't leave you with a house of cards either.
8. What happens when we disagree on the technical approach?
This question tests whether you're hiring a partner or a vendor. Vendors do what you tell them. Partners push back when they believe you're making a mistake — respectfully, with evidence, but firmly.
You want a team that will tell you "we think that's a bad idea, and here's why" before you waste three months going down the wrong path. Yes-men are cheap in the short term and catastrophically expensive in the long term.
9. How do you measure success beyond shipping features?
Features shipped is a vanity metric. What matters is whether those features achieve the business outcome they were built for.
Ask how the partner thinks about success metrics. Do they track adoption? Performance? Error rates? Customer satisfaction? Revenue impact? A partner who thinks beyond "tickets closed" is a partner who's invested in your actual results.
10. What will I own when the engagement ends?
This should be unambiguous. You should own everything: source code, documentation, infrastructure-as-code, CI/CD pipelines, design assets, and any tooling built for your project.
Check the contract carefully. Some firms retain IP rights to frameworks or "accelerators" embedded in your product. Others make it difficult to transition away by keeping critical knowledge undocumented.
A good partner builds for your independence, not your dependency.
The Meta-Question: Are They Selling Hours or Outcomes?
Underneath all ten questions is a deeper one: does this partner make money when you succeed, or when you consume more of their time?
The traditional time-and-materials model creates a structural misalignment. The longer your project takes, the more the partner earns. That doesn't make them dishonest — but it does mean the incentives aren't naturally pointing in the same direction as yours.
At Amexis, we've spent twenty years refining an approach that ties our success to yours. We staff projects with engineering experts — not because it looks good on a slide, but because experienced people solve problems faster, write code that lasts, and mentor developing talent effectively.
We're transparent about how we work because we've found that trust is the only foundation that survives a complex project. When clients ask us hard questions, we take it as a sign of a healthy partnership starting to form.
Before You Sign
Choosing a software development partner isn't like buying a product. You're entering a relationship that will shape your technology, your timeline, and possibly your competitive position for years.
Take the time to ask these questions. Pay attention not just to the answers, but to how they're delivered. Confidence without defensiveness. Specifics without jargon. Honesty about limitations.
Those are the signals that matter.
Amexis is an expert-driven software engineering company with 28+ engineers and two decades of experience in healthcare, transportation, and enterprise software. If you'd like to talk about your next project, get in touch.