If you only have time for five questions, ask these: Who owns the code, and when does ownership transfer? What exactly is included in the price, and what is excluded? Who will actually work on my project? When will I first see working software? What happens after launch if something breaks? The full list below covers 27 questions in six groups.
How to use this list. Do not send all 27 questions to every vendor. Send a written brief first, shortlist the teams whose replies show they read it, then use the questions relevant to your project. BBR is a studio and would be on the receiving end of this list; our own answers to most of them are on the how we work page.
Scope and pricing
1. What pricing model do you propose for this project, and why?
Why it matters. Fixed price, time and materials, and monthly team pricing place the risk in different places. The right model depends on how well the scope can be defined.
Good answer. A recommendation tied to your situation: "Your scope can be written down, so fixed price after a short discovery. After launch, a monthly plan." Evasive answer. "Whatever you prefer," or one model for every client regardless of project. The models are compared in our guide to outsourcing an app build.
2. What is included in the quote, line by line?
Why it matters. Quotes for the same brief differ mostly because they cover different things.
Good answer. A list that names design, backend, each front end, admin panel, testing, deployment, store submission and project management, with effort or price against each. Evasive answer. A single total, or a feature list with no mention of testing, deployment or admin tools.
3. What is explicitly excluded?
Why it matters. Exclusions are where surprise invoices come from: content entry, data migration, third-party fees, post-launch fixes, a second language.
Good answer. A short written list offered without hesitation. Evasive answer. "Everything you need is covered."
4. How do you handle changes to the scope?
Why it matters. Every project changes. You need to know the mechanism before you need it.
Good answer. "We describe the change, estimate it, and you approve the cost and schedule impact in writing before we start. Small swaps of equal size are absorbed." Evasive answer. "We're flexible," with no process, or a punitive rate for any change.
5. How are payments scheduled?
Why it matters. Payments tied to demonstrated milestones keep both sides' incentives aligned.
Good answer. A deposit, then installments linked to reviewable deliverables such as an approved prototype or a feature set on staging. Evasive answer. Most of the fee up front, or payments tied only to calendar dates.
6. Which assumptions in your estimate are you least sure about?
Why it matters. Every estimate contains guesses. A team that knows where its guesses are is a team that has estimated before.
Good answer. Specifics: "The third-party API has thin documentation, so we have padded that integration and would test it in week one." Evasive answer. "We are confident in the whole estimate."
Team
7. Who will work on my project, and what have they built?
Why it matters. You are hiring specific people, not a logo. The portfolio may have been built by staff who have since left.
Good answer. Names, roles, relevant past work, and an offer to meet the lead engineer before signing. Evasive answer. "We assign the team after the contract."
8. Is any of the work subcontracted?
Why it matters. Subcontracting is not wrong in itself, but it affects confidentiality, IP assignment and quality control, and you should know about it.
Good answer. A plain yes or no. If yes: which parts, to whom, and confirmation that subcontractors are bound by the same IP and confidentiality terms. Evasive answer. A change of subject.
9. Will the people on the sales call be involved in delivery?
Why it matters. Understanding built up during sales is lost if the project is then handed to strangers.
Good answer. In a small studio, the people scoping are often the people building. In a larger agency, a named delivery lead joins before signing. Evasive answer. You never meet anyone technical until after the contract.
10. What happens if a key person leaves or is unavailable?
Why it matters. This is the continuity question. It matters most with small teams, and it is fair to ask it of them, BBR included.
Good answer. Code review so more than one person knows each area, documentation kept current, everything in your repository so that any outcome leaves you holding the work. Evasive answer. "That won't happen."
11. How many projects does each person work on at once?
Why it matters. An engineer split across four clients delivers slowly and context-switches expensively.
Good answer. An honest allocation: "The lead is on your project about 70% of the time; the designer is full-time in weeks one to three, then on call." Evasive answer. "A dedicated team," with nothing to back it.
Process and communication
12. When will I first see working software, and how often after that?
Why it matters. The most reliable predictor of a project that ends well is seeing it work early and often.
Good answer. A staging link within the first few weeks of the build and a demo at a fixed interval. Evasive answer. "We'll show you when it's ready."
13. Who is my day-to-day contact, and how fast do you reply?
Good answer. One named person, a shared channel, a stated response time within working hours, and scheduled calls at times that suit both time zones. Evasive answer. A generic support address.
14. Which tools will I have access to?
Why it matters. Access is transparency. You should be able to see the task board, the repository and the staging environment without asking.
Good answer. "All of them, from the first week." Evasive answer. "We send weekly reports," and nothing else.
15. How do you decide what gets cut if we are running late?
Good answer. Features are ranked at the start, so there is an agreed order of cuts; you are told as soon as a risk appears, not at the deadline. Evasive answer. "We always deliver on time."
16. Tell me about a project that went badly. What happened and what did you change?
Why it matters. Every team that has shipped software has had a difficult project. Willingness to discuss one is a sign of honesty and of learning.
Good answer. A specific story with their own share of the blame and a process change that followed. Evasive answer. "We haven't had one," or a story where the client was entirely at fault.
Ownership and IP
17. Who owns the source code and designs, and at what point does ownership transfer?
Why it matters. This is the most important contractual question. In many jurisdictions, work created by a contractor does not automatically belong to the client without a written assignment.
Good answer. "You do. The contract assigns all project deliverables to you, on payment of each milestone or on final payment," with the clause shown to you. Evasive answer. "You get a licence to use it," or vagueness about timing. Have your own lawyer read the clause; this guide is not legal advice.
18. Whose accounts hold the repository, hosting, domains and app store listings?
Why it matters. Contractual ownership is of little use if you cannot log in. App store listings in particular are awkward to move between developer accounts.
Good answer. "Yours. We help you create them and you grant us access." Evasive answer. "We host everything for convenience."
19. Do you reuse your own frameworks, templates or libraries in client work?
Why it matters. Reuse is fine and saves you money, but you need a perpetual licence to anything of theirs that your product depends on, and the ability to modify it.
Good answer. A clear list of pre-existing components and the licence terms. Evasive answer. A proprietary platform you must keep paying for in order to keep your product running, disclosed late.
20. Which third-party and open-source components will you use, and under what licences?
Good answer. Mostly permissive licences such as MIT or Apache 2.0, a dependency list in the repository, and awareness that copyleft licences can carry obligations. Evasive answer. "We don't track that."
21. Will you sign an NDA, and how do you treat our data?
Good answer. Yes to a mutual NDA; test data instead of real customer data wherever possible; access limited to the people on the project. Evasive answer. Reluctance, or no thought given to production data on developer laptops.
Quality and security
22. How do you test, and who does it?
Good answer. Automated tests on the critical logic, code review on every change, manual testing on real devices and browsers before each release, and someone other than the author checking the work. Evasive answer. "Our developers test their own code," and nothing further.
23. How do you handle secrets, authentication and personal data?
Why it matters. Basic security practice is cheap at build time and expensive afterwards.
Good answer. Secrets kept out of the repository, established authentication libraries or services rather than home-made ones, encrypted connections, least-privilege access, backups, and familiarity with the privacy rules that apply to your users. Evasive answer. "Security is our top priority," with no specifics. If a vendor claims a certification, ask to see it.
24. Can I see something you have shipped that I can use myself?
Why it matters. A live product in a store or on the web is harder to fake than a slide.
Good answer. Links to live apps or sites with an explanation of what the team did on each. Evasive answer. Screenshots only, with everything attributed to confidentiality.
Launch and after
25. Is there a warranty period for defects after delivery?
Good answer. A defined period during which bugs against the agreed scope are fixed at no charge, with a clear definition of bug versus change. Evasive answer. "We'll see at the time," or every fix billed from day one.
26. What does ongoing support cost, and what does it cover?
Why it matters. Software needs maintenance: operating system updates, dependency patches, store policy changes. Our guide to app maintenance costs explains what to budget.
Good answer. A separately scoped plan with stated hours, response times and what falls outside it. Evasive answer. A mandatory, open-ended retainer tied to the build contract.
27. If we part ways, what do you hand over and how?
Why it matters. The best time to agree on the exit is before you start.
Good answer. Repository, credentials, documentation for setup and deployment, and a handover call with your next team. "There is no lock-in" backed by the account ownership in question 18. Evasive answer. Discomfort with the question.
Reading the answers as a whole
- Specific beats polished. Numbers, names and examples indicate experience. Adjectives indicate a sales script.
- Questions back are a good sign. A team that asks about your users, budget and deadline before quoting is doing its job.
- "It depends" is acceptable if followed by "on these three things."
- Watch the writing. The clarity of their emails now is the clarity of their project updates later.
- A "no" is valuable. A vendor who tells you part of your plan is a bad idea, or that they are the wrong fit, is showing you how they will behave mid-project.
If you are still deciding whether an agency is the right kind of partner at all, read agency vs freelancer first. For product-specific selection criteria, see the guides on choosing an MVP development partner and a mobile app development company. For what BBR builds, start at custom software development.
Short checklist
Before you sign, you should be able to tick every line:
- I have a line-item scope and a written list of exclusions
- The pricing model fits how well defined my scope is
- Payments are tied to milestones I can review
- There is a written change-request process
- I know the names and roles of the people doing the work, and whether anything is subcontracted
- I have met the person who will lead delivery
- I will see working software within the first few weeks and at a fixed rhythm after
- I have access to the repository, task board and staging environment
- The contract assigns code and design ownership to my company, and states when
- Repository, hosting, domains and store accounts are in my company's name
- Pre-existing vendor components and open-source licences are listed
- An NDA is signed and the handling of real user data is agreed
- Testing, code review and basic security practices were described specifically
- I have used at least one product the team shipped
- There is a defined warranty period and a definition of "bug"
- Post-launch support is scoped and priced separately
- The handover on exit is described in the contract
- A lawyer in my jurisdiction has reviewed the agreement