A proposal document tells you what an agency wants you to see. The questions you ask during early conversations reveal what the proposal omits. For a business investing in a web application — whether a customer portal, an internal CRM, or a SaaS product — the right questions expose gaps in the agency's process, clarify who controls your assets, and surface risks that polished presentations tend to bury.
The purpose of asking questions is not to conduct a technical interview. Most business owners are not developers, and there is no value in testing an agency on framework trivia. The aim is to understand how the agency approaches the things that actually cause projects to fail: unclear requirements, missing access credentials, poor handover, and undefined ownership.
Good questions share three characteristics. They are specific enough that a vague answer stands out. They relate to a real risk you have encountered or can anticipate. And they force the agency to describe a process rather than make a promise.
What a useful answer should reveal
| Question area | What you are testing |
|---|---|
| Requirements | Whether the agency investigates the business process before committing to a solution. |
| Team | Who will do the work, how continuity is protected and where subcontractors are used. |
| Estimate | Which assumptions drive cost and how uncertainty or change will be managed. |
| Quality | How acceptance criteria, testing evidence and defects will be handled. |
| Ownership and exit | Whether the business can access code, data, accounts, documentation and another supplier if needed. |
Questions About Discovery and Requirements
Ask: "How do you handle discovery, and what does the output look like?"
Listen for whether the agency treats discovery as a separate, defined phase with a concrete deliverable — typically a specification or set of process maps — or whether they fold it into a vague "planning" stage. A useful discovery output will include process flows, user roles, data fields, integration points and acceptance criteria. If the agency says they "just start building and figure it out as they go," that is a meaningful warning sign regardless of their technical skill.
Ask: "What happens if we change our mind about a feature after development has started?"
You are not looking for a yes-or-no answer. You want to hear the agency describe a change-control process: how they assess the impact, communicate the cost or timeline effect, and get your written approval before proceeding. An agency that promises unlimited changes without consequence is either being dishonest or has not thought through how changes affect a live system.
Questions About Ownership and Access
Ask: "Who will own the source code, and where will it be stored?"
The answer should be straightforward: your business owns the code, stored in a repository your team can access. If the agency talks about licensing the code to you, or insists on keeping the repository on their own infrastructure with no transfer mechanism, that needs to be resolved in the contract before you proceed.
Ask: "What credentials, keys and access will we receive on completion?"
A web application typically depends on server access, database credentials, domain registrar access, third-party API keys, SSL certificates and deployment pipelines. Ask for a list of every asset the agency will create or manage, and confirm that handover includes full access to each one. An agency that cannot articulate this list is unlikely to have a reliable handover process.
Questions About Security and Data
Ask: "How do you handle security during development and after launch?"
Listen for specific practices: dependency updates, secure authentication patterns, input validation, environment separation between development and production. Be wary of an agency that treats security as a one-time audit rather than an ongoing part of the development process. For systems handling personal data, ask how they ensure the application can support your data-protection obligations, while recognising that final legal responsibility rests with your business and should be reviewed with a specialist.
Ask: "Where will our data be stored, and who can access it?"
The agency should be able to name the cloud provider or hosting environment and explain the access controls. If they cannot, or if they suggest storing production data on a developer's local machine during testing, that is a clear problem.
Questions About the Team and Communication
Ask: "Who will actually be working on our project, and will those people stay for the duration?"
Agencies sometimes pitch with senior staff and then assign the work to junior developers. Ask for the names and roles of the people who will be involved, and whether those assignments are stable. High staff turnover mid-project is a common cause of delays and knowledge loss.
Ask: "How do you communicate progress, and how often?"
You are looking for a structured approach — regular updates, a shared task board, or scheduled reviews — rather than a promise that "we'll keep you in the loop." Ask what happens when the project hits a problem: who contacts you, how quickly, and with what level of detail.
Questions About Integrations and Technical Decisions
Ask: "How do you approach integrations with our existing systems?"
For a CRM connecting to an accounting package, or a portal pulling data from an existing database, the agency should explain how they assess the available APIs, handle authentication, manage data mapping and test the integration. If they say "we'll just use an API" without discussing error handling, rate limits or data format differences, they may be underestimating the work.
Ask: "What technology choices do you recommend for this project, and why?"
You are not evaluating the technology itself. You are checking whether the agency can justify their choice in terms of your requirements — scalability, available developer talent, long-term support — rather than defaulting to whatever they are most comfortable with.
Questions About Support and Handover
Ask: "What does the handover process look like, and what documentation is included?"
Handover should cover more than a login and a brief walkthrough. Expect a deployment guide, an overview of the system architecture, details of any background jobs or scheduled tasks, and guidance on common operational tasks. If the agency says "the code is self-documenting," ask how a new developer unfamiliar with the project would get started.
Ask: "What support do you offer after launch, and what is not included?"
Clarify the difference between bug fixes, security patches, infrastructure monitoring and new feature development. Ask whether support is time-bounded, retainer-based, or ad hoc, and what the response-time expectations are. Understand what happens if you choose not to continue with their support — whether the application remains fully operable and accessible without them.
Questions that produce misleading reassurance
The most frequent mistake is asking only about cost and timeline while treating every other question as optional. Price matters, but a low quote from an agency that cannot answer the questions above will typically cost more in the long run through rework, delayed launches, or a painful vendor exit.
Another mistake is accepting vague answers because the subject feels technical. If an agency says "we follow industry best practices" in response to a question about security, ask them to name two or three specific practices. If they say "we use modern technology," ask which technology and why it suits your project. Vague language often masks vague processes.
A third mistake is treating the questions as a one-time checklist. Return to these topics during the project. If the agency described a change-control process during the sales conversation, verify that it is actually being followed when a change arises.
Why questions need supporting evidence
Questions are a filtering tool, not a guarantee. An agency can give the right answers and still deliver poorly. Contracts, acceptance criteria and ongoing oversight matter as much as the initial conversation. The questions help you narrow the field to agencies that operate professionally; the contract and project management determine whether that professionalism is sustained.
References are useful but limited. A reference from a satisfied client proves the agency can deliver under specific circumstances that may not match yours. Ask the reference about the process, not just the outcome: were requirements clear, did the agency communicate well, and was the handover smooth?
How to assess the answers
Look for consistency between what different people at the agency tell you. If the sales lead describes a thorough discovery process but the technical lead says they prefer to "start coding quickly," that mismatch will show up in the project.
Notice whether the agency asks you questions in return. An agency that probes into your business processes, user roles, data flows and existing systems is more likely to build something that fits than one that simply takes a brief and starts estimating.
Pay attention to what the agency declines or pushes back on. A supplier that flags a risk you had not considered — for example, pointing out that a proposed integration depends on an API with known reliability issues — is often more valuable than one that agrees to everything.
Finally, check whether the agency's answers hold up when you ask the same question in a different way later in the conversation. Consistency under rephrasing is a reasonable indicator that the described process actually exists rather than being improvised on the spot.
Turn answers into evidence
- Ask the same core questions of every shortlisted agency.
- Request examples, documents or demonstrations where an answer is important.
- Record qualifications such as “normally”, “subject to” or “provided that”.
- Treat a refusal to clarify ownership, access or exclusions as a commercial risk.
- Compare the final written proposal with what was said in meetings.