Picking a software development partner is less about the pitch deck and more about how a team actually works once the contract is signed. Most businesses only discover whether they chose well three months in, when the first sprint review either builds confidence or reveals silence, shifting scope, and a codebase nobody outside the agency understands. This guide walks through the concrete things to check before you commit budget — not marketing language, but the operational details that predict whether a project ships on time, on budget, and in a state you can maintain long after the agency moves on.
Look past the portfolio and into the process
A polished case study tells you what an agency shipped, not how it got there. Ask specifically about their engineering process: how they scope a project, how estimates are produced, how testing is handled, and how ownership of the codebase is handed off at the end. Vague answers about being 'agile' are a warning sign — you want specifics like sprint length, who attends standups, and what a typical sprint review actually covers.
A strong partner will describe a clear sprint cadence, give you transparent access to the source repository from day one, and maintain a documented architecture decision trail rather than surfacing a demo link at the end of each milestone with no paper trail behind it. If a company can't explain how it tracks decisions or changes over time, you're signing up to inherit undocumented tribal knowledge later.
Communication cadence matters more than communication tools
Every agency will tell you they use Slack, or Linear, or weekly calls. The tool matters less than the cadence and the substance of what's shared. Ask what a typical weekly update looks like — a two-line status message is very different from a working demo plus a list of open risks and decisions that need your input.
Pay attention during the sales process itself: if responses are slow or vague before you've signed a contract, that's usually the best-case version of how communication will go afterward, not the worst case. Teams that are genuinely organized tend to over-communicate early, because it costs them nothing and builds trust.
Ask specifically about post-launch support
A large share of software cost happens after the first release, not before it — bug fixes, performance tuning, and the inevitable feature requests that come once real users start clicking around. Ask what happens the day after launch: is there a defined support window, a response-time SLA, or does the relationship simply end when the invoice is paid?
Agencies that plan for post-launch work will usually have a maintenance retainer or support package already defined, with clear boundaries on what's included (security patches, dependency updates, monitoring) versus what's billed separately (new features). If they haven't thought about this before you ask, they likely haven't budgeted the engineering time for it either.
Verify technical ownership, not just technical skill
Being able to write good code and being able to hand off a maintainable system are different skills. Ask how the team documents environment setup, deployment steps, and architectural decisions — and ask to see an example from a past project (with client details redacted, if needed).
Also confirm who owns what once the engagement ends: source code, domain names, hosting accounts, API keys, and any third-party service subscriptions should be transferable to you, in your name, not locked inside the agency's internal accounts. This is a common source of painful renegotiation later if it isn't set explicitly in the contract.
Red flags worth walking away from
Fixed-price quotes given before any discovery or scoping work almost always mean corners will be cut somewhere to protect margin — usually in testing, documentation, or code quality. Be equally cautious of teams that can't explain their pricing model at all; unclear pricing tends to correlate with unclear scope later.
Also watch for agencies unwilling to let you speak with a past client, or that only offer references they've hand-picked without any way to verify the relationship. A team confident in its delivery record will usually make it easy to check.
Key takeaways
- Evaluate process specifics (sprint cadence, testing, documentation) over polished portfolios.
- Judge communication quality during the sales process — it rarely improves after signing.
- Confirm post-launch support terms and who owns code, domains, and accounts up front.
- Be skeptical of fixed-price quotes given without any discovery phase.