How to Choose a Software Development Agency (Checklist + 15 Questions) | Corco Labs

Hiring a software development agency can be a superpower—or an expensive way to learn that “we’ll figure it out as we go” is not a strategy.

This is the checklist we’d use if we were hiring an agency tomorrow (including how you should evaluate us). It’s not about catching people out. It’s about surfacing the stuff that actually decides whether a project feels calm and predictable… or chaotic and never-ending: who’s on the team, how work is managed, how quality is handled, and what you walk away with at the end.

Before You Book Calls: Get 5 Things Clear

You don’t need a 40-page PRD. You do need enough clarity that two proposals are actually comparable.

The outcome: What changes in the business if this project succeeds?
Users and use cases: Who is this for, and what are the top 3 workflows?
Constraints: Deadlines, regulatory needs, internal systems, hosting preferences.
Budget range: Even a wide range helps agencies propose the right approach.
Decision process: Who signs off, and how fast can decisions be made?

If you can share these on the first call, you’ll get fewer vague answers and a lot more “here’s what I’d do first and why.”

15 Questions to Ask a Software Development Agency Before You Hire

1) Who will actually do the work?

Ask for names and roles: tech lead, product/design, engineers, QA. Then ask whether those people are assigned now or whether the agency is “staffing later.”

If they can’t tell you who your lead is, you’re not hiring a team—you’re buying a promise.

2) What’s your recommended first milestone—and why?

If the plan starts with “build everything,” push back. A strong agency will suggest a first milestone that reduces risk: discovery, architecture, or a thin end-to-end slice that proves the hard parts.

Listen for: what risk they’re trying to remove first (integrations, data, permissions, performance, compliance).

3) How do you handle changing requirements?

Requirements will change. The question is whether their process makes change manageable (prioritized backlog + clear tradeoffs) or turns every change into a negotiation.

Ask how you’ll make scope decisions week to week, and who owns those calls.

4) How do you estimate work, and how often do estimates get revisited?

Look for estimates that come with assumptions, ranges, and regular re-forecasting. “It’s exactly 12 weeks” without any caveats is usually a red flag, not confidence.

5) How do you communicate progress?

Ask what you’ll get each week. A good cadence is boring (in the best way):

a demo you can watch
a short written update (what shipped, what’s next, what’s blocked)
a list of risks and decisions needed from you

6) What does “done” mean to you?

“Done” should include code review, tests, QA, acceptance criteria, and deployment—not just “merged.”

If documentation and handoff are treated as optional extras, you’ll pay for it later.

7) How do you manage quality (tests, QA, CI/CD)?

Ask what’s standard vs optional. Specifically: automated tests, staging environments, release pipelines, and how bugs get triaged.

Bonus question: what broke in the last project and how did they catch it? Real teams can answer that.

8) How do you handle security and privacy?

If you handle customer data, don’t settle for “we take security seriously.” You want specifics: access controls, secrets management, audit trails, least privilege, and how incidents are handled.

9) How do you approach architecture and technical decisions?

Look for simple defaults, documented decisions, and a plan for scale that matches your real needs (not a “future unicorn” architecture).

10) What’s your process for integrating with our existing systems?

For most companies, the hard part is integration: auth, payments, internal tools, data sources, analytics, permissions.

Ask how they discover integration constraints early, and how they handle unknowns (sandbox accounts, API limits, data quirks).

11) Who owns the IP and the code?

You should leave with 100% ownership of source code, designs, and deliverables—plus access to repos and cloud accounts (as appropriate).

If the contract is vague here, fix it before anything starts.

12) How do you document what you build?

Good documentation reduces long-term cost. Ask what they produce by default: setup steps, architecture overview, runbooks, and “how to ship safely.”

13) What happens after launch?

Ask about support options: bug-fix windows, monitoring, on-call, feature iteration, and how handoff works if your team takes over.

Also ask what “launch” means. Is it a button press, or a staged rollout with monitoring and rollback?

Ask for examples that match your context: B2B vs B2C, regulated industries, data-heavy platforms, internal tools, or AI-enabled products.

If they can only show generic portfolio screenshots, dig deeper.

15) What are the most common reasons projects fail—and how do you prevent them?

The best answers are candid: unclear ownership, slow decisions, scope creep, lack of user feedback, underestimating integrations, or “we never agreed what done means.”

Fixed Price vs Time & Materials vs Retainer (Which Is Right?)

The best engagement model depends on how much you already know (and how much you’re still guessing).

Model	Best for	Watch out for
Fixed price	Clear scope, low change	Change becomes expensive; incentives can drift toward “minimum acceptable”
Time & materials	Evolving products, discovery-driven work	Needs strong prioritization and transparency
Retainer	Ongoing iteration + support	Make sure outcomes and cadence are explicit

Fixed price isn’t evil—it’s just brittle. If you’re early or integrating with unknown systems, a short discovery milestone followed by time & materials usually produces the least drama.

How to Compare Proposals (Beyond Price)

When you receive proposals, compare them on:

Understanding: Did they restate your goals and constraints accurately?
Plan: Is the first milestone designed to reduce risk?
Team: Are roles and seniority clear?
Quality: Are testing, QA, and deployment included?
Transparency: Do you get demos, metrics, and written updates?
Ownership: Do you own IP and have access to repos and infra?

If two bids differ a lot, it’s usually because they’re assuming different scopes for quality, integrations, or discovery—not because one team is magically faster.

Red Flags When Hiring a Software Agency

They won’t name the actual team assigned to your project.
They promise a timeline without asking about integrations or constraints.
They avoid discussing testing, QA, or deployment.
They talk about “velocity” but not about decision-making, ownership, or risk management.
They won’t commit to clear IP ownership and access.

A Simple Hiring Checklist

Use this as a quick sanity check before signing:

You understand the engagement model and how changes are handled.
You know exactly what you’ll see in week 1–2 (deliverables and demos).
You have a documented plan for quality (tests/QA/release).
Security and privacy expectations are written down.
Ownership, access, and handoff are explicitly covered in the contract.

If you want, we can walk through your goals and suggest a concrete first milestone (discovery or an end-to-end slice). Start here.