Search “San Diego app development” and page one gives you a row of firms that look more or less interchangeable, most of them claiming the city in the headline or the address block. None of those pages helps with the decision that comes first, which is what kind of software you’re actually commissioning. The word “app” is doing two different jobs in that search box: it means something you download from a store and carry around on a phone, and it also means a web application that people open in a browser and call an app out of habit, like a customer portal, an internal tool, or a product you sell as a subscription. Those are different builds carrying different risks, and which one you’re doing ought to decide who ends up on your shortlist.

We’re Ecliptic Ideas, a Ruby on Rails consultancy in Coronado, founded in San Diego in 2015, and both halves of this search reach us. Someone will call about an “app” and then describe something that never needs to touch an app store, and someone else scoping a web portal will describe a workflow that plainly wants a phone in a user’s hand. Either way it’s worth an afternoon to settle which one you’re building, because the alternative is working it out after you’ve already hired a shop that builds the other kind.

A mobile app is software installed on a phone or tablet, distributed through Apple’s and Google’s stores, and updated on their review schedules. It can reach the camera, the GPS, the notification system, and the fingerprint reader, it can keep working when the signal drops, and it usually has to exist twice, once for each platform. The store relationship is part of the product you’re buying: you need developer accounts, you submit builds for review, and the platform rules can change between one release and the next.

A web application runs in a browser and nobody installs anything. You deploy it whenever you decide to, since there’s no reviewer standing in the way and no second platform to keep in sync. The work concentrates somewhere else: accounts and permissions, reporting for the people running the business, integrations with the systems you already pay for, and a data model that has to hold up while records pile up for years. When a company says it needs “an app” for quoting, scheduling, claims, inventory, or giving clients a place to log in, this is almost always what they mean.

The two do overlap, often inside the same project, because a phone app needs a server and an API behind it, and the staff running the business usually need a web screen of their own. We broke that structure down in our guide to hiring a mobile team here in San Diego, so we won’t repeat it here. What the distinction still settles is where the hard part of your project sits, and that’s what should be driving who you interview.

Search flattens all of this even though the industry itself doesn’t. Two of the firms on page one for this exact phrase sell mobile, web, and custom software as separate service lines on their own sites, and then compete for the unqualified “app development” query with a single page covering everything, so the results you’re reading collapse a distinction those firms make internally.

The top result is Trango Tech’s San Diego page, which gives a Fifth Avenue address downtown, while its own footer navigation offers “Our Locations” across a long list of American cities, which is the shape of a national lead-generation network running one page per metro. The page does list both mobile and web development, down to naming Rails and Node, but every one of its featured case studies is a mobile product, so a mobile pitch is what actually arrives whatever the URL promises.

iQlance’s version puts “San Diego’s Top App Developers” in the headline, and then the footer lists offices in Dallas, New York, and Austin with no San Diego address anywhere on the page, while the featured work sits in Dallas and Canada without a San Diego client named. Like Trango Tech, iQlance splits mobile, web, and custom software into distinct service tracks elsewhere on its site, which is worth noticing: the firms competing hardest for this keyword agree that it covers more than phones.

The third result is the clearest example. App Makers LA’s San Diego page lists a local address on Newport Ave, while the site’s footer names Los Angeles as headquarters and the company describes itself, in its own words, as a Los Angeles app and web development company, and no San Diego clients appear on it. We ran into the same arrangement pointed the opposite way when we went through software development results in Los Angeles, where a firm headquartered down here was renting the LA name. Whichever direction it runs, you can spot it the same way: read the footer, then look for a city name in the case studies.

None of that tells you how well any of these firms build software, and a team spread across several cities can do perfectly good work. It does mean the ordering you’re looking at mostly reflects who invested in location pages, so the part about which firm fits your project is still yours to do. If you want the longer version of how to vet a mobile shortlist, question by question, it’s in the mobile hiring guide.

Four questions usually settle it, and you can answer all of them without a developer in the room.

1. Where is the person when they use it? If they’re standing up, moving around, in a truck or a warehouse or a job site, holding the device in one hand, you’re describing a mobile app. If they’re sitting at a desk with a keyboard and a large screen, you’re describing a web application, and any phone version will end up as a companion to the desk experience.
2. Does the core job depend on something only a phone has, like the camera, location, offline use, push notifications, or a barcode scan in the aisle? If your feature list works perfectly well in a browser tab, then a phone app is a distribution choice you can make later on.
3. Does it have to be in an app store? A consumer product people go looking for by name benefits from being there, and you should plan for review cycles and two platforms. Software for your own staff, or for customers who reach you through a login you email them, gets very little out of the stores while paying the same maintenance cost.
4. Who else needs to see the data? If the answer includes a manager who wants a dashboard, an operations person who has to correct a record someone entered wrong, or a monthly report somebody assembles by hand today, you’re specifying a web application whether or not a phone app sits on top of it.

If your answers land on both sides, that’s a normal result, and what it mostly tells you is the build order. The server, the API, and the data model come first, because the phone app is a client of them, and a mobile team that treats the backend as an afterthought tends to hand you something that looks right in a demo and struggles once real data and real users show up.

If you came out on the mobile side, two of our posts pick up right there. Hiring a mobile app team in San Diego covers how to read the local results, what a mobile project actually consists of beyond the screens, and the questions to put to a firm before you sign anything. Mobile app developers in San Diego is the one to read if you haven’t settled the arrangement yet, meaning a freelancer, an in-house hire, or an outside team that carries the product across releases.

If you came out on the web application side, start with our custom software work in San Diego, which covers what we build for companies here across web applications, integrations, and the systems that tie them together. Then read what counts as a custom web application for how scope and cost tend to behave on that kind of build, including the parts people are surprised by.

Before you compare another company, write one paragraph describing who uses the thing you want built, where they are when they use it, and what has to happen to your existing systems for it to be useful. That paragraph answers the four questions above on its own, and it’s also the fastest brief you can hand any developer, ours or anyone else’s.

If it points at a phone, the mobile hiring guide will get your shortlist started. If it points at a browser, a login, and the data behind it, that’s the work we do most. Either way, you’re welcome to book an intro call and walk us through the paragraph.