12 Questions to Ask Before Hiring a Software Development Agency

Most guides to hiring a software agency tell you to check portfolios and read reviews. That is table stakes, and it will not stop you from hiring an agency that ships something that looks right in the demo and falls apart three months later. The questions that actually protect you are the ones that reveal how an agency handles the moments that do not go according to plan, because every project has at least one of those moments.

Here are twelve questions worth asking before you sign anything, and what a good answer to each one actually sounds like.

On scope and pricing

1. Is this fixed price or hourly, and why? Hourly billing puts the financial risk of scope changes, underestimation, and inefficiency entirely on you. Fixed price puts that risk on the agency, which means they have a direct incentive to scope accurately upfront and build efficiently. If an agency defaults to hourly for a well-defined project, ask why. Sometimes there is a legitimate reason (genuinely undefined, exploratory work). Often it just means they have not scoped carefully enough to commit to a number.

2. What happens if I need to change scope mid-project? A good agency has a real answer: a documented process for scope addendums, each with its own price and timeline impact, agreed before the new work starts. A bad answer is vague reassurance with no actual mechanism, which usually means scope changes turn into either silent budget overruns or heated disputes at the end.

3. What exactly is included in "done"? Does the price include deployment to a production environment? A handoff document? A period of post-launch bug fixes? Get this in writing. "Done" meaning "code exists" versus "done" meaning "running in production with you able to operate it independently" are very different deliverables at the same price point if you do not clarify upfront.

On the team and process

4. Who specifically will be working on my project, and what is their background? Agencies sell you on their best case studies, then staff the actual work with whoever is available. Ask for names, not just "our senior team." Ask how long those specific people have been with the agency, and whether they will be the same people from kickoff to launch.

5. Do you write automated tests, and can I see an example? This sounds technical, but the answer tells you a lot about long-term reliability. A codebase with no test coverage works fine at launch and becomes increasingly fragile with every change afterward, because nobody can confirm a fix did not break something else. Ask to see an example test file from a past project, not just a yes.

6. How do you handle a bug found after launch? Get specifics: is there a warranty period, what is covered, what is the response time. This is where you find out if the relationship ends the moment the invoice is paid.

On security

7. Who reviews the code for security issues before launch, and what specifically do they check? A vague "we follow best practices" is not an answer. A real answer names specific checks: authentication and session handling, authorization on every endpoint (not just the obvious ones), input validation, dependency vulnerability scanning, secrets management. If nobody on the team has formal security training or certification, ask how they stay current on this.

8. Are your engineers certified in anything beyond the framework you're building in? This is a pointed question on purpose. Plenty of agencies are excellent at React or Laravel and have never had anyone independently verify their security knowledge. Certifications like CEH (Certified Ethical Hacker) or OWASP-aligned training signal that someone has actually studied how applications get broken into, not just how to build features.

9. What happens to my data during development, and where is it stored? If your project involves any real or test data resembling production, ask how it is handled, whether it is encrypted, and who has access. This matters even more if you are in a regulated industry.

On ownership and independence

10. Who owns the code, in full, and when? The answer should be "you, from day one," in writing, not "you, once the final invoice clears" with vague terms in between. Read the contract's IP assignment clause specifically. This is the single most important line in the agreement and the one people skip fastest.

11. Can I take this codebase to another team if I need to? A good agency should be comfortable with this question, because a well-built, well-documented codebase is inherently portable. Hesitation or defensiveness here is a signal, not necessarily of bad intent, but of a codebase that might be harder to hand off than it should be.

On the relationship itself

12. If we're not the right fit for this project, will you tell me? This is the hardest question to get a genuine answer to, because most agencies will say yes regardless. Pay attention to whether they actually turn down scope that is outside their expertise during the sales conversation, or whether they say yes to everything. An agency willing to say "that's not something we're strong at, here's who might be" during a sales call is telling you something true about how they will handle problems later.

What good answers have in common

Specificity. Every strong answer to these questions names a concrete process, a named person, or a documented mechanism, not a general reassurance. Vagueness at the sales stage, when an agency is trying hardest to win your business, tends to become uncertainty later, when the pressure is on to ship.

Frequently Asked Questions

Q: Is fixed-price always better than hourly for software development? A: For well-defined projects with a clear scope, fixed price generally protects you better, because it aligns the agency's incentives with delivering efficiently on time. For genuinely exploratory or research-heavy work where the scope cannot reasonably be defined upfront, hourly with a not-to-exceed cap can be a reasonable middle ground.

Q: How important is it that an agency's engineers hold security certifications? A: It is one meaningful signal among several, not a guarantee on its own. What matters most is whether security review is a built-in step in their development process, not an afterthought. Certifications like CEH or OWASP training indicate someone has studied attack techniques deliberately, which tends to correlate with more careful default engineering practices.

Q: What is the most commonly overlooked question when hiring a software agency? A: Who owns the code and when. Founders assume this is obvious and skip verifying it in writing, then discover during a dispute or a switch to a new team that the contract language was vaguer than they assumed.

Q: Should I be worried if an agency wants to bill hourly for my project? A: Not automatically, but ask why. A legitimate reason is genuinely exploratory work. If the project has a clear, describable scope and the agency still prefers hourly, it often means they have not invested the time to scope it accurately enough to commit to a fixed number, which is worth knowing before you sign.