Ask us these too. We are an app development agency, so most guides to vetting agencies are written about people like us, and the useful ones all say the same thing: ask questions whose answers you can check later. So here are the questions we think a careful founder should ask before signing with anyone, with the answer we give when we're asked, and what a weak answer tends to sound like.
Take the list into your calls. Write the answers down word for word. Compare them a week later, when the warm feeling of a good first meeting has worn off.
"Who will actually build this, and will they still be on it in month three?"
Our answer: a core team of two to five people, drawn from a studio of ten, and the same people carry the product from design through build to launch. The people who run your discovery are the ones who would lead the build. You'll know them by name and role: who designs the screens, who writes the app, who writes the backend, who tests.
That is a choice with a cost. A small team can't throw twelve people at a deadline, and we'd rather tell you that before you sign than after.
A weak answer is a team photo, or "our team of experts". Ask follow-ups: are these employees or subcontractors, how many other projects is each person on, and who do I talk to every week who can make a technical decision? If the senior person in the sales call won't be on the project, you want to know now.
"How did you get to this price?"
Our answer: we don't give a firm price for a real product after one call, because it would be a guess dressed as a number. The price comes from a written scope. For most builds that scope comes out of a two-week Discovery Sprint, which costs ₹1,50,000 ($1,600), the same wherever you are, and is credited to the build if it starts within 60 days of the walkthrough. It ends with six documents: the scope, user flows including the unhappy paths, a clickable prototype of the core screens, the architecture, a risk list, and a fixed quote in milestones. On your side it's about three short calls.
Sometimes a sprint ends in "not yet": a risk nobody can retire yet, running costs that would outgrow revenue, or a first release too large to fund. You keep the scope, flows, prototype and architecture either way. We think an agency that can't say "not yet" is selling builds, not advice.
The weak answer is a precise figure the day after a 30-minute call. Ask what assumptions it rests on and what it excludes. If they can't list them, the price was pulled from a similar project, and the differences will turn up as change requests.
"Fixed price or hourly?"
Our answer: every build is a fixed price for a written scope, paid in milestones. Hourly billing is only for small extra work on a maintenance plan, at ₹3,000 ($32) an hour. For a whole build, hourly gives the team no reason to finish and you no way to know the total.
That's our view, not a law. Some teams run time-and-materials well, especially when nobody can write the scope down yet. Our comparison of fixed price and time and materials is fair to both. What matters is that the agency can explain why its model suits your project, not just that it's the one they use.
Also ask what currency you'll be invoiced in. Clients in India are quoted and invoiced in rupees, everyone else in US dollars, at the same price. And ask which third-party bills are not in the quote: store developer accounts, hosting, maps, SMS, email and AI services all charge separately. Our running costs page lists the ones we've measured.
"What happens when I change my mind?"
You will. Everyone does once real screens are on a real phone, and that's healthy.
Our answer: a change after sign-off is priced before any work on it starts, so the number on the quote stays the number you pay for the agreed scope. You see the cost and the effect on the timeline, and you approve it or you don't. The hard part is telling a fix (it doesn't do what the scope said) from a change (the scope never said it). That line is drawn by the acceptance criteria written into each milestone, which settles most arguments before they start.
The weak answer is "we're flexible". Flexible with no rule turns into an argument about money in month four. Ask who can approve a change request on each side, and what it does to the delivery date.
"When can I hold the app?"
Our answer: early, and on your own phone. Android test builds go through Google Play's internal testing, iPhone builds through TestFlight, as features land. Each milestone ends in something you can install and use, not a status document. Our process page shows the order.
This one is easy to check, so check it. Ask an agency to show you how a past client got test builds. If the first thing you can install arrives near the end, every misunderstanding gets found at the most expensive moment.
"How do you test, specifically?"
Everyone says they test. Ask for numbers.
Ours, from Pakka, a delivery platform with customer and driver apps: before launch we exercised 260 of its 270 API routes with real requests and real roles, not only the routes the screens happen to call, because an untested route is usually the one that leaks data. The pre-Play QA pass found 28 defects, all fixed before release. Our QA and testing page lays out the full approach.
A weak answer is "we follow best practices" or "we have a QA team". A better one names what's automated (money, permissions, data), what's tested by hand on real Android phones and iPhones, and the checklist that runs before every release. Ask about security in the same breath: where do API keys live, how are roles enforced on the server for every request, and which checklist runs before launch? Ours is the pre-launch security checklist. If your users are in India, ask what the app does about the DPDP Act: consent, account deletion, where data sits.
"Tell me about your last store rejection."
This is our favourite question, because a team that has shipped apps has a story and a team that hasn't goes quiet.
Ours: on 23 October 2026 Google Play rejected Pakka's driver app. Nothing in the app was broken. Our own limit on one-time-password attempts locked the reviewer out before they could get in. We changed the limit, resubmitted, and the app is live. It's a slightly embarrassing story, which is why it's a useful one: it shows that store review tests things your own testing doesn't think of.
Follow-ups: who prepares the store listing, the screenshots and the privacy answers? Who holds the developer accounts and signing keys? (You should.) Do they know the rules that catch new accounts out, such as a new personal Google Play account having to run a closed test with at least 12 testers for 14 days in a row, or Apple wanting a D-U-N-S number from an organisation? Our App Store and Google Play launch page and the Google Play launch checklist cover the rest.
"What exactly do I get at the end?"
The question founders forget until the relationship ends.
Our answer is easiest to show with a real one. When we handed Trainr, a fitness marketplace we built for a Dubai company, to its incoming developer on 13 August 2026, the handover included the accounts, the signing material, deploy and rollback runbooks, environment templates for all four codebases, a full export of the media bucket, and a written record of every system's state, the open items and whose court each one sat in. The Trainr case study has the detail, and the agency handover checklist is the general list.
A handover also has to survive small things. When Trainr's error monitoring moved to their own organisation, we pulled the JavaScript bundle out of the built app and searched it: the new address appeared once, the old one nowhere. That's the level of "done" to ask about.
The weak answer is "you'll get the code". Code without the accounts, keys and runbooks is a box of parts. Get the list into the contract, and have your own lawyer read the contract. Ours sits alongside our data processing terms if we'll touch your users' data.
"What happens after launch, and at 2 a.m.?"
Our answer has limits in it, which is the point. Maintenance plans run ₹20,000, ₹45,000 or ₹95,000 a month ($210, $470 or $1,000), with a three-month minimum and then 30 days' notice. Response runs from next working day on the smallest plan to critical issues within four business hours on the largest. Cover is Indian working hours. We don't offer round-the-clock on-call, and a founder who needs that should hear it from us before signing, not during an outage.
We're in Bengaluru. For clients in the UAE our day covers most of theirs; for the UK, their morning is our afternoon. The UAE and UK pages show the overlap. In our experience overlap matters less than habits: written weekly updates, decisions recorded where both sides can see them, and one named person on each side who can say yes or no.
Ask any agency to show you a real weekly update from another project, client details removed. It tells you more than any promise about communication.
"How do I check what you've told me?"
Look at the work, and look at how honestly it's labelled. Every case study on our work page says its real stage: live, built, launching. Some of our own products are built and not yet launched, and they say so. Store wording should be exact too. Four Android apps we built are live on Google Play; Pakka's two iPhone apps are in App Store review, so we say "in App Store review", not "on the App Store".
Then ask for a conversation with a past client about how changes and problems were handled, not how the app looks. If an agency's portfolio is all screenshots and no products, ask why.
Answers that should end the call
Some answers we'd treat as a no, from anyone, including us:
- a firm price for a large product after one conversation;
- a lead who won't be on the project, or no names at all;
- the agency keeping your store accounts or signing keys with no plan to hand them over;
- "we'll figure that out in development" about payments, integrations or moving your data;
- nothing to install until the end;
- a discount that expires on Friday.
If you're still deciding what kind of team you need at all, the comparisons of freelancers, agencies and studios and of in-house teams and outsourcing to India are the place to start, and the choosing a development partner hub collects the rest.
The agency that answers most specifically, including about what it won't do, is usually the easiest one to work with when something goes wrong. And something always goes wrong. You're choosing who you want in the room when it does.