10 Questions to Ask Before Hiring a Dev Agency

Hiring a dev agency is a high-stakes decision. As Harvard Business Review has noted, technology decisions can make or break companies. You're about to hand someone a significant chunk of money, a lot of trust, and the future of your product. And unlike buying a car or renting an office, you won't know if you made the right choice until weeks or months into the engagement.

The good news: the evaluation process itself is incredibly revealing, if you know what to ask. Most founders default to "show me your portfolio" and "how much does it cost." Those questions are fine, but they're surface-level. The real signal comes from questions that force the agency to show you how they think, how they work, and how they handle the messy reality of building software.

Here are the 10 questions we'd ask if we were hiring an agency. (Yes, including an agency like ours.)

Key takeaways:

• Ask to meet the specific people who will write your code, not just the sales team — agencies often sell with senior staff and deliver with junior ones
• The single best predictor of project success is how often you see working software (every 1-2 weeks is ideal)
• Ask "What would you cut from this project?" — agencies that can prioritize strategically are far more valuable than those who say "it's all important"
• Always request the agency's most recent client reference, not a cherry-picked testimonial from years ago
• Fixed-price contracts with a defined change request process protect you from budget surprises

In this post:

• 1. "Who specifically will work on my project?"
• 2. "Walk me through a project that didn't go well."
• 3. "What will the first two weeks look like?"
• 4. "How do you handle scope changes?"
• 5. "Can I talk to your most recent client?"
• 6. "What technology do you recommend, and why?"
• 7. "What do I own when the project is done?"
• 8. "How often will I see working software?"
• 9. "What happens after launch?"
• 10. "What would you cut from this project?"
• The Cheat Sheet
• FAQ

1. "Who specifically will work on my project?"

Not "how big is your team," but who, specifically, will write the code, create the designs, and manage the project.

This matters because agencies sell with their best people and sometimes deliver with different ones. The senior architect who impressed you in the pitch meeting might be spread across six projects. The person actually doing your work might be a mid-level developer you've never met.

Ask to meet the team before signing. If they can't commit specific people, ask why. And if the team changes after the project starts (it happens), make sure the contract addresses how transitions are handled.

2. "Walk me through a project that didn't go well."

Every agency has a project they'd rather not talk about. A deadline that slipped. A client relationship that soured. A technical decision that backfired.

How they answer this tells you everything about their maturity.

The bad answer: "All our projects go well" (not true), or a vague non-answer about "communication challenges" (evasive).

The good answer: a specific story with an honest assessment of what went wrong, what they learned, and what they changed as a result. Something like: "We took on a project with unclear requirements and didn't push hard enough on scoping. Three months in, the scope had doubled and the timeline was blown. Now we require a paid discovery phase before committing to a fixed-price build."

Agencies that can be vulnerable about their failures are agencies you can trust to be honest when your project hits a rough patch.

3. "What will the first two weeks look like?"

This question reveals how organized the agency is. A well-run shop has a clear onboarding process: kickoff meeting agenda, discovery workshop format, design review cadence, first milestone target.

A disorganized shop will give you something vague: "We'll get started on the designs" or "We'll start building." No specifics, no milestones, no clear picture of what you'll see and when.

The first two weeks set the tone for the entire engagement. If they can't articulate a clear plan for those first 10 business days, the rest of the project isn't going to be more organized.

4. "How do you handle scope changes?"

This is the question that saves you the most money.

Requirements always change. You'll realize a feature needs to work differently. Your users will give you feedback that shifts priorities. The market will move. If you pretend this won't happen, you're setting up for budget arguments and timeline disputes.

What you want to hear: a specific process. Something like "We use a change request form. Any new work is estimated, you approve the estimate, and we adjust the timeline and budget accordingly." Or: "We work in two-week sprints (fixed-length development cycles with defined deliverables), and you can reprioritize features at the start of each sprint without additional cost."

What you don't want to hear: "We're flexible" (undefined flexibility becomes defined disagreements) or "We stick to the original scope" (they'll charge you for every tiny change as an "out of scope" add-on).

5. "Can I talk to your most recent client?"

Not a testimonial from their website. Not a reference from two years ago. Their most recent client.

This is one of the most revealing questions you can ask because it eliminates cherry-picking. Their most recent project is the one that reflects their current team, current process, and current quality. A reference from 2023 might describe a company that no longer exists in the same form.

When you get that person on the phone, ask: "Would you hire them again?" and "What was the most frustrating part of working with them?" Those two questions will tell you more than an hour of portfolio review.

6. "What technology do you recommend, and why?"

The answer matters less than how they answer it.

A weak answer: "We use [technology X] for everything." One-size-fits-all technology choices suggest the team isn't evaluating your specific needs.

Another weak answer: "What do you want us to use?" An agency that can't make a technology recommendation isn't confident in their expertise.

A strong answer: "Based on what you've described, we'd recommend [technology X] because [specific reason tied to your project]. We considered [alternative] but chose against it because [specific trade-off]. Here's how this decision affects your timeline, cost, and long-term maintenance."

Technology opinions reveal depth of experience. The team that can explain trade-offs has been in the trenches. The team that rattles off a tech stack without context is reading from a marketing page.

7. "What do I own when the project is done?"

The only acceptable answer: everything. The code, the design files, the documentation, the deployment configuration: all of it.

This should be explicit in the contract, but ask it out loud during the evaluation. Some agencies license their code, restrict your ability to modify it, or retain rights to frameworks and components they used across client projects.

Your code should be yours. Period. If the engagement ends tomorrow, you should be able to hand the codebase to another developer and keep building. If there's any gray area here, clarify it before signing.

8. "How often will I see working software?"

This is the cadence question, and it's the single best predictor of project success we've seen.

The Standish Group's CHAOS Report found that software projects using agile delivery methods (iterative development with frequent client feedback) succeed at nearly twice the rate of those using traditional waterfall approaches. Seeing working software early and often isn't just nice to have — it's statistically linked to project success.

The projects that go well: the client sees working software every 1-2 weeks. They can click through it, test it, give feedback early. Problems are caught when they're small and cheap to fix.

The projects that go badly: the client doesn't see anything for 6-8 weeks. When they finally do, it's not what they expected. Changes cascade, the timeline slips, and suddenly everyone is frustrated.

If the agency's answer is anything longer than two weeks, ask why. Some projects have legitimate reasons for a longer initial phase (complex architecture, data migration), but you should still be seeing incremental progress (staging environments, design previews, working prototypes) regularly.

9. "What happens after launch?"

Software isn't done when it launches. It's just beginning. Your users will find bugs you didn't. Your analytics will reveal features that need to work differently. The server will need monitoring. Dependencies will need updating.

Ask the agency what post-launch support looks like:

• Is there a warranty period for bug fixes?
• Do they offer ongoing maintenance retainers?
• Will the same team be available, or will you need to re-onboard new developers?
• How are emergency issues (site down, security vulnerability) handled?

An agency that treats launch as the finish line is planning to move on to the next sale. An agency that has a clear post-launch structure is planning to be your partner for the long haul.

10. "What would you cut from this project?"

This is our favorite question, and it catches a lot of agencies off guard.

You've just described your project: all the features, all the requirements, everything you think you need. Now ask: "If you had to cut this in half and still deliver something valuable, what would you keep and what would you cut?"

The answer reveals whether they understand your business problem (not just your feature list) and whether they can think strategically about scope. A good agency will have opinions about what matters most and what can wait. A bad agency will say "it's all important," which is the same as saying they haven't thought about priorities at all.

The ability to cut scope intelligently is one of the most valuable skills in software development, and it's a core tenet of lean product development (a methodology focused on eliminating waste and delivering value with minimal resources). It's the difference between shipping something useful in three months and shipping everything in nine months (or never).

The Cheat Sheet

FAQ

How many agencies should I evaluate before choosing one?

Talk to at least three. Fewer than that and you don't have enough data points to compare. More than five and you'll start suffering from decision fatigue — every agency will blur together. Three solid conversations, with the same questions asked each time, gives you a clear picture of who's the best fit.

Should I always choose the cheapest agency?

Almost never. The cheapest bid usually means either junior developers, offshore teams with communication overhead, or an agency that's underestimating the scope (and will charge you later). Compare value, not price. A $30K project delivered in 4 weeks with clean, maintainable code is better than a $15K project that takes 4 months and needs a rebuild.

What's a reasonable deposit or payment structure?

A common structure is 30-50% upfront, with the remaining balance tied to milestones. Avoid paying 100% upfront — you lose all leverage. Also avoid paying nothing upfront — good agencies have strong demand and won't reserve their team without a deposit. Milestone-based payments aligned to deliverables keep both sides accountable.

How do I know if an agency is too small or too big for my project?

If the agency's smallest typical project is 5x your budget, you'll be a low-priority client. If your project is 5x their largest past project, they're in over their head. Look for agencies where your project falls in the middle of their typical range — that's where you get their best attention and most relevant experience.

Is it a red flag if an agency doesn't have experience in my specific industry?

Not necessarily. What matters more is whether they've built similar types of products (marketplaces, SaaS platforms, mobile apps) regardless of industry. A team that's built 20 SaaS products across different industries will adapt to yours quickly. Industry-specific compliance knowledge (like HIPAA in healthcare) is the exception — that's hard to learn on the job.

Want to put us through the test? Ask us these questions. We'll answer every one of them honestly.