What to look for in a custom software development partner
Most companies learn what to look for in a software partner by choosing the wrong one first.
The wrong partner shows up in a few predictable ways: a codebase that nobody can explain, a product that works in demos but breaks under real users, a handoff with no documentation, an estimate that grew 3x by delivery. Any of these.
Here's the evaluation framework I'd use if I were a CTO or founder hiring an engineering firm.
Start with evidence, not claims
Every software company claims to be "experienced," "agile," "detail-oriented," and "committed to quality." These words mean nothing without evidence.
The evidence that matters:
**Production references.** Not testimonials on their website — direct conversations with past clients. Ask specifically: "Did you have production incidents? How did they handle them?" and "Would you hire them again for something more complex?"
**Live products you can use.** If the firm has built software that's running in production, you can evaluate their work directly. Use it. Break it. See if it handles edge cases.
**Code samples or open-source work.** Looking at how a team writes code is the fastest signal of their standards. Do they write tests? Is the code readable? Are there obvious shortcuts?
**Specific failure stories.** The best engineers can tell you about a project that went wrong and what they learned from it. A firm that claims perfect delivery history on every project either doesn't do complex work or isn't honest.
The specification test
Before any pricing conversation, ask the firm to help you write a specification for a small, well-defined feature.
This tells you: - Whether they understand the problem domain - Whether they ask the right clarifying questions - Whether they think about edge cases unprompted - Whether their written communication is precise
A firm that writes vague specs will build vague software. A firm that helps you sharpen requirements before coding is worth the premium.
Architecture and technical depth
The two things most likely to kill a software project in year 2 are:
1. No tests — changes become risky, bugs multiply, velocity slows 2. Bad data modeling — the schema that made sense in week 1 collapses under real complexity
Ask the firm: "How do you approach testing?" If the answer is "we write unit tests at the end," that's a yellow flag. If the answer is "testing is part of our definition of done, with coverage thresholds enforced in CI," that's what you want.
Ask about their database design philosophy. Listen for: separation of concerns, migration strategies, read/write patterns. A developer who can't explain their data model decisions probably hasn't thought about them carefully.
Team structure and continuity
Find out who will actually work on your project. This matters more than it sounds.
Questions to ask: - Who is the lead engineer? Can I meet them before signing? - What's your policy on rotating engineers on/off projects? - If the lead engineer leaves, what happens to my project? - Do you have dedicated QA, or do engineers test their own work?
Smaller firms often give you more consistent team composition — the same people who write the spec are the ones who deploy. Larger firms have more depth but higher rotation risk.
Pricing model transparency
Be wary of the firm that gives you a fixed-price quote after a 30-minute call for anything complex. Complexity is almost always underestimated. The firms that know this charge for discovery before committing to a full-project price.
Reasonable pricing approaches: - **Time & materials** with weekly tracking — works when requirements are likely to evolve - **Fixed-scope, fixed-price** with well-defined specifications — works when the problem is clearly understood - **Phased engagement** — discovery phase, then build phase with updated scoping
Not reasonable: - A fixed-price quote for a complex product with undefined scope - A quote given within 24 hours of an initial conversation for anything non-trivial
The communication test
Run a trial sprint before committing to a full engagement. Pay for 1–2 weeks of work on a defined, small deliverable. Evaluate: - How often do they communicate without being asked? - When they hit a blocker, how quickly do they flag it? - Is their written communication clear and professional? - Do they show work-in-progress, or only deliver at the end?
The communication pattern in week 1 is exactly what you'll get in month 6.
Red flags to walk away from
- Commits to unrealistic timelines without pushback
- Can't explain their QA or testing process
- Doesn't ask questions about your users or business model
- Has no examples of production software they maintain
- Doesn't discuss what happens after launch
- Won't give direct client references
Green flags worth paying for
- Pushes back on requirements that don't make sense
- Raises architecture concerns before you notice them
- Documents decisions in writing without being asked
- Has engineers who have been at the firm for 2+ years
- Proactively tells you about risks before they become problems
---
*This framework reflects how we at Heaplex approach engagements — and how we'd want to be evaluated. If you're doing due diligence on software partners and want to ask us the hard questions, we're comfortable with that. Email [email protected].*