The best way to choose a SaaS development agency is to judge how they will work with you, not only what they have built. Before signing, ask how they run discovery, how scope and changes are handled, who owns the code, how they approach security and testing, how deployment and handover work, and what support looks like after launch. Below are twelve questions that reveal those answers, what a good response sounds like, and the red flags worth walking away from. They apply to any agency, including us.
Key takeaways
- Process predicts outcomes. Discovery, scope and change handling matter as much as talent.
- Ownership must be explicit. Your repository, your accounts, written into the contract.
- Ask about the unglamorous parts. Testing, security, deployment and support separate good agencies from good demos.
- Specific answers beat confident ones. Ask for examples, documents and names.
Before you ask: know what you need
You do not need a full specification, but you should be able to explain the problem, who the users are, what the first version must do, your budget range and your timeline. If you are unsure whether an agency or a freelancer suits you better, our agency vs freelancer comparison covers that decision. For budgeting, see how much a SaaS MVP costs to build.
The 12 questions
1. How do you run discovery before quoting?
Good answer: a structured conversation or short paid discovery that produces written scope, assumptions and open questions. Red flag: a fixed quote after a fifteen-minute call, with nothing in writing about what it includes.
2. What exactly is in scope, and what is not?
Ask for a document listing features, user roles, integrations and platforms, plus explicit exclusions. Misunderstood scope is the most common cause of disputes, and “out of scope” lists prevent most of them.
3. How are changes to scope handled?
Requirements always change. A good agency explains how a change is estimated, approved and scheduled, and how it affects cost and timeline, before it happens. Beware of either extreme: “we will just absorb it” (which usually means quality suffers) or a fee for every small question.
4. What are the milestones, and what do I get at each?
Milestones should produce something you can see and use, such as a working feature on a staging site, rather than “backend 50 percent done”. Ask how payments tie to milestones and what acceptance looks like.
5. Who will actually work on my project?
Ask for the names and roles of the people doing the work, their seniority, and whether any work is subcontracted. Ask who your day-to-day contact is and what happens if someone leaves mid-project.
6. Who owns the code, designs and accounts?
You should own the code and designs once paid for, with the code in a repository you control from the start, and hosting, domain, database and third-party accounts in your name. The contract should say this explicitly and clarify the licensing of any components the agency reuses. A reluctance to give you repository access early is a serious red flag.
7. How do you approach security?
Listen for specifics: how secrets are stored, how access control is designed and tested, how dependencies are kept up to date, and whether they reference frameworks such as the OWASP Top 10 or the OWASP ASVS. “We take security very seriously” with no detail is not an answer.
8. What testing will you do?
Ask which flows get automated tests, whether tests run on every change, and who does manual testing before each release. You are not looking for a coverage percentage; you are looking for confidence that critical flows such as sign-up and payments cannot break silently.
9. How do deployment and environments work?
A mature answer includes separate staging and production environments, configuration kept out of the code (the Twelve-Factor approach), repeatable deployments from the repository, and a way to roll back. Ask who has access to production and how that is controlled.
10. How will we communicate, and how often?
Agree the rhythm up front: weekly demos or updates, a shared channel, a place to see progress. Ask how quickly they respond to questions and how they raise problems. Early bad news is a sign of a healthy relationship.
11. What happens after launch?
Ask what support is included, for how long, and what counts as a bug versus new work. Then ask what ongoing options exist for maintenance, security updates and new features, and how they are priced.
12. Can I see similar work and talk to a past client?
Case studies show outcomes; conversations with past clients show how the agency behaves when things get difficult. Ask what went wrong on a past project and how they handled it. A thoughtful answer is more reassuring than a claim that nothing ever goes wrong.
A simple scorecard
| Area | Green flag | Red flag |
|---|---|---|
| Scope | Written scope with exclusions | Quote with no written scope |
| Changes | Clear change process | “We will figure it out” |
| Ownership | Your repo and accounts from day one | Code handed over “at the end” |
| Security | Specific practices described | Generic reassurance |
| Testing | Automated tests on critical flows | “We test everything manually” |
| Deployment | Staging, repeatable deploys, rollback | Manual uploads to production |
| Communication | Agreed rhythm and named contact | Updates only when you chase |
| After launch | Defined support period and options | Nothing specified |
What to make sure the contract covers
- Scope, exclusions and the change process.
- Milestones, deliverables, acceptance criteria and payment schedule.
- Intellectual property and code ownership, including third-party components.
- Confidentiality and data protection responsibilities.
- Support period after launch and what it includes.
- What happens if either side wants to end the engagement early, including handover.
How we answer these questions
Since we wrote the list, it is fair to say where we stand. Scope and pricing are set out in a written proposal before work starts. You own the source code and designs, delivered in your own repositories and accounts. Our Production Sprint includes 30 days of free post-launch bug support. Our work is documented in case studies such as Seatsy and isthislegal. For ongoing work after launch, our Growth Partner plan starts from $1,500 per month. Hold us to the same questions as everyone else.