Key takeaways
- Define your goals, budget range and constraints before you contact agencies, so you can compare proposals on the same basis.
- Judge agencies by how they think about your problem, not by how polished their pitch deck is.
- Ask to speak with the people who will actually build your product, and ask to see real code and process artifacts.
- Watch for red flags such as instant fixed quotes, no discovery phase, vague QA and unclear ownership of code and accounts.
- Make sure the contract assigns IP to you on payment and gives you access to repositories, cloud accounts and store listings from day one.
Why the agency decision matters more than the tech stack
Choosing an app development agency is usually the largest single decision in a product project. The partner you pick shapes the architecture, the quality of the code you will own for years and how quickly you can respond to what users tell you.
A strong team can recover from a mediocre framework choice. A weak team will struggle with any stack. That is why the vetting process deserves as much attention as the feature list.
Switching agencies mid-project is expensive. The new team needs weeks to understand the codebase, often finds parts that must be rewritten, and has to rebuild trust with your stakeholders. Spending an extra two or three weeks on selection is cheap insurance against that outcome.
Prepare before you start contacting agencies
You will get better proposals, and be able to compare them fairly, if you send every agency the same short brief. It does not need to be a full specification. Two to three pages is enough.
- The business problem and who the users are.
- The three to five workflows the first release must support.
- Platforms you need: iOS, Android, web, admin tools.
- Known integrations, data sources and compliance constraints.
- A budget range and a target launch window, even if approximate.
- Who on your side will make product decisions and how much time they have.
Sharing a budget range feels risky, but it saves everyone time. Agencies can then propose a scope that fits rather than an idealized product you cannot afford. If you are unsure what range is realistic, our article on what an app typically costs to build gives US-market ballparks by complexity.
The vetting checklist
Use this checklist to score each agency on your shortlist. You do not need perfect marks everywhere, but gaps in the first four items are hard to fix later.
| Area | What good looks like | How to verify |
|---|---|---|
| Relevant experience | Has shipped apps with similar complexity, integrations or regulatory needs | Walkthrough of a comparable project, with the agency explaining trade-offs it made |
| Technical depth | Can explain architecture, data flow and platform choices in plain language | Technical call with the proposed lead engineer |
| Process | Defined discovery, sprint cadence, demos and release management | Sample sprint report, backlog or release checklist |
| Quality assurance | Dedicated QA, automated tests, real-device testing | Ask for their test strategy and typical coverage targets |
| Design capability | UX research and prototyping, not only visual polish | Review a prototype and the reasoning behind it |
| Communication | Named contacts, overlapping hours, written status updates | Note response time and clarity during the sales process |
| Security | Secure coding practices, secrets management, access controls | Ask how they handle credentials, code reviews and dependency updates |
| Post-launch support | Clear maintenance options and SLAs | Request a sample support agreement |
Design deserves its own conversation. Agencies that treat UX research and interface design as a core discipline tend to catch usability problems before they are coded, which is far cheaper than fixing them after launch.
Questions to ask every agency
Good questions move the conversation from sales claims to how the team actually works. Listen for specific answers with examples, and for honest descriptions of trade-offs.
About the team
- Who exactly will work on my project, and what share of their time will it get?
- Are developers in-house employees or subcontractors? Where are they located?
- Who is the single point of contact, and who makes technical decisions?
About process and quality
- What happens in the first two weeks of the engagement?
- How often will I see working software, and in what form?
- How do you handle scope changes mid-sprint?
- What is your definition of done for a feature?
- How do you test on real devices and older OS versions?
About technology and ownership
- Why would you recommend native or cross-platform for this product?
- Which third-party services would you use, and what do they cost at our expected scale?
- Will the code live in our repository from the start?
- How would another team take over this codebase if we parted ways?
Ask them to walk you through their delivery method in detail. You can compare their answers with how we describe our own product development process to see which stages a vendor treats lightly.
Evaluating technical capability when you are not technical
Many founders and operations leaders are not engineers, and that is fine. You can still get a reliable read on technical quality without reading code yourself.
- Ask for an architecture walkthrough of a past project. A capable lead can explain why they chose a database, a framework and a hosting setup, and what they would change now.
- Ask how they would approach your riskiest feature. Good answers mention unknowns, a prototype or spike, and fallback options.
- Bring in an independent reviewer. A few hours from a trusted CTO or senior engineer to review a code sample or proposal is money well spent.
- Look at their release discipline. Ask how they version builds, manage signing keys and roll back a bad release.
Pay attention to how the agency handles questions it cannot answer on the spot. Saying it will check and following up in writing is a far better sign than a confident answer that turns out to be wrong.
Running useful reference checks
References are only useful if you ask specific questions. Request contacts from projects similar to yours in size and complexity, and ask to speak with someone who worked with the delivery team day to day rather than only the executive sponsor.
- Did the project finish close to the original budget and timeline? If not, how did the agency communicate the change?
- How did the team handle disagreements about scope or quality?
- Was the code easy for others to work with after handover?
- Would you hire them again for a critical project?
Red flags that should slow you down
- A fixed quote after one short call. Without discovery, the number is a guess, and change orders will fill the gap.
- No questions about your users or business model. An agency that only asks about screens will build screens, not a product.
- Pressure to sign quickly. Discounts that expire in 48 hours are a sales tactic, not a partnership.
- Vague QA. If testing is described as developers checking their own work, expect bugs in production.
- Code or accounts held by the agency. You should own the repository, cloud accounts, domain and store listings.
- Unverifiable claims. Case studies with no detail, testimonials with no names and award badges you cannot trace.
- Rotating team members. Frequent reassignment destroys context and slows delivery.
Choose the right engagement model
How you contract matters as much as who you contract. The three common models suit different situations, and many projects move between them over time.
| Model | Best for | Watch out for |
|---|---|---|
| Fixed price | Small, well-defined scope such as a prototype or a discrete feature | Change orders, padding for risk, less flexibility |
| Time and materials | Products where requirements will evolve with user feedback | Needs active backlog ownership and budget tracking |
| Dedicated team | Long-running products that need steady capacity | Requires strong product leadership on your side |
We outline how each option works in practice on our engagement models page, including how budgets are capped and reported.
Contract and IP considerations
Most disputes between clients and agencies trace back to contracts that were vague about ownership, acceptance or exit. Have a lawyer review the agreement, and make sure it covers the points below.
- IP assignment: all custom code, designs and documentation are assigned to you upon payment, in writing.
- Pre-existing and open-source components: the agency lists any reusable libraries it brings and grants you a perpetual license to use them; open-source licenses are documented.
- Account ownership: source repositories, cloud hosting, app store developer accounts, analytics and domains are registered to your company, with the agency added as a collaborator.
- Confidentiality: an NDA or confidentiality clause that covers your data and business information.
- Data protection: if the app handles health, payment or personal data, the contract addresses security obligations and, where relevant, a BAA or data processing agreement.
- Acceptance criteria: how deliverables are reviewed and what counts as accepted.
- Warranty period: a defined window after launch in which defects are fixed at no extra cost.
- Termination and handover: notice period, final invoice terms and a handover package including documentation and credentials.
Comparing proposals side by side
Put proposals into a single spreadsheet with the same rows: scope included, scope excluded, team composition, rate, timeline, assumptions, QA approach and post-launch support. The cheapest proposal often excludes work the others include.
Also compare how each proposal handles uncertainty. A credible proposal names its biggest risks, such as an unfamiliar integration or an unclear compliance requirement, and explains how the team will reduce them early. A proposal with no risks listed has either not thought about them or chosen not to tell you.
Pay attention to how each agency describes the build phases and deliverables. A detailed plan that resembles a real mobile app development process is a good sign that the team has done this before and has thought about your project specifically.
Think beyond launch
Your agency relationship should not end at the App Store release. Ask how they handle crash monitoring, OS updates, dependency upgrades and small enhancements once the app is live, and what response times they commit to.
A clear post-launch maintenance arrangement protects the investment you made in the build. Agencies that discuss this early tend to write code with long-term upkeep in mind.
Frequently asked questions
How many agencies should I talk to?
Three to five is usually enough. Fewer gives you little basis for comparison, while more turns vetting into a full-time job. Send all of them the same brief so proposals are comparable.
Should I choose a local agency?
Location matters less than time zone overlap, communication quality and accountability. Many US companies work well with distributed teams, provided there are at least a few hours of shared working time each day and a clear point of contact.
Who should own the app store developer accounts?
Your company should. Enroll in the Apple Developer Program and Google Play Console under your own legal entity and invite the agency as team members. This keeps your listings, reviews and signing keys under your control if the relationship changes.
Is a paid discovery phase worth it?
For most projects, yes. A few weeks of discovery produces a prioritized backlog, architecture direction and a much more reliable estimate. It also lets you evaluate the agency on real work before committing to the full build.