Search for a mobile app development firm and the results put a three-person shop and a company with seventeen hundred engineers on the same page, described in almost the same language. Both have iOS and Android service blocks, a process diagram, a wall of client logos, and a contact form. Neither page tells you whether the company behind it is built to run one project carefully or seventy at once, and that difference will shape your project more than its position on any shortlist.

We build mobile apps, so we’re one of the options in those results, and this is our attempt at the page the search should return instead of another set of service blocks. If you haven’t settled on hiring a firm at all yet, our comparison of freelance, in-house, and an outside team covers the decision one step earlier. This piece assumes you’ve made it, and looks at what changes across the range of companies the word “firm” covers.

Most of the first page is ranked lists and directories, so we read through BuildFire’s “11 Best Mobile App Development Companies in the United States” to see what a list like that sorts on. Its stated criteria are years in business, the number of apps a company has delivered, industry specialization, and a cost range, and it tells you outright that location no longer matters now that collaboration happens digitally. BuildFire, which publishes the list, also holds first place on it. We ran into the same arrangement writing about choosing a Rails development company: the ranked list turns out to be a marketing asset belonging to one of the ranked companies.

None of that is meaningless. Years in business tells you a company survived, which is real information in an industry where plenty of shops don’t, and app counts do measure throughput. Industry specialization comes closest to being useful, though it’s self-declared and nobody checks it. Even a cost range wide enough to hold both a pilot and a multi-year program tells you the company works above some floor.

None of those criteria describe how a project the size of yours would run inside that company. They measure the firm, since the firm is the unit a list can rank, and what drops out is everything comparative: independently verified reviews, outcomes you could hold side by side, contract terms, or any signal for whether a company that has shipped a hundred apps and one that claims ten thousand belong in the same conversation at all.

Read a large firm’s own services page and you can see which numbers it believes are persuasive. Appinventiv’s opens with seventeen hundred tech experts, two thousand custom apps delivered, over $950M in funding raised for its clients, work across seventy countries, awards from Deloitte and Entrepreneur, ISO certifications, and logos including KFC and Adidas. Those are real numbers, and they all describe the flow of work through the company as a whole rather than what happened on any single project, which is the unit you’re buying.

Two things change at that scale. The first is parallel capacity: when iOS, Android, the backend, QA, and design are staffed as separate groups, they can move at once, and a program that would cost a small team eighteen months of sequencing can be compressed if the work splits that cleanly. If you have a fixed launch date driving four workstreams, capacity is what you’re paying for, and a company at that size has it in a way a small one doesn’t.

The second is the layer of account and project management between you and the engineers. It has to exist, because coordinating that many people across that many clients is a job in itself, but it also means the person who hears your requirement and the person who writes the code are two different people, and everything you say reaches the keyboard through someone else’s notes. Requirements survive that trip more often than not. What gets lost is the nuance, the reason a tradeoff went one way instead of the other.

What these pages leave unsaid matters too. Appinventiv’s doesn’t state where its developers sit or who writes the code, so if either matters to you, that’s a question for the call rather than something you can read off the page. Its contact form asks which budget band you fall into before it asks what you’re trying to build, so the page sorts you by spend before it hears the problem.

The spectrum has a middle, and it’s the part the listicles blur. Simpalm, founded in 2009 with offices in three US cities, names clients including Medline and the University of Maryland. Named clients work differently as evidence than aggregate counts do, because you can look them up, and sometimes you can find the app and use it yourself. A claim of two thousand delivered apps can’t be checked by anyone outside the company that made it.

At the other end of the range, the same project gets carried by fewer people, and a larger share of them are senior, because a small firm can’t afford a junior bench sitting behind a manager. The person who scoped your work is usually the person who writes it, so when you ask why something was built a certain way, you’re asking whoever decided. That shortens the loop on the small questions that come up every week on a real project, like how a screen should behave when the data goes missing.

A small firm has no number that sounds like a hundred simultaneous projects, so what it offers instead has to be evidence about the work itself. We’re a Ruby on Rails consultancy based in Coronado, California, founded in 2015, and we hold client projects to 80 to 90 percent test coverage. That figure is useful to you because it gets measured continuously, so you can ask to see the report this week, on the code being written for you.

The other question worth putting to every company on your list, at any size, is who writes the code and who reviews it. Our answer is that AI writes the code here today, with senior engineers directing and reviewing every change, and that’s a large part of how a team our size covers the ground it does. Elsewhere you’ll get a different answer, and the thing to listen for is whether a stated policy exists at all and whether review sits with a named senior person or with whoever has time that week.

We’ve sat in both seats on mobile work, holding the whole product on Wine Spies and building the backend and API behind another contractor’s iOS app on Sunscreen. Both stories are on the case study pages and in our guide to hiring a mobile team if you want the detail.

The tradeoff at this end runs the other direction. A small firm has less surge capacity, so if your program does need four workstreams moving in the same eight weeks, a small team will either sequence them or take longer. Ask how many people would be on your project, who covers the work when one of them is out, and what else that team is carrying this quarter.

1. How many workstreams have to run at the same time? Count them, because most projects have fewer than the plan implies. An app, an API, and an admin screen built in sequence by one senior team is a common shape and it works. If iOS, Android, a backend, and a data pipeline all have to land in the same quarter against a date you can’t move, that’s a capacity problem, and capacity is what a large firm sells.

2. Is this a one-time build, or something a team lives with for years? A company organized around throughput hands off at launch by design, and that’s a clean fit for a defined build. If the app has to survive years of Apple and Google platform changes, ask a different question: who will still know this codebase in year three, and will they still be assigned to you.

3. Who at your company manages the vendor? A large firm’s account layer needs a counterpart on your side, someone who runs the relationship, arbitrates priorities, and sits in the status calls. If that job belongs to nobody, or it belongs to a founder who’s already overcommitted, direct access to the people writing the code will cost you less of your own time.

4. What evidence can you verify from outside? Award badges, certifications, country counts, and delivered-app totals are things a buyer has to take on faith. Named clients, a coverage number you can ask to see, a stated policy on who writes and reviews code, and ownership of the repository and App Store account in your name are all things you can check yourself. For the full list of what to ask before you sign, our hiring guide works through it question by question.

Most of the time these four answers agree with each other. A defined build with a hard date and several tracks running at once points to a larger firm, and you should go in planning for the management layer that comes with it, while a product one team has to know deeply and carry for years points the other way.

If the open question is still how design and build get divided between the parties on your project, we compared the two usual arrangements in mobile application design and development. And if you’re starting from nothing, our new products page walks through discovery, architecture, and the path to a first release in customers’ hands.

Otherwise, book an intro call and tell us what you’re building, what date you’re working toward, and how many tracks have to move at once. We’ll tell you which end of this range we’d hire in your position and why.