The question comes up in many first conversations: do we need an app? Behind it there is rarely a wish for a program of one's own, but a concrete goal - staying visible on the customer's phone, taking appointments, keeping prices and opening hours current, bringing returning visitors back quickly. For exactly that purpose a website can do more than most firms assume: it can be placed on the home screen, it starts without an address bar, it shows something even on a weak connection, and it needs no review before every change. This article shows what belongs to it, which cost items arise, and where a native app is still the better answer.
Where the app question comes from
The starting point is observed correctly: the phone is the main device. 92.4 percent (Eurostat) of people in Germany who used the internet in the last three months did so on a mobile phone in 2025. Anyone thinking about reachability rightly thinks of the small screen first. The conclusion drawn from it is often too quick: so, an app. Yet an app is one of several answers to the same question, and for the usual tasks of a small firm - enquiry, appointment, price list, directions, opening hours - it is as a rule the most laborious one.
It helps to turn the question around. What is supposed to happen on the phone? In most cases the answer is: somebody looks for the number, the address or the opening hours, sends an enquiry, books an appointment or checks what something costs. These are matters of a few seconds to a few minutes that are rarely repeated. Hardly anyone installs a program for that. The hurdle does not start with the operating, it starts with the download: account, storage, permissions - and afterwards an icon that sits unused in a folder three weeks later. How these paths should feel on the small screen is covered in detail in usability on the phone.
On the other side is the effort that is rarely discussed in a first conversation. A native app means two versions for two platforms, two tool chains, two sets of test devices. Every change - a new price, a reworded text, one more form field - passes a review before it reaches the customer. And because the website stays in place anyway, since it is the place search engines read and the one you put in an email signature, the firm maintains two systems instead of one from the day of release. What that means for planning is set out in one-off and ongoing website costs.
The question behind the question
What a website already does without an install
A website has been more than a document in a browser for years.
Three building blocks turn it into something that feels like a program of its own on the phone: a small description file, the manifest, a set of icons in several sizes, and a piece of code that keeps content ready for the next visit. All three are open standards, not purchases. They sit in the same deployment as the pages themselves and cost no second operation.
The manifest is a JSON file with a handful of fields. The relevant W3C specification states its purpose plainly: “Using this metadata, user agents can provide developers with means to create user experiences that are more comparable to that of a native application” (W3C). In plain terms: the browser may treat the website at launch like an installed program - its own icon, its own window title, its own entry point. The firm supplies data for that, not software.
- Enquiry form with required fields, confirmation and delivery to the right mailbox
- Appointment picking with free time slots instead of a call-back loop
- Opening hours, emergency cover and holiday closures that change in one place
- Map, directions and phone number as a tap target that dials straight away
- Price and service overviews that stay current without updating a program
- Documents to download: site sketch, forms, data sheets, price list
{
"name": "[Business name] - Painting and Decorating",
"short_name": "[Short name]",
"start_url": "/?source=homescreen",
"scope": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#004d43",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" },
{ "src": "/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
]
}The icon set is the part that trips people up particularly often in practice. The specification explains the size entries like this: “These sizes serve as hints for the user agent to determine a suitable icon to use in a particular context (e.g., on the home screen of a device)” (W3C). That has landed broadly: icons are set in 90 percent (Web Almanac) of the analysed manifests on desktop and in 91 percent on mobile, and around 85 percent (Web Almanac) ship the edge length 192 by 192 pixels. Anyone who only supplies the icon as a classic favicon gets a blurred crop on the home screen instead of a tile. Where good icons and preview images come from and how they work together is covered in preview image and favicon when sharing.
The test takes two minutes
The tile on the home screen
It is not widespread yet. The annual Web Almanac report puts it this way for 2025: “In 2025, we can see that roughly one fifth of sites use service workers, and roughly one tenth use manifests” (Web Almanac).
So around one tenth (Web Almanac) of the websites examined carry a manifest file at all. For a small firm that is good news: the effort is small, but the difference on the customer's phone is visible at once, because most other sites do not offer it.
One field decides the impression: display. With standalone in it, the website starts without an address bar and without a browser frame; the specification describes the mode as “Opens the web application to look and feel like a standalone native application” (W3C). That is the normal case: 78 percent (Web Almanac) of the analysed manifests set display to standalone. The effect is unspectacular and works anyway - what starts in a window of its own no longer feels like a bookmark.
/site.webmanifest name, short name, icons, display mode, start address
/icon-192.png 192 x 192 tile on the home screen
/icon-512.png 512 x 512 splash image and task switcher
/icon-maskable-512.png 512 x 512 version for round and rounded masks
/favicon.svg scales without loss for the browser tab
/sw.js keeps content ready for the next visitScroll table sideways
| Task | Native app | Installable website |
|---|---|---|
| Visible on the home screen | After an install from a platform store | After two taps in the browser menu |
| Serving two platforms | Two versions, two tool chains | One version, one state |
| Changing a price or an opening hour | New version, review, distribution, update on the device | The change is there on the next visit |
| Findable in search | The store listing, not the content | Every page findable and linkable on its own |
| Passing on a link | Detour via the store listing | The address points straight at the content |
| Access to camera, location, files | Complete, after permission | Largely, after permission in the browser |
| Background operation and sensors | Possible | Limited |
The third building block is called a service worker and is the reason an installed website shows something even on a weak connection. The specification names the purpose directly: “This specification also provides a fetch event, and a request and response store similar in design to the HTTP cache, which makes it easier to build offline-enabled web applications” (W3C). In practice: opening hours, contact details and the page read last sit on the device and appear before the connection is up. The technique is far more widespread than the manifest - 18.9 percent (Web Almanac) of the websites examined use a service worker. How much fast delivery matters overall is shown in PageSpeed 100 through static delivery.
What “installed” means here
When an app is the right answer
This honesty belongs here: there are cases in which a native app is the fitting tool, and they can be named clearly.
They have to do with something running permanently in the background, reaching deep into the device hardware or working in an environment without a connection - or with the application itself being the product rather than the advertising for it.
One argument regularly falls away, even though it comes up first in conversation: the notification. The Web Almanac analysis describes the behaviour soberly: “Desktop notification acceptance is overwhelmingly ignored: 78% of them are disregarded, with a slightly lower but still meaningful 48% on mobile” (Web Almanac). The figures come from Chrome permission telemetry and cover origins that run a service worker: for that group the report puts unheeded prompts on the phone at 48 percent (Web Almanac). Anyone building an app mainly to deliver messages builds on a channel that a large share of recipients swipes away. For appointment reminders, text message and email are as a rule the more dependable route - what an appointment path looks like that works without reminder pressure is covered in online appointment booking for small firms.
Permanent background operation
Positioning during a tour, measurement series over hours, recording without an open window: that belongs in a program the operating system keeps alive.
Deep device access
Near-field communication, attached measuring equipment, a barcode scanner in continuous use, biometric approvals: here the browser's scope is frequently not enough.
Work without a connection
When jobs are recorded for hours without a network and reconciled later, you need local data storage that goes beyond a cache.
The application is the product
When use, subscription or purchase happen inside the program and the platform store is the intended sales channel, there is hardly a way past an app.
The test question is simple: does the benefit of the application carry on while nobody is looking? Then an app is plausible. If everything happens within one visit - look, fill in, send, put away - the website carries it. For most firms the answer is clear, and then the app is not progress but a second project beside the first. Anyone weighing a social network profile instead of an app will find that comparison in own website or social media profile.
An app asks for a decision before the first benefit. A tile appears after the benefit was already there.
The bill over three years
There are no dependable market prices for app development in a form that could be quoted here - the ranges run from side-job work to corporate budget and say little about a single project.
What can be named cleanly, though, are the items that arise and how often they return. That is what decides the question, not a figure from an industry survey.
A native app has three cost blocks a website does not have: the second platform version, the review before every release, and the follow-up work when the platforms change their requirements. The third block is the uncomfortable one, because it arrives without any prompting from your own side: an app that is left untouched for two years as a rule disappears from the platform store at some point. A website left untouched for two years stays reachable - outdated in content perhaps, but online.
Scroll table sideways
| Item | Native app | Installable website |
|---|---|---|
| Creation | Two versions, each with its own tool chain | One version, the same one as the website |
| Release | Account with the platform operator, review before every version | Deployment like any other change |
| Content upkeep | Through an interface, otherwise a new version | In the same editorial path as the pages |
| Platform changes | Follow up, otherwise withdrawal from the store | Older browser versions stay usable as a rule |
| Findability | Store listing, separate from the website | Part of the visibility you already have |
| End of use | Uninstall, the icon disappears | Drag the tile away, the address remains |
If you want to go both routes anyway, mind the order: first build the website so that it carries on the phone, then measure what actually happens there - and only afterwards decide whether an app closes a gap you can name. The reverse order leads to a program whose purpose is looked for after the fact. The basic route decision before all of this is covered in builder, agency or AI compared.
An installable website in six steps
The path is short and can be done in one go if the website is being reworked anyway. The order matters: first it has to be clear which address should open when the tile is tapped, then come icon and description, and the caching comes last of all.
- Set the start address: the home page is not right in every case. For a firm with appointments the appointment page is often the better entry, for a practice the page with consulting hours and the emergency number.
- Create the icon set: square at 192 and 512 pixels, plus a version with a margin for round masks. The motif should stay recognisable at the small tile size - wordmarks are mostly unreadable there.
- Write and link the manifest: six fields are enough to start -
name,short_name,icons,display,start_url,scope. The short name should be twelve characters at most, otherwise the device truncates it. - Set the colours:
theme_colortints the system bar,background_colorthe moment between the tap and the first content. Both should match the website, otherwise a foreign surface flashes up at launch. - Set up the cache: a lean service worker for the shell page, the fonts and the pages visited last. Less is better here, because whatever is cached has to be refreshed again as well.
- Test on real devices: an older phone on a throttled connection says more than a new machine in the office. Check the tile, the short name, the splash image and the first screen after the tap.
After that a second look at the pages reached from the tile is worthwhile. A start address pointing at an overloaded home page gives away the advantage. A short entry with the three or four actions that count on the phone makes sense: call, appointment, enquiry, directions. How a form is built that does not get abandoned there is covered in turning visitors into enquiries. For buildings with two audiences, owners and tenants, the look into property management: separating owners and tenants is worth adding.
Two things you do not change afterwards
scope and the start address belong settled before release. Whoever moves them later breaks the tiles already sitting on home screens - they then point at an address that no longer exists. And do not push the install: a notice bar that covers half the screen on the first visit costs more enquiries than the tile brings in.How you notice it is working
The tile is not an end in itself, and it can be measured. Because the start address is freely chosen, it can carry an addition - in the example above ?source=homescreen.
Every visit through the tile is thereby distinguishable from a visit through search, without collecting additional data about the person. Six values are worth a look.
- Visits carrying the home screen addition per week: the number of people actually using the tile
- Share of returning visitors among those visits compared with the rest of the traffic
- Time to the first visible content on a throttled connection, with and without the cache
- Enquiries sent and appointments booked per hundred visits, split by entry route
- Share of visits from the phone overall: the ratio that sets the priorities
- Exits on the start address: shows whether the tile leads to the fitting page
Two to three months of observation are enough for a verdict. If the share of tile visits stays small, that is no argument against the website - it only means the customers reach you another way, mostly through search and a map service. Then the lever sits there, and an app would have changed little about it. If the share rises, the firm has gained a channel without ongoing platform costs. How opening hours stay current in either case is shown in keeping opening hours and availability current.
Five mistakes that devalue the tile
The technique is manageable, the mistakes repeat themselves anyway. All five can be checked in half an hour, and all five only show up once somebody really uses the tile.
- Short name too long: the device truncates it and a syllable sits under the tile. Twelve characters are a usable upper limit.
- Icon with type in it: what works on a letterhead is often a grey smudge at tile size. Reduce it to the mark or set a single letter.
- Start address on the home page: whoever taps the tile as a rule wants to settle one thing and not navigate through a menu.
- Cache without expiry: outdated prices or opening hours that stubbornly persist are more annoying than a slow page. Every cached file needs a rule for when it is refreshed.
- Install banner on the first visit: the prompt arrives before anybody knows whether the page helps. It belongs where the benefit has already been visible.
Whoever clears these five points has turned the website into a tool that sits on the customer's phone - without a second project, without a review loop and without a second place where prices have to be maintained. For firms with recurring matters that is often the whole difference: service forms for existing customers shows what such paths look like, and how a practice maps appointments and fees on the phone is covered in veterinary practice: appointments and fees.
display: standalone the page starts without an address bar in a window of its own. That is the normal case: 78 percent (Web Almanac) of the analysed manifests set exactly this value. The tile carries your icon, the task switcher shows your name.?source=homescreen, and every visit through the tile is thereby distinguishable from other entries, without additional data about the person. After two to three months you can say whether the route is being used. Accessibility belongs in the same check - the framework for it is set out in accessible websites under the Accessibility Act.