Mobile app or web service

Most small and mid-sized companies get everything they need from a web service that opens in the phone browser. It costs less to start, it updates the same day with no approval from app stores, and a person reaches it through an ordinary link from an ad, a newsletter or a business card.

An app in the App Store and Google Play pays off in a different situation. When a customer or an employee opens the product every day, and the scenario calls for reliable background work, full access to the phone hardware, and predictable behavior without a network. Without those scenarios an icon on the phone screen stays an icon. Below we go through how to recognize your own case, what budgets and timelines to expect, and where owners lose money most often.

What you get in each case

Both options close the same business tasks: a customer dashboard, booking a service, placing an order, reports for the manager. The difference sits in where the interface lives, who controls access to it, and what every change costs after launch.

A web service in the phone browser

A web service is a full program that runs on a server and opens at an address in the browser. From the outside it can look exactly like an app: its own login screen, a bottom menu, cards, buttons, a cart. The phone installs nothing, it renders a page. You change a price, a form or a calculation rule, and within minutes every user sees the same thing.

This format fits tasks where people switch devices during the day, from a phone in the morning to a laptop in the office by noon. One web service opens on Android, iPhone and Windows, and you never pay for a separate build per system.

An app from the store

A mobile app installs on the phone and gets access to the device itself. It feels smoother on heavy screens with long lists and maps, sends push notifications, reads the camera and sensors, and stores data for work without a network. The price of that is separate development for iOS and Android, developer accounts in both stores, and a review of every version before it goes public.

One more thing owners rarely plan for in advance. People update apps whenever they feel like it, so part of your audience runs a build from several months ago. The server has to support several versions at once, and every new feature goes through a compatibility check against the older ones.

When a web service is enough

The simplest self-check is to look at how often a person interacts with the product and what they do in that moment. Compare it with the list below.

• Customers come back rarely. Booking an appointment, ordering delivery once a week, checking the status of a request. Nobody visits an app store and gives up phone storage for that.
• Traffic comes from ads and search. A link opens immediately and the person sees your offer in a second. Installing an app adds an extra step, and part of the audience disappears on it.
• The product is needed on a computer too. Managers, accounting and warehouse staff work on large screens, and a browser dashboard suits them better than any mobile version.
• The feature set is still moving. While you look for a working model, changes ship every week. On the web that is a routine release, while in the stores each version waits for review.
• The audience is broad and mixed. Some of your customers carry old phones with little free storage and will not install anything.

In our experience a large share of app inquiries turns into a browser dashboard after this check. The client gets the same value sooner and for less money.

When a mobile app pays off

Some tasks need more stability and deeper phone integration than a browser can offer. There the cost of two platforms is justified.

• Daily return. A taxi service, food delivery, a financial product, a loyalty program with points. People open the service constantly, and hunting for the right browser tab tires them out.
• Push notifications as part of the service. Order status, a schedule change, a reminder about a visit. On iPhone the web push options are narrower, and the app wins here.
• Work without a stable connection. Field crews, sales reps, a basement warehouse, a courier in an elevator. Data stays on the device and syncs once the network is back.
• Phone hardware. A barcode scanner in the warehouse, a photo of a defect attached to a ticket, a driver route, a customer signature drawn on the screen.
• A tool for your own staff. When the devices belong to the company, the app is installed centrally and the public stores stay out of the process.

Most of these points describe a person who works with their hands outside the office. That is the most common reason a company genuinely orders mobile development.

Money and timelines

The development budget is the first line of the calculation, and the cost of ownership follows it. Below are our working ranges for web services.

The scope of each tier and examples of our projects are on the web application development page.

Smaller jobs are counted differently. A single improvement on a finished project runs from $300 to $1,000, separate modules and API integrations from $500 to $2,000, and hourly work starts at $20 per hour. That format suits systems that are already live. Terms and examples are collected on the custom development page.

What an app adds on top of that budget

• Two builds instead of one. iOS and Android are built on different technologies. Even with a cross-platform approach you keep separate testing, separate quirks and separate fixes for each system.
• The server side is needed either way. An app without a backend is a display window. Data, roles, payments and reports live on the server, and you pay for that work equally in both scenarios.
• Accounts and publishing. A yearly fee for an Apple developer account, a payment for a Google account, a store page with screenshots and a privacy policy.
• Review of every release. A submission can come back with a remark, and the launch moves by several days. Planning an ad campaign for the same day as a release is risky.
• Constant upkeep. Apple and Google ship new system versions every year, change the requirements for apps and the publishing rules. The build needs updates even when nothing in your business changed.

Because of this the same feature set costs noticeably more to build inside an app and even more to own. Our technical support plan for a web service starts at $400 a month, and the format with 40 hours of work every month starts at $800.

PWA as a middle option

A PWA is a web service that the browser allows you to place on the phone home screen. There is an icon, there is a full screen mode, and part of the data is stored for work on a weak connection. On Android push notifications work as well, while on iPhone the options are narrower and we advise against building critical scenarios on them.

Who a PWA suits

The format solves the task when a customer wants quick access from the home screen and the feel of a separate program. A modern PWA can use the camera and geolocation, store data for offline use, and show push notifications on supported devices, so for dashboards and catalogs its capabilities are usually enough. The line runs where reliable background work and deep system integration are required. A customer dashboard, a panel for managers, a booking system, an internal price reference for sales reps all fit here well.

There are no separate iOS and Android builds and no store publishing, so a PWA often becomes the first step. Installability, caching, offline behavior, and push notifications still get their own estimate, yet the total stays well below two native builds. From there you test demand, collect statistics and only then decide whether a full mobile version is worth the investment.

How to test the idea before a large budget

The most expensive mistake is ordering a complete system based on assumptions. The owner describes two dozen screens, pays for all of them, and after launch it turns out that people use three. So the first thing we build is a short working version with one main scenario. For us that is an MVP from $4,000 and from 1.5 months, with the scope described in the web application development section.

What the first version contains

• One main scenario, end to end. The path the customer came for: place an order, submit a request, see their balance. The remaining sections wait for the next stage.
• Login and roles. A customer, a manager and an administrator see different data. Permission separation goes in from the start, since reworking it later is expensive.
• An admin panel for your team. So that prices, texts and statuses change without calling a developer.
• Payments, when that is where the money comes from. Connecting a payment provider before the first release gives a clear picture of orders.
• Event analytics. You need to see which screen people stop on. Without that the next stage is pure guesswork.

The calendar in this kind of work slips mostly because of content and approvals on the client side. We covered how long website development takes separately, and that article lists the stages that stretch out most often.

Mistakes that cost real money

We see these situations regularly when someone brings us a finished product.

• An app for a one-time action. Nobody installs a program to submit a single request or look at a price list once. A page with a form covers it.
• An estimate without the cost of ownership. The budget has development in it and no support, no servers, no updates for new system versions. Twelve months later the product stalls, because no money was set aside for it.
• Moving the whole website into an app. The catalog, the blog and the contacts page are useless inside a mobile build. Only what people use constantly belongs there.
• A boxed solution where your own logic is required. Ready platforms save time at the start and hit a ceiling on nonstandard processes. We went through the difference in the article on a ready-made solution or custom development.
• A launch with no plan for the first weeks. The product is handed over and then silence: nobody watches errors, collects feedback or corrects problem screens. We have a separate piece on the first 90 days after launch.

Conclusions

The choice between a mobile app and a web service is decided by the behavior of your users. Count how often a person opens the product and what they do at that moment, and the answer becomes obvious before you even talk to a contractor.

• Rare visits, traffic from ads, a need to work from a computer as well: take a web service.
• Daily use with heavy background scenarios and deep phone integration: budget for mobile development together with the server side.
• An icon on the screen without heavy mobile features: look at a PWA, it fits the budget of a regular web app.
• An idea with no confirmed demand behind it: start with a short working version and add features based on real data.

At Amidcode we build web services and business portals on Laravel and see both scenarios every month. Describe the task in your own words and we will tell you straight whether you need an app, or whether the money works harder in the web part and its promotion.