< blog />
How to choose a SaaS development company: 12 questions
By Vinicius Ambrozio, founder of VTA Tecnologia · Published
By the time you have three proposals on the table, they have converged. Same stack, same phases, similar prices, the same promise of agile something. The documents were written by people whose job is to win the project, not to build it, and they are optimized to remove reasons to say no.
The way through is to ask questions the sales team cannot answer alone. This article gives you twelve, grouped into people, product and contract, with the weak answer and the strong answer to each. Written by the VTA team, who sell SaaS development and would like you to ask us the same questions.
Why do the proposals all look the same?
Agency proposals are built from templates and tuned against the objections of the last hundred prospects. That is not dishonest, it is efficient, but it means the document tells you about the agency's sales process rather than about its engineers. Review platforms like Clutch help you filter out firms with no track record, but a five-star profile says a project ended well, not how it went in week six.
The information you actually need lives with the people who will write the code: how senior they are, how they handle billing edge cases, what they do when a tenant's data leaks into another tenant's export, and who owns the repository when the contract ends. So the questions below are designed to be answered by an engineer, in writing, before you sign.
Questions about the people
1. Will the people on this call write the code? The weak answer is a project manager and a rotating pool. The strong answer names the engineers, says how long they have been with the firm, and puts at least one of them on the next call.
2. Exactly which hours of my working day are you online? Ask for hours, not for the word flexible. A team one to two hours from New York can give you a seven-hour overlap; a team ten hours away gives you a morning handoff. Neither is wrong, but the second one changes how you have to write tickets. We compared the options in our nearshore vs offshore guide.
3. What happens to what an engineer knows when they rotate off? The weak answer is that documentation covers it. The strong answer is a written architecture decision log, a README a stranger can follow, and a rule about overlap between the person leaving and the person arriving.
4. Can I talk to two clients whose products are still running? Not the logo wall. Two people, with email addresses, whose SaaS has been in production for over a year. A firm that has been shipping for a while has these; a firm that hesitates has a reason.
Questions about the product
5. How do you isolate one customer's data from another's? This is the multi-tenant question, and it is the one that separates teams that have built SaaS from teams that have built websites. The strong answer names a model (shared schema with a tenant column, schema per tenant, or database per tenant), explains why it fits your product, and mentions row-level security or an equivalent enforcement at the database. Our guide to multi-tenant architecture explains what to listen for.
6. Walk me through a failed subscription payment. The weak answer is that Stripe handles it. The strong answer describes retries, the emails the customer receives, when access is downgraded, and which webhook events drive each step. If nobody in the room can describe this, they have not shipped a subscription product.
7. Which security practices do you follow, and can I see evidence? Nobody expects a SOC 2 report from a ten-person agency. You can expect a team to name the OWASP Top 10, to keep secrets out of the repository, to separate staging from production the way the twelve-factor conventions describe, and to run dependency updates. Ask to see the last pull request that fixed a security issue.
8. What gets tested, and what happens when a deploy breaks production? The strong answer has automated tests on billing and permissions at minimum, a staging environment that mirrors production, and a rollback that takes minutes. Teams that measure their own delivery tend to know the DORA metrics by name; teams that do not usually describe testing as a phase at the end.
Questions about the contract
9. Is the price fixed against a written scope, or hourly with no ceiling? Both are legitimate. What is not legitimate is a fixed price against a scope that says 'user management' and nothing else. Ask for the scope document before the price, and read it as if you were the one who had to argue about it in week six.
10. Who owns the repository, the cloud accounts and the domain, starting on day one? The strong answer is you, from the first commit, with the vendor as a collaborator. Transferring a repository later is a supported operation on GitHub, but the accounts you did not create, the environment variables you never saw and the DNS you do not control are where handovers go wrong.
11. What does the month after launch look like, and what does it cost? A SaaS is never finished. Ask for the retainer terms now: response time when production breaks, what counts as a bug versus a change, and how dependency updates are handled. A vendor who has no answer plans to disappear at launch.
12. What would you cut from my scope, and why? This is the question that exposes the difference. A sales-led firm says the scope looks great. An engineering-led firm names two things you do not need in the first release and explains what they would build instead. You are hiring for judgment; this is where you get to see it.
The twelve questions, with the answers to listen for
Print this table and fill it in for each vendor. The scoring is deliberately simple: a strong answer scores two, a partial answer one, a weak or missing answer zero.
| Question | Weak answer | Strong answer |
|---|---|---|
| 1. Who writes the code? | A PM and a pool | Named engineers, on the next call |
| 2. Which hours are you online? | We are flexible | Specific hours in my time zone, in writing |
| 3. What happens when someone rotates off? | Documentation covers it | Decision log, README, handover overlap |
| 4. Two clients I can call? | Here is our logo wall | Two names, two emails, products still running |
| 5. How is tenant data isolated? | Each user has an ID | A named model, enforced at the database |
| 6. Walk me through a failed payment | Stripe handles it | Retries, emails, downgrade, the webhooks that drive it |
| 7. Security practices and evidence? | We take security seriously | OWASP, secrets management, a PR that fixed an issue |
| 8. What is tested, what if a deploy breaks? | QA phase at the end | Tests on billing and permissions, staging, fast rollback |
| 9. Fixed or hourly, against what scope? | Fixed, scope to be defined | A scope document specific enough to argue over |
| 10. Who owns repo, cloud, domain? | We transfer at the end | You, from day one, vendor as collaborator |
| 11. What happens after launch? | We can discuss later | Retainer terms, response time, what counts as a bug |
| 12. What would you cut? | Scope looks great | Two things to cut, and what to build instead |
A firm scoring 18 or more out of 24 has told you more about how the project will go than any case study page. A firm scoring under 12 is not necessarily bad, but you will be doing the engineering management yourself, and that should be reflected in the price.
What the answers should look like from us
Bias declared: we are a software house in Brazil and we sell exactly this. Here is how we would answer the questions we can answer publicly. You reply from someone who writes code, the same day. Quotes are fixed against a written scope and come back within 24 hours. The repository and every account are created in your name from the first commit. We have built our own payment gateway, with KYC, payouts, checkout and a webhook API, and we run integrations in production with Stripe, Mercado Pago and three Brazilian processors, which is where our answer to question six comes from.
The rest, names, hours, references and what we would cut from your scope, depends on your product, and you should hear it on a call rather than read it on a page. Our SaaS development page explains what a first release includes; if you are earlier than that, the MVP development page is the better starting point.
The detail on the work itself
Frequently asked questions
How do I choose a SaaS development company?
Ask every shortlisted firm the same twelve questions in writing, split across people, product and contract, and score the answers instead of comparing logos. The questions that separate teams who have shipped SaaS from teams who have built websites are the ones about tenant isolation, failed payments and what they would cut from your scope.
Should I pick the cheapest proposal?
Only if the scope documents are identical, which they never are. Compare what each vendor assumed about user roles, billing and integrations. A cheap proposal that is silent on all three was not written for your product, and the difference shows up later as change requests.
Does a SaaS development company need SOC 2?
Not to build your product. Your product may need it later, when enterprise customers send security questionnaires, and the team should build with that in mind: secrets out of the repository, access logs, encrypted backups and separated environments. Ask for evidence of practice, not certificates.
Freelancer, agency or in-house team for a SaaS?
A freelancer is the cheapest hour and the highest key person risk. An agency costs more per hour and buys continuity and someone to call at 4pm when production breaks. In-house is the most expensive way to start and the cheapest way to run something for years. Most SaaS products are built by an agency or a freelancer and brought in-house once they earn a payroll.
What should the contract say about ownership?
That the repository, cloud accounts, domain and every credential are created in your name from the first day, that the code is your property on payment, and that the vendor keeps no exclusive access to anything. Ownership transferred at the end of the contract is where handovers fail.
How many vendors should I talk to?
Three is enough if all three answer the twelve questions in writing. More than five and you spend the budget on evaluation. Send the same brief to each so the proposals are comparable.
Keep reading
Nearshore vs offshore software development: 2026 comparison →
What each model costs, what the time gap does to your week, and when offshore is the better buy. Overlap hours and rate bands with sources, bias declared.
Outsourcing SaaS development to Brazil: what to expect →
Time zone overlap by US city, how contracts and payments work with a Brazilian vendor, data protection, the honest downsides, and a checklist before you sign.
SaaS development cost in 2026: what US startups actually pay →
Public price bands for building a SaaS product, the recurring costs nobody puts in the quote, and the five decisions that move a build from five figures to six.
Want a number for your own project?
Tell us what you are building and you get a written scope, a fixed price and a delivery date within 24 hours.