10 Questions to Ask Before Hiring a Software Agency

Most founders get burned by a software agency at least once. The warning signs were usually there early. They just didn't know what to look for. These 10 questions are designed to surface those warning signs before you sign anything. Ask them on your first or second call. Pay attention not just to the answers but to how the agency responds to being asked.

1. Can you walk me through your scoping process?

This is the most important question on the list. A good agency will describe a structured process for defining exactly what is being built before any code is written: discovery sessions, a written scope document, architecture decisions, and a fixed cost that comes out of that process. A bad agency will tell you they can get started quickly, that scoping happens as you go, or that they work in an agile way that means scope evolves over time. That last one sounds modern and flexible. In practice it means you don't know what you're getting or what it will cost until it's too late to change course. What you want to hear: a clear, step-by-step description of how they go from your idea to a written plan before building starts.

2. Will I get a fixed price before the project starts?

There are two ways to price a software project: fixed scope, where the cost is agreed upfront based on a defined scope, and time-and-materials, where you pay by the hour for however long it takes. Fixed scope protects you. Time-and-materials protects the agency. That doesn't mean time-and-materials is always wrong, for ongoing work or products with genuinely undefined scope it can make sense, but for a defined MVP or a specific project, you should be able to get a fixed price once the scope is agreed. If an agency won't commit to one, ask why. What you want to hear: yes, once we've completed scoping, you'll have a fixed cost before we write a line of code.

3. Who actually builds my product?

This question makes some agencies uncomfortable, which is exactly why you should ask it. Some agencies win business with senior people and then hand the work to junior developers or outside subcontractors. The pitch was impressive. The team that builds your product is not the team that pitched you. Ask for the names and roles of the people who will work on your project, whether they are employed by the agency or contracted, and if you can meet them before you sign. What you want to hear: here are the engineers on your project, they work for us directly, and you can meet them before we start.

4. Can I see examples of work similar to mine?

Portfolio pieces are a starting point, not a conclusion. What you want is work that's genuinely comparable to what you're building. If you're building a marketplace, ask to see a marketplace they've built. If you're building a SaaS tool, ask for SaaS examples. If you're building something with AI features, ask what AI products they've shipped in production. Generic portfolio pieces don't tell you much. Similar work tells you whether they've solved the same class of problems you're bringing them. What you want to hear: here are two or three projects similar to yours, with a description of what was built and what challenges came up.

5. Can I speak to a past client?

Every agency worth hiring has clients who would recommend them. Ask to speak to one directly, not via a written testimonial on their website. A live conversation with a past client tells you things a reference letter never will: how they handled problems, whether the project came in on time and budget, whether they'd hire them again, and what they'd do differently. An agency that hesitates on this question is telling you something. One that connects you quickly and confidently is telling you something else. What you want to hear: absolutely, let me connect you with a couple of clients from similar projects.

6. How do you handle scope changes during the build?

Scope changes are inevitable. Something you thought would be simple turns out to be complex. A new feature becomes important mid-build. A third-party integration doesn't work the way you expected. How an agency handles these moments determines whether your project stays on budget or spirals. You want a clear, formal process where any change to scope is evaluated, priced, and agreed before work begins on it, not "we'll figure it out as we go." What you want to hear: any change to the agreed scope goes through a change-order process, we assess the impact on timeline and cost, give you a number, and only proceed once you've approved it.

7. Will I own all the code when the project is done?

The answer should be an immediate, unqualified yes. You should own the full source code, in a repository under your control, with no strings attached. Some agencies retain ownership of code or frameworks they've built, licensing them to clients rather than transferring ownership. Some host your product on their own infrastructure in ways that make it difficult to move later. These arrangements benefit the agency, not you. Ask directly, get it in the contract, and if there's any hesitation or qualification in the answer, dig into why before you sign anything. What you want to hear: yes, everything we build is yours, and you'll have full access to the repository and can take it anywhere.

8. How will I see progress during the build?

You don't need to be technical to evaluate whether a product is being built correctly. You just need to be shown working software regularly and given the opportunity to test it. Ask how often you'll see demos of working software, not status updates or progress reports but actual working features you can click through. Ask what happens if you give feedback that requires changes, and how decisions get made when something is unclear. The answer tells you whether you'll be a partner in the build or a spectator waiting for a delivery date. What you want to hear: we build in visible phases, and at the end of each phase you'll see and test working software before we move to the next one.

9. What happens if something breaks after launch?

Software breaks. Features that worked perfectly in testing behave differently under real usage. Edge cases appear that nobody anticipated. How an agency handles the period immediately after launch is one of the clearest signals of whether they care about your product or just their invoice. Ask what support they provide after launch, for how long, and at what cost. Ask what their response time is for critical bugs, and whether they offer ongoing maintenance and what that looks like. What you want to hear: we include a support period after launch to handle any issues that come up, and after that, here's how ongoing maintenance works and what it costs.

10. What would make this project fail, and how do you prevent that?

This is the question most founders don't ask, and the most revealing one on the list. A good agency will give you a specific, honest answer: the real risks in your project, whether that's unclear scope, a tight timeline, a complex integration, or something specific to your product, and exactly how they mitigate each one. A bad agency will tell you that projects don't fail when you work with them, or give you a vague answer about communication and process. That's a sales answer, not an honest one. What you want to hear: here are the two or three things most likely to cause problems on a project like yours, and here's specifically how we handle each of them.

What the answers tell you

You're not just evaluating the content of the answers. You're evaluating how the agency responds to being asked hard questions. An agency that gets defensive, deflects, or oversells on any of these questions is showing you how they'll handle the harder moments in a real project. One that answers directly, acknowledges uncertainty honestly, and pushes back when a question deserves pushback is showing you something different. The right agency for a non-technical founder is one that makes you feel informed rather than managed. That starts on the first call.