Most founders we meet open the conversation with "we want to build an app." The honest answer is that most of them do not yet know whether the right first build is a web app, a native mobile app, or both. The question is not should we build an app. It is who is the user, what are they trying to do, and where will they actually be when they try to do it. Get those three right and the platform choice usually answers itself. Get them wrong and you spend twelve months and a startup's worth of capital building the wrong thing on the wrong platform. This article walks through the framework we use with Sri Lankan clients to make the call honestly, with realistic cost and timeline numbers for each path.
The Question Most Founders Ask First, and Why It Is the Wrong One
"Should we build an app" is the wrong question because it skips the user. Apps are not a marketing channel, they are a usage pattern. The right question is whether the user's relationship with your product is the kind that earns a place on their home screen. If the answer is yes, native is on the table. If the answer is no, you are about to spend six figures on a download that will be opened twice and uninstalled the next time the phone is low on storage.
Three more useful questions take its place.
- Who is the user, and where do they spend their working day? A field operations manager lives on a phone. A purchasing officer lives on a desk.
- What is the core action they take, and how often? Daily check ins favour native. Quarterly approvals favour web.
- How will they discover and adopt the product? Search and link sharing favour web. Word of mouth and brand pull can support an install.
The Six Question Framework We Actually Use
This is the decision matrix we run through in every Dev Studio discovery session. None of these questions on their own settles the platform call, but the pattern of answers across all six almost always does.
- One. How will the user first encounter the product? If discovery happens in Google search, on a partner website, or via a shared link, web has a structural advantage. If discovery happens through community, paid app campaigns, or an existing brand following, native is viable.
- Two. How often is the core action performed? Multiple times a day means an icon on the home screen earns its keep. Once a week or less means asking for an install is friction the user will not pay.
- Three. Do you need push notifications to drive value? Real time alerts that the user must see immediately are an app strength. Email or SMS handles less time sensitive nudges perfectly well from a web product.
- Four. Does the product need to work offline or on weak connections? Field workers, delivery drivers, and rural users in Sri Lanka regularly hit dead zones. Native handles offline gracefully. Web is improving but still trails.
- Five. Does the product need device features? Camera, GPS, biometrics, Bluetooth, background location. The more of these you need, the heavier the case for native.
- Six. Is the audience B2B or B2C? B2B users generally accept web because work happens at a desk. B2C users skew mobile, especially in categories like food, transport, banking, retail loyalty, and entertainment.
When a Web App Is the Right First Build
Web is faster to ship, cheaper to maintain, and discoverable through search. For a large number of Sri Lankan business problems, it is the correct first answer.
- B2B and internal platforms. CRMs, dashboards, approval flows, project tools, custom internal portals, vendor portals. The work happens on a laptop and the audience is reachable by URL.
- Marketing led products. SaaS tools, lead capture experiences, free calculators or generators where SEO is the growth engine.
- Long form transactional flows. Insurance applications, loan onboarding, government style forms, long checkouts. Bigger screens earn their keep here.
- Early stage startups validating an idea. Web ships in weeks, not quarters, and lets you iterate on real users before committing to the cost of a native build.
- Anything that needs to be linkable and shareable. Apps cannot be shared as a link that opens an exact screen. Web can.
The trade is the absence of the home screen icon and weaker push notifications. If neither matters to your use case, web is almost always the right place to start.
When a Native Mobile App Is the Right First Build
Native earns its place when the product lives in the user's pocket and the relationship is daily, real time, or device dependent. The Sri Lankan market has a clear pattern of categories where native is the correct first move.
- Consumer marketplaces and on demand services. Food, transport, grocery delivery, courier booking. The user is mobile while the action happens. PickMe and Uber Eats are the canonical examples.
- Banking and finance. Biometric login, push alerts for transactions, QR payments, and offline support all live in native.
- Loyalty and rewards. A retail loyalty product without push notifications is a database with a website. The notification is the value.
- Field operations. Sales reps, technicians, delivery drivers. Offline capability and device hardware are fundamental.
- Health, fitness, and wellness products. Daily engagement, biometric integrations, and notification driven habit loops favour native.
The trade is longer build time, higher initial cost, app store approval cycles, and the obligation to maintain two platforms (or accept the limitations of a cross platform framework).
"An app is a place on the home screen. If the user has no reason to keep that real estate occupied, you have built a download, not a product."
The Middle Path: PWAs and Cross Platform Frameworks
Two pragmatic options sit between a pure web build and two native codebases. Both have a real place, and both have honest limitations.
- Progressive Web Apps. A web app that can be installed to the home screen, work offline, and send push notifications. Excellent for products that need most of the app feel without the cost of a native build, especially on Android. iOS support is improving but still limited compared with Android.
- React Native and Flutter. One codebase that compiles to both iOS and Android. Mature, well supported, and the right answer for the majority of cross platform native builds. Performance is close to native for most use cases. Heavy graphics, AR, or deep system integration is where you may still want fully native.
For a Sri Lankan business shipping its first mobile app, React Native or Flutter is almost always the right call. Two platforms for the price of approximately one and a quarter, with a single team to maintain it.
How Much Does Each Path Actually Cost and Take?
Numbers are useful here. The figures below are realistic Dev Studio ranges for a focused first version, including discovery, design, build, testing, and launch. Costs scale with scope, not with platform alone, but these are the brackets we typically see.
| Build path | Typical timeline | Typical cost |
|---|---|---|
| Web app, focused MVP | 6 to 12 weeks | LKR 2 to 5 million |
| Progressive Web App | 8 to 14 weeks | LKR 2.5 to 6 million |
| Cross platform mobile (React Native or Flutter) | 10 to 18 weeks | LKR 4 to 8 million |
| Two native apps (iOS plus Android) | 16 to 28 weeks | LKR 7 to 14 million |
| Web plus cross platform mobile | 14 to 26 weeks, phased | LKR 6 to 12 million |
Two practical points worth flagging. First, the maintenance bill matters as much as the build bill. A native app has app store reviews, OS update cycles, and certificate renewals every year. Plan for 15 to 25 percent of build cost as annual maintenance, depending on how active the product is. Second, the second platform is rarely half the cost of the first. The discovery, design, and backend work do not double, so adding mobile to an existing web product or vice versa is meaningfully cheaper than the table implies if it is built on the same foundation.
If You Need Both, Which Should You Build First?
Most teams that eventually need both should still pick a starting point and ship it before opening the second front. The right starting point depends on which side of the product is closer to revenue.
- Web first when discovery and onboarding decide the business. SaaS products, marketing led startups, and any business where new users find you through search or referrals. Build the web app, prove the model, then add mobile to retain the users you already have.
- Mobile first when usage frequency and retention decide the business. Consumer products with a daily action, delivery and on demand services, loyalty plays. Build the native app first, optimise for retention, then add a web product for desktop access or partner integrations.
- Web and mobile in parallel when both are core from day one. Marketplaces with two distinct user types (a consumer mobile experience and a partner web dashboard) often justify the parallel investment. Done well, the backend is shared and the parallel build costs less than the sum of two sequential ones.
The Three Mistakes We See Most Often
- Building native because investors expect an app. If your users do not need an app, investors are wrong. Show them the usage data instead.
- Treating mobile as a smaller web app. Native users behave differently. The information architecture, navigation, and onboarding need to be designed for the platform, not crammed in.
- Skipping web because mobile feels modern. Web is where the search traffic, the link sharing, and the desktop usage live. Skipping it usually means rebuilding it later under pressure.
Worth noting
The cheapest mistake to avoid is building both at the same time without a shared backend. The most common rebuild we get hired to do is "we have a web app and a mobile app, but they were built by different teams on different stacks, and now nothing stays in sync." Pick one team, one backend, and one data model, even if the front ends ship in different orders.
The Verdict
- Wrong question. Should we build an app.
- Right questions. Who is the user, what action are they taking, how often, and where are they when they take it.
- Web first. B2B, internal tools, marketing led products, long form flows, anything that needs to be linkable.
- Native first. On demand consumer products, banking, loyalty, field operations, anything with daily use or device dependence.
- Cross platform. The right call for the majority of first time mobile builds in Sri Lanka.
- Both. Shared backend, sequenced front ends, with the order chosen by where revenue is closer.
If you are in the middle of this decision and want a second pair of eyes, the Dev Studio team runs a structured discovery session that walks through the six questions on your specific product. The output is a written recommendation with platform, scope, timeline, and a fixed quote, so you can make the call with the same numbers we would use ourselves.
