Hiring an outside team to build your product is a big decision, and most of the risk is decided before any code is written. These are the questions we would want answered if we were in your seat.
Who will actually work on our project?
The people on the sales call are not always the people who build the product. Ask to meet the engineers and whoever will manage the project day to day.
Who owns the code, accounts and domains?
The answer should be you, from day one. The repository, hosting and third-party accounts should be in your name, with the team given access. Anything else creates a dependency that is expensive to unwind.
How is the scope written down?
A good team puts the scope in writing with clear milestones, and explains what happens when things change. A vague scope protects nobody, least of all you.
How often will we see working software?
Status reports are easy to write. Working demos are harder to fake. Ask how often you will be able to click through real progress, and expect an answer measured in weeks, not months.
How do you handle changes and delays?
Every project changes. What matters is whether changes are visible, priced and agreed, rather than discovered at the end.
What happens after launch?
Ask about bug fixes, maintenance, documentation and handover. A product that only the original team can maintain is a long-term cost.
Can we talk to someone you have worked with?
Any team can describe its process. Talking to a past client tells you how that process holds up under pressure.
We are a young studio, so we expect to be asked all of these, and we would rather you ask than assume. If you are comparing teams, we are glad to walk you through our answers.