Why so many mobile app projects go sideways
Every year we take over at least one mobile app project that another team started and could not finish. The pattern is depressingly consistent. A founder had an idea. A development shop quoted a fixed price. Work started before anyone had written a proper product specification. Six weeks in, the founder realized they wanted features nobody had discussed. The dev shop began charging change orders. Timelines slipped. Quality slipped. Trust collapsed. By month four the project was either abandoned or delivered as a bare-bones version of what the founder originally imagined, and nobody was happy.
The good news is that every one of the failure modes is predictable and preventable. This post is the pre-development brief we now insist every mobile client read before we start building. It covers the questions that decide whether the project takes six weeks or six months, the technology decisions that determine whether the app can grow with the business, and the operational realities of shipping and maintaining a mobile product year after year.
Question one: does this actually need to be an app
The most valuable question in the room is usually the one nobody asks. Does the thing you are trying to build actually need to be a native mobile app. In a surprising number of cases, the honest answer is no. A well-built mobile web experience — a responsive site, or a progressive web app — can deliver eighty percent of the value at twenty percent of the cost and complexity.
Apps are the right choice when you need one or more of the following. Frequent, habitual engagement that benefits from being one tap away on the home screen. Rich device integration — camera, sensors, background location, push notifications delivered reliably, offline functionality. A branded moment that benefits from being separate from the browser context.
Apps are the wrong choice when the primary use case is occasional, when discovery happens mostly through search and social, when the audience is price-sensitive and reluctant to install anything, or when the feature set is mostly rendering pages of content. In those cases, a great mobile web experience will out-convert a mediocre app every time and will not require the audience to complete a friction-heavy install.
Question two: iOS, Android, or both, and in what order
Cross-platform frameworks like React Native and Flutter have made "both platforms at once" the default answer, and for most product categories it is the right one. Building twice in Swift and Kotlin costs more, takes longer, and forces every future feature to be shipped twice. Cross-platform is the correct default unless you have a specific reason not to.
Reasons to go native. You need bleeding-edge platform features on day one — the latest ARKit capability, a specific new iOS API. You are building a game or a highly graphical experience where you need every frame. You have a large existing native team and rebuilding around cross-platform would waste institutional knowledge.
For every other case, React Native or Flutter is the right answer. Between the two, our default is React Native because the JavaScript ecosystem is enormous, the hiring market is deep, and code sharing with a web front end becomes possible over time. Flutter is a genuinely excellent alternative if you want a more opinionated toolchain and are willing to hire for Dart.
Question three: what does "MVP" actually mean for you
MVP — minimum viable product — is the most abused acronym in software. Every founder claims to want an MVP. Nine out of ten specifications we receive are not MVPs. They are the founder's ideal product with the word "MVP" pasted on the cover.
An honest MVP is the smallest product that lets a real user complete the one core action your business is built around. For a food delivery app that is browse, add to cart, pay, receive the order. That is the MVP. Reviews, favorites, referral codes, loyalty points, ambassador programs, in-app chat, gamification badges — every one of those is a great feature and none of them belongs in the MVP. Ship the core action, get real users through it, and let their behavior tell you which of the fifty possible next features actually matter.
The discipline of a genuine MVP is not primarily about cost saving. It is about learning speed. Every feature you add to version one delays the moment you get real feedback from real users. That delay is the single most expensive thing in early-stage product development, because it prevents you from correcting course before you have committed months of engineering to the wrong idea.
Question four: what is the backend story
Half of every serious app project is the backend. Founders sometimes forget this and are surprised when the quote arrives. Real applications need user authentication, data persistence, business logic, integrations with third-party services, admin dashboards, analytics, and infrastructure that stays online as the user base grows. Every one of those has to be designed, built, secured and maintained.
The modern backend for a mobile app usually looks like this. A managed database — Supabase, Firebase, or a self-hosted Postgres — that handles user data and business objects. Serverless functions or a small backend service for business logic that cannot live client-side. A push notification service. An analytics platform. A file storage service for media. An error monitoring service. Payment processing. Email and SMS providers. Every one of those has to be chosen, wired together, secured, and monitored.
The good news is that the ecosystem for backend-as-a-service has matured to the point where a small team can stand up a robust backend inside a week. The bad news is that the total complexity of a real production app is still higher than most first-time founders expect, and skipping it or treating it as an afterthought is how you end up with a beautiful front end that stores user data insecurely and falls over the day you get press coverage.
Question five: how will people find the app
The average user installs a couple of new apps a month. The App Store and Play Store are crowded, competitive, and largely opaque to new entrants. If your growth plan is "list it in the store and hope for organic downloads," you do not have a growth plan.
Real app growth comes from a combination of paid acquisition, deep linking from your web presence, referral loops, and a genuinely great in-product experience that produces word of mouth. The paid acquisition math is often brutal — for consumer apps, cost per install runs from thirty to three hundred rupees depending on category and geography, and the fraction of installs that convert to active users is often below twenty percent. Model the funnel before you decide whether the app economics work.
For B2B and services businesses, the growth model is different. Your website is your storefront and the app is a tool for existing customers. In that case, focus install marketing at your existing customer base — post-purchase emails, WhatsApp campaigns, in-store QR codes — rather than trying to compete on discovery in the stores.
Question six: what happens after launch
An app is not a project. It is a product. It needs to be maintained forever. Every quarter, Apple and Google release new operating systems that occasionally break something. Every quarter, the frameworks and libraries you depend on ship updates. Every quarter, users report bugs, ask for features, and leave reviews. If you launch a mobile app and stop investing after launch, it will visibly rot within a year.
Budget for a maintenance retainer from day one. A reasonable rule of thumb for a mid-sized production app is fifteen to twenty percent of the original build cost per year in ongoing engineering time — for bug fixes, OS updates, small feature improvements, and monitoring. Below that number you will accumulate technical debt that eventually forces a rewrite. Above that number you are underinvesting in new customer acquisition and should probably reallocate.
Choosing a build partner
Every mobile project ultimately succeeds or fails on the strength of the team building it. When you evaluate a partner, ask to see live production apps they have built, not slick portfolio pages. Ask to talk to those apps' founders and hear the unvarnished story of what worked and what did not. Ask for the CV of the specific engineers who will work on your project, not the flagship engineers who show up in the sales pitch and disappear after the contract is signed. Ask how they handle scope changes, how they manage timelines, and how they communicate when things slip — because things will slip.
Fixed-price contracts sound safe and rarely are. In practice, the shop is incentivized to interpret every ambiguous requirement in the way that minimizes their own effort, and every change to the specification becomes a negotiation. Time-and-materials contracts sound risky and often produce better outcomes, because the team and the client are aligned on the same goal — a great product shipped quickly. The trick is to work with a partner you trust, agree on a weekly cadence and a monthly budget cap, and hold the entire relationship to a shared quality standard.
The honest timeline
An MVP for a well-scoped consumer app runs eight to twelve weeks. A production-grade version of the same app, with the full backend, admin dashboard, analytics integration, and polish, runs four to six months. A complex marketplace or fintech product with regulatory obligations runs a year or more. Timelines that promise significantly less than these are either lying, cutting corners you will pay for later, or working on a scope that will not survive contact with reality.
If you are new to app development, budget both time and expectation. Assume the first version will be smaller than you initially wanted. Assume you will discover things during development that force you to redesign parts of the product. Assume the launch will be smaller than you dreamed and the growth will be slower than you hoped. Every founder we know who eventually built a successful app started with those expectations and stayed patient. Every founder we know who failed started with the opposite.
What we would tell a first-time founder
Ship the smallest thing that lets one real user complete the one core action. Build it on cross-platform unless you have a specific reason not to. Invest in the backend as seriously as the front end. Plan for maintenance as a permanent line item. Choose a build partner you would trust to tell you bad news early. And be prepared for the app to change more between launch and product-market fit than it changed between spec and launch. Every serious app product does.
