Search for custom mobile software development and every page on the first screen of results uses the word, usually in a heading, and not one of them tells you what it excludes. What you get instead is a menu of platform options (native, hybrid, cross-platform), a list of frameworks (Swift, Kotlin, Flutter, React Native), a process diagram, and a cost section that resolves to something like “it depends on various factors.” We read six of those pages back to back while writing this one, and at the end of it you still couldn’t hold two proposals carrying the same word and say whether they describe the same kind of work.

That matters because at least four different things get built and delivered under this phrase, and they drift apart once a project is underway. Some of the difference shows up on day one, in what the app can do with the phone it’s installed on, but most of it stays hidden until you ask for something the people who built it hadn’t planned for.

We ran the general version of this test on the word “bespoke” in what that label actually covers, where platform configuration, low-code assembly, and rented engineering hours all turned out to be wearing it. Mobile has its own set, built on tools that post never names, so this is the mobile fork of the same question.

Each of these is the right purchase for some project. The trouble is that they all arrive wearing the same word, so it’s left to you to work out which one you’re looking at.

This is your existing responsive site, loaded inside a native shell and submitted to the stores. It’s the quickest way to get an icon onto a home screen, and when the experience already works well in a mobile browser it can be a sensible buy.

The limits are the browser’s limits, though. Bubble’s own write-up on turning a website into an app describes wrapped sites as slower and laggier than a real app, with limited access to the camera, location, biometrics, and features that work offline, while a native app is built specifically for iOS or Android and reaches device capabilities like push notifications and the camera directly. There’s also a review risk to understand before you commission one, because Apple can reject an app that turns out to be a webview loading your site with no native features, on the grounds that it lacks minimum functionality. If what you’re being quoted is a shell around a URL, it’s better to find that out before you sign than at review time.

These tools are more capable than their reputation suggests. FlutterFlow, the best known of them, deploys to the App Store, Play Store, and web with a few clicks, lets you export the code with the click of a button and no vendor lock-in, and gives you granular control over widget properties and logic, with custom actions and custom widgets available for whatever the palette doesn’t already cover.

What you’re buying is an app assembled from that tool’s component set. Anything outside the set arrives as a custom action or widget that somebody writes and then maintains alongside the generated parts, which works fine when it’s three of them and gets awkward when it’s thirty. Two questions decide whether that matters for you. The first is how much of your product lives outside the palette, whether that’s an unusual data flow or a third-party SDK that has to be wired in at the native layer. The second is what the export is really for, because exported code only helps you if somebody can pick it up and work in it comfortably, so ask to see a project that was exported and then maintained by hand.

There’s an entire business model here, and its vendors describe it openly. FluxBuilder’s agency page invites agencies to create app designs once and resell them to multiple clients, customizing colors, logos, and UI elements for each account. You get something working quickly, with your branding on it.

The architecture underneath was designed for the general case before anyone involved knew your business existed, and it’s running other people’s apps at the same time as yours. That trade works when your product sits close to what the template assumes, which for most of these means a storefront or a booking flow. It stops working when the thing that makes your business different is exactly the thing the template has no field for, and the answer to your request turns out to be that the feature exists in a different tier, or on a roadmap you have no say in.

Here the data model comes out of how your business actually works, the framework gets chosen for the project in front of it, and the screens are written for your product. It’s the slowest of the four to get to a first release and the most expensive to commission, and for a thin product it’s usually the wrong call.

What that money buys is room to change. There’s no component list to run out of and no shared architecture whose other tenants limit what you can change in yours, so when a requirement shows up that nobody anticipated, the conversation is about how long it’ll take to build, and that stays true as the product gets older.

You can get most of the way to an answer with one question, asked before anything is signed: what happens when we need something your approach doesn’t already have a shape for?

Make it concrete, and pick the version that fits what you’re building. It might be a screen the builder’s component list has nothing for, or a device capability a wrapper can’t reach, like background location or a queue of actions that survives the app being closed and reopened with no signal. If a template is what’s on the table, use a data shape it was never designed to hold, such as a second side of a marketplace on top of something built for a single seller.

Then listen to what the answer is made of. “We’d build it” puts you in from-scratch territory. If you hear “we’d step outside the tool for that piece and hand-write it,” you’re in builder territory with an escape hatch, which is a perfectly workable place to be as long as you know you’re there and know who maintains the hand-written part. And “that’s a different tier,” or “that’s on the roadmap,” means the shape of your software was decided by somebody else before you arrived.

Any of those answers can be fine, depending on what you’re building, so treat them as information about the purchase and keep the conversation going.

Look at what the pages competing for this phrase actually do with it. Salesforce runs the most definitional page on the results list, covering app types, process, frameworks, cost factors, and AI’s role, and it never separates a from-scratch build from a templated one, at one point putting vibe-coding tools alongside real engineering work without marking any difference between them. Chetu goes the other way and presents custom as the only thing that exists, a menu of platforms and frameworks with no acknowledgment that the alternatives are being sold under the same name elsewhere. Coherent Solutions leads with tenure and headcount figures and case-study call-outs before sending pricing off to depend on various factors, and AppIt Ventures names real frameworks and a blended development approach while compressing the entire backend into a line about database and API development.

The two pages that go furthest toward being useful still stop short of it. IT Craft names case studies with real usage numbers, lays out a four-stage process, and even publishes a price range, which is unusual among these pages. EffectiveSoft carries named client testimonials, a six-stage process, and a full stack listing, then declines to put any number on cost and asks you to consult its experts. Neither one mentions no-code builders, webview wrappers, or white-label templates, so even with that much detail on the page you still can’t tell which kind of build a quote from either of them would describe.

A buyer holding four proposals that all say “custom” has no way, from those pages alone, to tell which of the four things above each one is quoting. We don’t read that as bad faith. Pages like these are written to be found by a broad search, and drawing the line would turn away some of the people arriving on it, so the line tends to stay undrawn and you end up drawing it yourself on sales calls, with less information than you’d like.

We build from scratch, in a framework we pick for the project. In practice that’s usually React Native for iOS and Android, sharing logic with the web side so a feature ships everywhere at once, and the rest of the stack is on our custom software page.

If one of the other three looks like the better buy for what you’re building, we’ll say so on the first call. If you’re further along and trying to scope what a mobile project involves, we wrote that up in hiring a mobile app team. There’s also a piece on whether one team should handle design and build together or the two should be split into separate engagements, which is worth reading before design gets locked: two shapes an engagement can take. And when the product doesn’t exist yet at all, how we run a build from zero is the closer read.

Write your version of the question down before you take the first sales call, using a feature you already know you’ll need and that feels slightly unusual for your market. Ask every vendor the same one, in the same words, and note which of the four answers comes back. Putting those answers side by side tells you more about each proposal than their service menus do.

When you’ve got answers you want a second read on, book an intro call and bring them along. We’ll tell you which of the four we think you were quoted.