7 Questions to Ask Before Hiring an App Development Agency
· 6 min read · Mona Technologies
Most guides to hiring an app development agency read like procurement checklists — get three quotes, check references, sign an NDA. That advice doesn't tell you anything about whether the agency can actually ship a product that works, stays secure, and doesn't fall apart the moment you need a second developer to touch it. The questions below are the ones that actually separate a shop that builds apps from one that builds problems you inherit later.
Who owns the code, the accounts, and the keys when the contract ends?
Before any design work starts, get in writing that you own the source code, the App Store Connect and Google Play Console accounts (or at minimum have admin access to them), the domain, the analytics, and any push-notification or payment credentials. Some agencies build under their own developer accounts by default because it's faster for them — and then charge a transition fee, or worse, drag their feet, if you ever want to leave. Ask directly: "If I stopped working with you tomorrow, could I hand everything to another team by Friday?" If the answer involves any hesitation, that's your answer.
What happens during App Store and Google Play review, and who handles a rejection?
Apple states that the large majority of app submissions are reviewed within 24 hours, but that's a target, not a guarantee — first submissions, major updates, and apps with new business models (subscriptions, in-app purchases, anything health- or finance-adjacent) commonly take 48-72 hours or longer, especially around September and December when submission volume spikes. A rejection is normal, not a red flag on the agency. What matters is whether resubmission and Apple/Google correspondence is included in the project scope or billed as a separate emergency, and whether the agency has actually shipped apps that involve the review category yours falls into (subscriptions, HealthKit, location tracking, and crypto/payments each have their own extra scrutiny).
- Ask for one example of a past app that got rejected and what the fix was
- Ask who owns the developer account the app is submitted under
- Ask how long post-launch bug fixes are covered before hourly billing kicks in
Will the app meet basic accessibility requirements, or is that an afterthought?
This isn't a nice-to-have anymore. The W3C's WCAG2Mobile guidance extends the same Web Content Accessibility Guidelines used for websites to native and hybrid mobile apps, covering things like not locking functionality to one screen orientation, making gesture-based controls operable with a single pointer, and hitting a 4.5:1 color contrast ratio for normal text. In the US, a 2024 Department of Justice rule now requires state and local government web content and mobile apps to meet WCAG 2.1 AA on a fixed compliance timeline — and private-sector lawsuits citing the same standard have been rising for years. If your app serves any public-facing audience, ask the agency point blank whether accessibility is built in during design or bolted on before launch. "We'll deal with that if it comes up" is a warning sign, not a shrug-worthy answer.
What's the actual tech stack, and why that one for your app specifically?
A good agency can explain, in plain terms, why they'd build your app as a native iOS/Android pair, a single cross-platform codebase (React Native, Flutter), or a web app wrapped for app stores — and what you give up with each choice. Cross-platform tends to mean faster and cheaper to build and easier to maintain with one team, but can mean choppier performance or delayed access to brand-new OS features. Fully native tends to mean the smoothest experience and fastest access to new platform capabilities, at higher cost and slower parallel development across iOS and Android. Be suspicious of an agency that proposes the same stack for every client regardless of the app's actual requirements — that's usually about what they're comfortable building, not what your users need.
Who is actually going to work on your project, day to day?
The sales call is often run by the agency's most experienced people. The build is often run by whoever's available. Ask for the names and seniority of the people who will write the code and manage the project once the contract is signed, not just the case studies of people who worked on other apps years ago. Ask what happens if that developer leaves mid-project — is there documentation and a handoff process, or does the project stall until someone new gets up to speed from scratch.
How do they handle scope creep and change requests once the build starts?
Almost every app changes shape between kickoff and launch — that's normal, not a failure of planning. What matters is the mechanism for it. Ask for the specific process: is there a written change-order system with cost and timeline impact shown before you approve it, or does scope just quietly expand until the final invoice is a surprise? Get this in the contract, not just as a verbal assurance in the sales meeting.
- Fixed-bid contracts should specify exactly what's in and out of scope, in writing
- Time-and-materials contracts should include a not-to-exceed cap or a check-in cadence for budget review
- Either way, ask how many change requests their typical project goes through, and what triggered them
What does post-launch support actually include?
Launch is the beginning of the app's life, not the end of the project. iOS and Android both push OS updates multiple times a year, and an app that isn't touched for 12-18 months often breaks against a new OS version, a deprecated API, or a new App Store policy. Ask exactly what's covered after launch: is it just crash fixes, or does it include OS-compatibility updates, security patches, and minor feature requests? Ask what the hourly or retainer rate is once the initial support window ends, and get that number before you sign, not after you need it.
The short version
The single question that filters out the most risk is the ownership one — code, accounts, and credentials — because everything else (support, accessibility, tech choices, staffing) is negotiable after launch if you actually own what you paid for, and unfixable if you don't.