Most companies that get burned by outsourcing ask the wrong questions at the start. They focus on price and portfolio — and miss the signals that actually predict whether a partnership will work. Here's what to look for instead.
The agency model is broken by design
Traditional software agencies are structured to maximize utilization — not outcomes. Engineers rotate between projects. Account managers sit between you and the work. Seniority is mixed and rarely disclosed. You're paying for a service, not a team.
When things go wrong — and they do — you find yourself in email threads with people who weren't in the original kickoff call, trying to explain requirements to engineers who have context on six other projects.
The alternative isn't working with a freelancer either. Solo contractors create key-person dependency, no redundancy, and no accountability structure.
What actually works is a dedicated team model: a small, stable squad of senior engineers assigned exclusively to your project — with a tech lead who owns the architecture, and a direct line to the founders.
Five questions to ask every potential partner
1. Who will actually write the code?
This is the most important question. Ask for CVs, GitHub profiles, or past project references for the specific engineers you'll work with — not the team in general. If they can't give you this, the people they're proposing don't exist yet or change frequently.
Require seniority definitions. "Senior" should mean 5+ years of production experience in your relevant stack — not 5 years of total employment.
2. Who is your point of contact when something breaks?
In a well-run engagement, your contact is the person with authority to make decisions. In a traditional agency, your contact is a project manager who has to escalate everything. The difference matters enormously under pressure.
Ask explicitly: if there's a production incident at 11pm on a Friday, who do I call? How long until I get a response? The answer reveals the actual structure behind the pitch deck.
3. What does the onboarding process look like?
A partner who can start contributing within two weeks has a real process. A partner who needs 8–12 weeks to "ramp up" is billing you for learning that should have happened before you signed.
Ask for a timeline: day one, week one, end of week two. If they can't give you specifics, the onboarding is improvised.
4. Who owns the code at the end?
The answer should be: you do, completely, from day one. This includes all repositories, documentation, CI/CD pipelines, and infrastructure configurations. Any partner who hedges on this is creating lock-in.
5. How do you handle disagreements?
This sounds soft but it's not. A good partner will have a clear answer: they push back in writing when they disagree with a technical decision, they escalate to founders if a client is asking for something that will damage the product, and they hold weekly architecture reviews to catch problems before they compound.
A bad partner will tell you they "always align with client vision." That's a red flag — it means no one is protecting you from bad decisions.
Red flags to walk away from
- Vague pricing structures with lots of variables — a serious partner can give you a realistic range after a 30-minute call
- A portfolio that doesn't match your domain — building a FinTech compliance platform is not the same as building an e-commerce site
- No clear tech lead structure — if everyone is an "engineer," no one is accountable for architecture
- Reluctance to sign an NDA — standard practice, immediate red flag if refused
- Long lock-in contracts upfront — a partner confident in their work doesn't need to trap you
- Promises they can't back up — "we've never missed a deadline" is not a guarantee, it's a warning sign
What great actually looks like
When a software development partnership is working, it feels almost invisible. Engineers ask the right questions before they start building. Updates arrive without you having to chase them. Architecture reviews surface problems before they become production incidents. Code reviews happen fast. Deployments are boring.
You spend your time on the decisions that matter — product direction, user feedback, business priorities — instead of managing an external team.
That's the bar. It's achievable. But it requires being deliberate about who you choose to build with.