The conversation usually starts the same way. A founder has an idea, a rough budget, and a clear conviction about one thing: they need an app. What they mean by “app” is where the conversation gets complicated and where the decision gets expensive if it goes wrong.
Some mean a native mobile application on iOS and Android. Some mean a web platform that works on any browser. Some mean both, simultaneously, because their mental model of the product requires it. The problem is that all three answers carry meaningfully different cost structures, development timelines, and strategic risk profiles. Choosing the wrong one at the MVP stage doesn’t just waste money. It wastes the first six months of your product’s life the months when learning velocity matters most and runway is most finite.
According to Statista, mobile devices account for approximately 60% of global web traffic in 2026. That number is real, but it doesn’t tell you which platform to build first. Your users’ specific behaviour, not global traffic averages, determines the right answer. Getting that distinction right before you sign a development contract is one of the most commercially important decisions a London startup founder makes.
This article gives you the framework to make that decision correctly: what each platform actually costs, where each one wins, where each one loses, and how to know which path your specific product requires.
What You’re Actually Choosing Between (And What Gets Confused)
Before the framework, the terminology needs to be precise. Founders regularly conflate four different things, and the confusion generates proposals that answer the wrong question.
A native mobile app is built specifically for one platform: iOS using Swift, Android using Kotlin, or both using separate codebases. It installs from an app store, runs directly on the device, and can access hardware features like the camera, GPS, push notifications, and biometric authentication. Building native for both platforms means building and maintaining two separate products. That is not a minor distinction. It is a structural cost implication that compounds through every feature you add after launch.
A cross-platform mobile app is built once using a framework like Flutter or React Native and deployed to both iOS and Android from a single codebase. It reaches near-native performance for most use cases, accesses most device hardware, and costs meaningfully less than dual native builds. This is the default choice for London startups building mobile-first products without the budget or team size to support two separate native codebases.
A web app runs in a browser. It requires no installation, works on any device, and can be updated instantly without waiting for app store review cycles. The trade-off: limited access to device hardware, no push notifications on iOS without workarounds, and a user experience that depends on browser quality and connection speed rather than device capability.
A progressive web app sits between the two. It is a web application built to behave like a mobile app: installable from the browser, capable of push notifications on Android, functional offline through service workers, and fast enough to feel native on a decent connection. The progressive web app developers London working at the frontier of this technology are delivering experiences that most users cannot distinguish from native apps for the right product categories.
Not X. It is not a question of mobile versus desktop. It is a question of where your core user action happens, what hardware your product needs to access, and what your first six months of evidence collection requires.
The Case for Building Web First: Where It Wins Without Argument
For a specific and significant category of London startups, building web first is not a compromise. It is the strategically correct answer, and founders who resist it are usually resisting it for the wrong reason.
Web apps win on four dimensions that matter acutely at the MVP stage: speed of development, cost of development, ease of iteration, and breadth of access. A focused web application can be built in eight to twelve weeks rather than the sixteen to twenty-four weeks a polished cross-platform mobile build typically requires. That time difference is not trivial when your runway is finite and your learning objective requires real user behaviour, not just user interest.
Consider what the web’s update cycle means in practice. A mobile app update requires submission to the App Store and Google Play, review periods that run one to seven days, and user acceptance the percentage of your installed base that actually updates the app. A web app update deploys in minutes and is live for every user simultaneously. For an MVP that is actively learning and iterating on core flows, the ability to push a UX change and see behavioural data shift within forty-eight hours rather than two weeks is not a nice-to-have. It is a learning-velocity advantage that compounds across every sprint.
The web also eliminates the app store as a distribution problem. App store optimisation, review policy compliance, keyword competition, and the thirty-day delay between submission and visibility are real friction that slows early user acquisition. A web app can be live and indexed within days of launch. For B2B products targeting professionals who will discover and evaluate the tool on a desktop browser, the app store is irrelevant to the acquisition journey anyway.
The founders who resist web-first for the wrong reasons typically cite one of two things: “our users are on mobile” or “an app feels more credible.” The first claim requires evidence, not assumption and the evidence is your specific user’s specific behaviour, not global traffic statistics. The second claim is a brand feeling masquerading as a product decision. Credibility is built by delivering value, not by appearing in an app store.
The Case for Mobile First: Where Native Wins and Why It Matters
There is a category of product for which building web first is genuinely the wrong answer. Not because mobile is inherently superior, but because the core value proposition depends on device capabilities that the web cannot reliably deliver.
If your product’s primary value lives in the camera a visual inspection tool, a document scanner, an augmented reality feature native or cross-platform mobile is not a preference. It is a technical requirement. Mobile camera access from a web browser is improving, but it remains inconsistent across devices and browsers, and the user experience gap between a native camera integration and a web-based one is perceptible to most users within seconds.
If push notifications are core to your engagement model rather than a nice-to-have feature, mobile wins clearly. iOS does not support push notifications for web apps installed from a browser with the same reliability as native push, and the user opt-in rates for native push notifications, while declining, remain substantially higher than web push opt-in rates. For a product whose retention model depends on timely, high-frequency notifications a fitness app, a trading alert platform, a shift management tool mobile is the right infrastructure.
If offline functionality is genuinely central to the use case field service workers who operate in areas without reliable connectivity, delivery drivers using the app in transit, logistics teams in warehouses with poor signal native mobile provides more robust offline capability than web, even accounting for service workers and progressive web app technology.
The honest test: remove push notifications, camera access, and offline functionality from your product’s core value proposition. What remains? If the answer is “the product still works and still delivers its primary value,” you probably don’t need to build mobile first. If the answer is “the product doesn’t work without those things,” you do.
The Progressive Web App Middle Ground: When It’s the Right Structural Answer
The progressive web app occupies a position that most London startup founders don’t consider seriously enough, and the consequence is that they either over-invest in native mobile or under-deliver on the mobile experience their users need.
A PWA built to the current standard is installable, runs offline for cached content, supports push notifications on Android, loads at near-native speed on a good connection, and can access a growing subset of device hardware that would have been native-only three years ago. For a large category of consumer products and most B2B tools, it closes the gap between web and native to the point where the remaining gap doesn’t materially affect user behaviour.
The cost implication is significant. A PWA adds approximately twenty to thirty percent to the cost of a web build rather than doubling it, which is what adding a native mobile app to a web build typically does. For a startup choosing between spending £60,000 on a web app and £110,000 on a web app plus a native mobile app, the PWA path at £75,000 to £80,000 deserves a serious evaluation rather than being dismissed as a technical compromise.
The progressive web app developers London working at the current standard are building products that users install, engage with daily, and refer to others without ever visiting an app store. For the right product category, this is not a second-best outcome. It is the correct architecture from the start.
The Cost Comparison That Most Agencies Won’t Give You Directly
The pricing conversation around mobile versus web is one that agencies frequently obscure with scoping caveats and “it depends” qualifications. The ranges below are real. They reflect London market rates for credible development partners with genuine mobile experience, not offshore rates or freelancer quotes.
A focused web app MVP with authentication, a core workflow, and a simple dashboard runs £25,000 to £55,000 for a six to ten week build. A web app built to PWA standards on the same scope runs £35,000 to £70,000. A cross-platform mobile MVP using Flutter or React Native on the same functional scope runs £45,000 to £90,000. A dual native build separate iOS and Android codebases runs £80,000 to £160,000 for equivalent functionality.
These ranges assume a competent UK-based or UK-supervised team, discovery included, with a post-launch support period of four weeks. They are starting points, not quotes. Complexity in the authentication model, third-party integration requirements, and regulatory compliance requirements all move the number. But the order of magnitude relationship between these four options is consistent across the market: web is the cheapest, dual native is the most expensive, and cross-platform mobile and PWA sit between them at different points on the spectrum.
The implication for your decision: if your budget is £40,000, you can build a credible web MVP or a credible PWA. You cannot build a credible cross-platform mobile app. Forcing a native mobile build into a £40,000 budget produces a product that isn’t competitive enough to generate clean learning data, which defeats the purpose of the MVP entirely.
How User Behaviour Data Should Drive the Decision, Not Assumptions
The most common mistake in the mobile versus web decision is making it based on what founders assume their users prefer rather than what evidence shows their users actually do.
Ask yourself: where does your target user resolve similar problems today? Not “do they use their phone a lot.” Where specifically does the behaviour your product is trying to capture already happen? A finance professional tracking portfolio performance is already doing it in a browser tab at their desk. A field engineer inspecting equipment is already doing it on their phone in the field. A procurement manager approving purchase orders is already doing it in an email client on their laptop. The device context of the existing behaviour is the strongest single predictor of where your product needs to live.
If you don’t have direct evidence yet, a landing page test costs less than £5,000 and produces real behavioural data in two to four weeks. Build a landing page that describes the product and presents two sign-up options: “get early access on web” and “get early access on iOS/Android.” The split of sign-ups tells you where your users expect to find you. That data point, however imperfect, is worth more than any amount of internal debate about user preferences.
The top software development companies in London that advise on platform decisions before accepting a build brief are the ones worth working with. An agency that agrees to build whatever you specify without challenging the platform assumption is an agency that will build you something expensive before you’ve confirmed what you actually need.
Scaling Considerations: What Your Platform Choice Means at 50,000 Users
The MVP decision doesn’t just determine what you build in month one. It shapes the architecture your product runs on when it reaches scale and the cost of undoing that architecture if it wasn’t right.
Web apps built on modern cloud infrastructure scale horizontally without significant re-architecture. User load distributes across server instances, database connections pool appropriately, and the infrastructure cost grows approximately linearly with usage. The scalable cloud development companies London teams rely on for production-grade deployments those working with AWS, GCP, and Azure at the application layer deliver web architectures that can handle 50,000 concurrent users on the same codebase that served 500.
Mobile apps face a different scaling challenge: the backend. A cross-platform mobile app depends on an API layer that must be designed for scale from the start, because retrofitting a poorly designed API for load is architecturally painful and expensive. The API is the mobile app’s equivalent of the web server, and it needs the same scalability thinking applied at the same early stage.
The scaling mistake specific to mobile: building a backend that works for your first 1,000 users but wasn’t architected with connection management, caching strategy, and data model efficiency in mind for 100,000. This mistake is common because the symptom performance degradation under load doesn’t appear until you’re already at a stage where slowing down the product is commercially damaging. The best development partners architect against this problem in the sprint design phase rather than the emergency remediation phase.
The scalable cloud development companies London startups use for infrastructure decisions at this level bring the same architecture conversation to both web and mobile builds. The difference is that web apps have more mature tooling for auto-scaling, traffic management, and performance optimisation at the infrastructure layer, which reduces the operational complexity of hitting a growth inflection point without warning.
The Honest Concession: When Building Both at the Same Time Makes Sense
This article has argued for sequencing: pick one platform, validate the core value proposition, then expand. That argument holds for the majority of London startups at the MVP stage. It does not hold universally.
There is a specific category of product for which simultaneous web and mobile presence is not a preference but a structural requirement for the core value proposition to work. A marketplace that connects supply and demand needs to be accessible to both sides, and if one side is fundamentally mobile-native while the other is fundamentally web-native, building only one platform means you can’t close the loop. A two-sided platform for field workers and office managers can’t test its core dynamic if only one side has a usable product.
If your business model requires simultaneous participation from two user groups with different device contexts, the argument for sequencing breaks down not because building both is easy, but because building only one means the product cannot produce the evidence it needs to validate the model. In that case, the budget needs to reflect the reality of building for two platforms rather than being squeezed into a single-platform budget and producing two inadequate products.
The honest question to ask before accepting this framing: is the two-sided requirement genuinely structural, or is it a product preference that could be satisfied with a constrained early version? A marketplace can often test its core hypothesis by having one side use a mobile app and the other use a simple web form not a full web platform until the unit economics are proven. The minimum viable version of a two-sided product is often simpler than founders believe.
Frequently Asked Questions
Should I build a mobile app or a web app for my London startup?
Build where your core user behaviour already lives. If your target users resolve similar problems on a desktop browser, build web first. If the core value proposition requires device hardware camera, GPS, push notifications, offline access build mobile first. Global mobile traffic statistics are irrelevant to this decision. Your specific user’s specific behaviour context is the only data point that matters.
What is the cost difference between a mobile app and a web app in London?
A focused web app MVP runs £25,000 to £55,000 in the London market. A cross-platform mobile MVP using Flutter or React Native runs £45,000 to £90,000 for equivalent functionality. A dual native build for iOS and Android separately runs £80,000 to £160,000. A progressive web app sits between web and cross-platform mobile at £35,000 to £70,000. These ranges include discovery and four weeks of post-launch support from a UK-based or UK-supervised team.
What is a progressive web app and is it the right choice for my startup?
A progressive web app is a web application built to behave like a mobile app: installable, capable of push notifications on Android, functional offline for cached content, and fast enough to feel near-native on a good connection. It costs approximately twenty to thirty percent more than a standard web build but substantially less than a native or cross-platform mobile build. For products whose core value doesn’t require native hardware access beyond what PWA technology supports, it is frequently the correct architectural choice at the MVP stage.
How long does it take to build a mobile app versus a web app?
A focused web app MVP typically takes six to twelve weeks of development after a four to six week discovery phase. A cross-platform mobile MVP on equivalent scope takes twelve to twenty weeks, depending on the complexity of the mobile-specific interactions. The update cycle difference is equally significant: web app updates deploy in minutes, mobile app updates require app store review periods of one to seven days and user uptake time on top.
When does it make sense to build both web and mobile simultaneously?
When the core value proposition structurally requires simultaneous participation from two user groups with different device contexts a marketplace connecting field workers to office managers, for example building both simultaneously may be necessary. In most other cases, sequencing is more cost-effective and produces cleaner learning data. Before accepting the two-platform requirement as structural, test whether a constrained version of one platform could validate the core hypothesis before the second platform is built.
How do I know which development partner is right for a mobile vs web decision?
The right partner challenges your platform assumption before agreeing to build. Ask any potential agency to describe the last three times they recommended a different platform than what the client originally requested, and why. Agencies with genuine platform advisory capability have specific answers to that question. Agencies that build whatever they’re asked to build without challenging the brief will cost you more in the long run than their day rate suggests.
The Decision Is Simpler Than the Debate
Most founders spend more time debating mobile versus web than the decision actually warrants, once the right framework is applied. The framework is not complicated: build where your user already is, with the minimum hardware access your core workflow requires, at the cost your current budget can support without constraining the quality of the learning the build produces.
Web first is right for most B2B products, most content-driven products, and most marketplace products at the MVP stage. Mobile first is right for products whose core value lives in device hardware, real-time location, or high-frequency push-driven engagement. The progressive web app is right for the significant middle ground between those two poles, where mobile behaviour is expected but native hardware access is not structurally required.
What makes this decision expensive is not its complexity. It is the social pressure to build the more impressive-sounding option rather than the strategically correct one. A native mobile app sounds more serious than a web app. It photographs better in pitch decks. It generates a different kind of investor reaction in the first thirty seconds of a demo. None of those reasons are good enough to justify an additional £40,000 to £70,000 in development cost and a twelve-week extension to your timeline.
The top software development companies in London that operate at the advisory end of this conversation the ones who will tell you to build web when you came in asking for mobile, and who can justify that recommendation with specific evidence from your user research rather than generic best practice are the partners worth finding before you commit your budget to a platform choice that will shape your product for the next three years.
Among the progressive web app developers London founders work with at this standard, the most common piece of advice is the same one that applies to every platform decision: don’t let the technology choice precede the user behaviour evidence. Build what your users need, on the device they already use, in the timeframe your runway allows.
For decisions that involve significant cloud infrastructure whether the product is mobile, web, or both the scalable cloud development companies London startups rely on for production-grade architecture bring the same discipline to infrastructure as the best product teams bring to platform selection: choose what the business needs now, design for what it will need at ten times the scale, and build the bridge between those two points deliberately rather than by accident.
If you’re a London startup navigating this decision and want a partner who will give you a direct answer rather than a qualified one book a free 30-minute discovery call with Empyreal Infotech. No pitch deck. No pressure. Just a direct conversation about which platform your product actually needs and why.
