Before You Build a Mobile App: What to Decide First (and What It Costs)

In 18 years of building software for clients, I’ve talked roughly half of them out of developing a mobile app. Here’s the truth most agencies won’t tell you: most businesses don’t need an app, they need a fast mobile website. And the businesses that genuinely do need an app usually waste tens of thousands of dollars because they skip the four or five decisions that actually determine whether the thing ships, gets used, and pays for itself.

So before you write a single line of code or sign with a single developer, work through the decisions below in order. Each one closes off an expensive wrong turn. If you only read one section, read the first one, because it’s the question that saves the most money.

Do You Even Need an App?

Start here, because most of the time the answer is no. If your goal is “let customers browse, book, or buy on their phone,” a responsive website or a Progressive Web App (PWA) does that for a fraction of the cost, with no app store approval, no separate iOS and Android builds, and nothing to download. A PWA loads in the browser, can send push notifications on Android, and can be saved to the home screen so it looks like a native app. For a local business, a content site, or a basic store, that’s the right answer about nine times out of ten.

You earn a native app when you need things the browser can’t do well: heavy offline use, tight access to the camera or sensors, GPS that runs in the background, Bluetooth hardware, Apple or Google Pay at the system level, or genuinely high-frequency daily engagement where a home-screen icon changes behavior. A fitness tracker, a delivery app, or a tool people open six times a day clears that bar. A brochure with a “book now” button does not. Be honest about which one you’re building. I’ve reviewed apps tied to health and medication tracking where native truly mattered, and store-locator apps where the company torched a budget rebuilding their own website inside a worse shell.

Native, Cross-Platform, or No-Code?

If you’ve decided you need an app, the next fork decides most of your budget and timeline. You have three realistic paths. Fully native means two separate codebases, Swift for iOS and Kotlin for Android, built by two skill sets. It gives you the best performance and the earliest access to new OS features, and it costs roughly double because you’re building everything twice.

Cross-platform is where most sensible projects land. React Native (backed by Meta) and Flutter (backed by Google) let one team write one codebase that ships to both stores, with performance that’s indistinguishable from native for the vast majority of apps. You give up a little raw speed and occasionally wait for a plugin to catch up to a brand-new OS feature. In exchange you cut cost and time significantly. I default clients to this unless there’s a hard reason not to. If you want to go deeper on the tooling tradeoffs, I broke down the options in my guide to the best Android app development frameworks.

No-code and low-code builders (FlutterFlow, Glide, Adalo, Bubble) are the third path. They’re genuinely useful for an MVP, an internal tool, or proving demand before you spend real money. The catch: you’ll hit a ceiling on custom logic, you’re tied to the platform’s pricing and limits, and migrating off later means a rebuild. Use no-code to validate, not to scale.

Define the MVP: One Core Job

The single most common reason an app blows its budget is scope. Your first version should do one job exceptionally well, not ten jobs adequately. Write down the one action a user takes that makes the app worth opening. For a delivery app it’s “order food and track it.” For a fitness app it’s “log a workout.” Everything that isn’t in service of that one core job goes on a “later” list.

This is hard because every stakeholder has a feature they’re sure is essential. Resist it. A tight MVP ships in weeks instead of months, gets real users in front of it sooner, and teaches you what to build next based on actual behavior instead of guesses. I’ve watched two teams with the same idea and the same budget end up in completely different places, and the difference was almost always discipline about the first release. The team that shipped one thing learned and iterated. The team that tried to ship everything ran out of money before launch.

Realistic Cost and Timeline Ranges

Here’s where I’ll give you numbers, because vague answers help nobody. A genuine MVP cross-platform app, one core job done well, typically runs $25,000 to $60,000 and three to five months from kickoff to store. A more involved app with accounts, payments, a backend, and a handful of real features lands somewhere between $60,000 and $150,000 and six to nine months. Anything with complex real-time features, heavy integrations, or two native codebases climbs past that quickly.

No-code MVPs are the exception and can come in under $10,000 if you build it yourself or with light help. Whatever bracket you’re in, budget for the parts people forget: design (often 15 to 20 percent of build cost), backend infrastructure, app store fees ($99 a year for Apple, a one-time $25 for Google), and the single biggest line item nobody plans for, which is everything that happens after launch.

Who Builds It, and How to Brief Them

You have three options for who builds the thing: an in-house team, an agency, or freelancers. In-house makes sense only when the app is core to your business long-term and you can afford to keep developers employed after launch. An agency costs more per hour but brings a full team, designers, developers, project management, and accountability, which matters when you can’t manage the build yourself. Freelancers are cheapest and great for well-defined pieces, but you become the project manager, and stitching together a designer, an iOS dev, and a backend dev is real work. I wrote more about choosing between these in my piece on getting outside help for business software development.

However you go, the brief makes or breaks the relationship. Don’t hand over “build me an app like Uber.” Hand over the one core job, your target user, wireframes or at least sketches of the key screens, the platforms you need, your budget range, and your timeline. Ask to see their portfolio of shipped apps that are still live in the stores, not mockups. Ask who actually does the work versus who you talk to. And get the source code ownership and account ownership in writing before money changes hands, because the most expensive mistake I see is a business that doesn’t own its own app store accounts or codebase. A good developer documents their architecture clearly, and that discipline matters more than price, as I argued in why architecture matters in custom software development.

App Store Reality: ASO, Reviews, and Updates

Shipping to the store is the start, not the finish. Apple’s review can take a day or two and can reject you for reasons you didn’t anticipate, so build a buffer into your launch date. Once you’re live, App Store Optimization (ASO) decides whether anyone finds you. Your title, subtitle, keywords, screenshots, and the first sentence of your description do most of the work, and your conversion from store-page view to install is the metric that compounds.

Reviews are your reputation and your ranking at the same time. Prompt happy users to rate the app at a good moment, after they’ve completed that one core job, never on first launch. Respond to negative reviews quickly and publicly, because future downloaders read them. And expect to ship updates constantly: bug fixes, OS-compatibility patches when Apple and Google release new versions every year, and the features your real users actually ask for. An app that goes quiet for six months reads as abandoned, and downloads follow that perception down.

Maintenance Is Forever

The number that surprises every first-time app owner is the ongoing cost. Plan on 15 to 25 percent of your original build cost every year, indefinitely, just to keep the app working. iOS and Android ship major versions annually and routinely break things. Your backend needs hosting, monitoring, and security patches. Third-party libraries get deprecated. None of that is optional, because an app that stops working gets one-star reviews and uninstalls within days.

So my honest verdict for a small business: don’t build a native app unless you’ve genuinely cleared the “do I even need this” bar, and even then, start with a cross-platform MVP that does one job, ship it, and let real usage tell you what to do next. For most small businesses, a fast, well-built mobile website or PWA delivers 90 percent of the value at a fraction of the cost and a fraction of the ongoing burden. Building an app is a long-term commitment, not a project with an end date. Go in knowing that, decide each question above on purpose, and you’ll be in the small group that gets it right.