How to choose an app development company: questions to ask

Most failed app projects don't fail on code. They fail because the founder hired the wrong team for the job: a freelancer for a project that needed a team, an agency that handed the work to someone else, or a cheap bid that ignored half the scope. This guide covers how to tell the options apart, what to ask on the first call, and what has to be in the contract before you pay anything.

I run Loha.dev, a small app studio in Albuquerque, so I have a stake in this. I'll try to be fair anyway, including about when a studio like mine is the wrong choice.

Freelancer, agency, studio, offshore or in-house?

Before comparing companies, decide what kind of team fits your project. The hourly rates below are rough typical ranges for 2026 in the US market and vary widely by region and seniority.

A practical rule: if you don't have a technical cofounder and you're building a first version, you want one accountable team that covers product, design, mobile, backend and release. That's usually a small studio or a strong freelancer with trusted partners. Hiring in-house makes more sense after the product has users and a roadmap that will keep a full-time engineer busy for years.

Before you hire anyone, also ask whether you need custom software at all. Sometimes a no-code tool or an existing SaaS product gets you 80% of the way for a fraction of the cost. I wrote about that decision in custom app vs off-the-shelf software.

Red flags to watch for

• A fixed price after one call. Nobody can price an app responsibly from a 30-minute conversation. A number that fast is either padded or missing scope.
• No apps you can download. Mockups and Dribbble shots aren't shipped software. Ask for App Store and Google Play links.
• They agree with everything. A good team pushes back on features that don't serve the first release. A team that never says no is optimizing for the sale.
• Vague answers about who builds it. If the person selling isn't the person building, find out who is, and where.
• The code lives only in their accounts. Repository, hosting, domain and store listings controlled by the vendor is how founders end up held hostage.
• Large upfront payment for the whole project. A deposit is normal. Paying 100% before work starts removes your leverage.
• No mention of testing, analytics or post-launch support. Launch is the start of the work, not the end.

Green flags that predict a good project

• They ask about your users, your business model and how you'll measure success before they talk about technology.
• They suggest cutting scope and explain why, with a concrete smaller first version.
• They give you a range with assumptions written down, not a single number.
• They demo working builds every week or two, on real devices, not slide decks.
• They set up the repository, Apple and Google accounts under your company from day one.
• They can explain their tech choices in plain language, including the downsides.
• They're clear about what they don't do well and who they'd refer you to.

The questions to ask an app development company

Use these on the first or second call. You don't need to ask all of them; the point is to hear how they answer. Specific, slightly uncomfortable honesty is a good sign. Polished generalities are not.

Portfolio and shipped apps

• Which apps have you shipped that are live in the stores right now? Can I download them?
• What exactly did your team build on each one: design, mobile, backend, all of it?
• Which project is closest to mine, and what went wrong on it?
• Can I talk to a past client? (If they say yes, actually call.)

Download the apps and use them for ten minutes. Check onboarding, loading states, what happens offline, and the store reviews. You'll learn more from that than from any case study page.

Process and communication

• How often will I see working software, and on what devices?
• Who is my day-to-day contact, and is that person technical?
• How do you handle a feature request in the middle of a sprint?
• What do you need from me each week, and how much of my time does this take?

If you want to know what a healthy process looks like phase by phase, see the app development process explained.

Tech choices and ownership

• What stack do you recommend for this app, and what would make you choose differently?
• Native (Swift/Kotlin) or cross-platform (React Native, Flutter)? Why for my case?
• Who owns the code, designs and IP when the project ends? When does ownership transfer?
• Will the repository, cloud hosting, domain and Apple/Google developer accounts be in my company's name?
• If we part ways, how would another developer take over? Is there documentation?

Pricing model: fixed price vs time and materials

• Do you work fixed price, time and materials, or a hybrid?
• What's included in the estimate, and what's explicitly excluded?
• How are change requests priced and approved?
• What are the payment milestones, and what does each one deliver?

Fixed price works when scope is small and stable. It also tends to include a risk buffer, and every change becomes a negotiation. Time and materials is more honest for products that will evolve, but it needs a budget cap and weekly visibility into hours. A common middle ground is a fixed-price discovery phase followed by capped sprints. For realistic numbers, see how much it costs to build an app.

Quality assurance

• Who tests the app, and on which real devices and OS versions?
• Do you write automated tests? For which parts?
• How do you track crashes and errors after release?
• What's your process for App Store and Google Play review rejections?

Post-launch support

• What happens in the first 30 days after launch? Is bug fixing included?
• What does ongoing maintenance cost per month, roughly?
• Who handles OS updates, SDK deprecations and store policy changes?
• What's your response time if the app goes down?

Who actually writes the code

• Who are the developers on my project by name, and how senior are they?
• Are they employees, contractors or a subcontracted firm?
• Will the team stay the same for the whole project?
• Can I meet the lead developer before signing?

How to evaluate and compare proposals

When you have two or three proposals, put them side by side. Price differences of 3x are common, and they usually mean the vendors understood different projects.

1. Check scope first, price second. List the features each proposal includes. Missing items like admin panels, push notifications, payments or analytics explain most low bids.
2. Look for stated assumptions. Good proposals say what they assumed: number of user roles, integrations, platforms, design included or not.
3. Compare the first release, not the dream. The best proposal often says what to leave out of v1.
4. Read the timeline for realism. A full iOS + Android + backend app in four weeks is a warning sign. See how long it takes to build an app for typical ranges.
5. Count who's involved. Does the plan include design, QA and a project lead, or just developers?
6. Ask what post-launch costs. Hosting, third-party services, store fees and maintenance belong in the total cost.

Contract essentials: protect your code, IP and accounts

Your contract should be written so that if the relationship ends tomorrow, you can hand everything to a new team the next day. At minimum, it should cover:

• IP assignment. All code, designs and documentation created for you are assigned to your company, typically on payment of each milestone. "Work for hire" language alone may not be enough; an explicit assignment clause is safer. Have a lawyer review it.
• Source code access. You get access to the Git repository from day one, not a zip file at the end.
• App store accounts in YOUR name. Enroll your own company in the Apple Developer Program ($99/year; organizations need a D-U-N-S number) and Google Play Console ($25 one-time fee). Add the developer as a team member. Transferring an app between accounts later is possible but slow and annoying.
• Infrastructure in your name. Cloud hosting, database, domain, email sending, analytics and API keys should live in accounts you own and pay for, with the developer invited.
• Third-party and open-source components. The vendor should disclose libraries or licensed assets that come with restrictions.
• Confidentiality and non-solicitation that fit your situation, without blocking the developer from building other apps.
• Payment milestones tied to deliverables you can verify, like a TestFlight build or a store submission.
• Warranty and support terms: how long bugs are fixed for free after launch, and the rate after that.
• Termination terms: what you get and what you owe if either side ends the contract early.

This isn't legal advice. Have an attorney review any development agreement before you sign, especially the IP section.

Local or remote developer?

Remote work is normal now, and most projects run fine over video calls and a shared Slack channel. Still, a team in your time zone makes daily decisions faster, and being able to meet in person helps for complex or regulated projects. If you're in New Mexico, we offer app development in Albuquerque with in-person workshops; otherwise, prioritize overlapping working hours over geography.

How we approach this at Loha.dev

Since you'll ask us these questions too, here are our answers. We're a small studio, and I write code on every project. We build custom apps for iOS, Android and the web, mostly with React Native and Expo, TypeScript, Convex for realtime backends, and Cloudflare. Clients own their repository, store accounts and infrastructure from the start. We ship working builds frequently and say early when a feature isn't worth building yet.

We also run our own products, including Star, a setlist and presentation app, so we deal with store reviews, OS updates and user support ourselves. If you're comparing teams for mobile app development, you can get a free app plan and use it to compare other proposals, whether or not you hire us.