Who will actually do the work
The people on the sales call are rarely the people who write your code. That is normal. What matters is whether you can meet the engineers before you sign, and whether they stay on your project once it starts.
Ask these first:
1. Who will write the code, and can I talk to them?
You want names and a short call with the lead engineer. Be careful if the answer is 'we will assign a team after kickoff'.
2. Who is my day-to-day technical contact?
One person who understands both your business and the code. If every technical question goes through an account manager, expect slow answers.
3. What happens if someone leaves mid-project?
People change jobs. A good team has written documentation, code review and more than one person who knows each part of the system.
How work gets planned, shown and changed
Process questions reveal how the next six months will feel:
4. How often will I see working software?
Weekly or every two weeks, on a link you can click, not in slides. If the first demo is planned for week eight, you will find out about problems in week eight.
5. How do you handle a change in scope?
Changes are normal. You want a clear, written way to price and schedule them, not a surprise invoice and not 'we will absorb it' (which usually means something else gets quietly dropped).
6. What does done mean to you?
Good answers mention tested, reviewed, deployed to a staging environment and accepted by you. 'The developer finished it' is not done.
7. What questions do you have for us?
Turn the interview around. A team that asks hard questions about your users, your data and your deadlines on the first call is already thinking about your product. One that only talks about itself is not.
Code, accounts and handover
This is where founders get hurt most often, and it is the easiest part to get right if you ask before you sign.
Get these answers in writing:
8. Who owns the code and the intellectual property?
You should, fully, on payment. Read the contract. Some agreements keep 'reusable components' with the agency, which can turn out to be most of your product.
9. Whose accounts will everything run on?
The code repository, cloud hosting, domain and app store listings should be in your company's name from day one, with the agency invited as users.
10. If we part ways, what does handover include?
Documentation, a setup guide a new engineer can follow, and a walkthrough call. A team that is confident in its work is happy to plan its own exit.
Evidence beats claims
Finally, check the work rather than the website:
11. Can you show me something similar you have built?
Ask to see working software and to hear what went wrong on that project. Every real project has a story about something that broke. A team that has none is either new or not being straight with you.
12. Can I speak to someone you have worked with?
A past client or a former colleague who has seen the team work. Ask them one question: would you hire this team again for something that matters?
A newer studio may not have a long client list yet. That is not a reason to rule it out. It is a reason to look harder at the people: their past work, their code and how they think through your problem in a paid discovery week before you commit to a full build.
“The cheapest proposal is rarely the cheapest project. Choose the team whose answers you understand.”