You Don’t Need an App. You Might Need a Better Website.

The coffee order that became an app idea

Imagine a small roaster selling to households and local offices. A new buyer follows a link to choose a blend. A returning office manager wants last month’s order, with one extra bag and a new delivery address. Today, that manager emails the roaster, who looks up the old order and types the details into another system.

The owner pictures an app with a logo on the customer’s phone. But the useful improvement is more specific: let the manager find the previous order, edit it and review the current total. A website can provide that kind of account experience. Shopify, for example, documents customer accounts with order management, reordering, profile changes and saved checkout details. That is an available capability to investigate, not proof that this particular roaster’s setup already has it. [1] (opens in a new tab)

This distinction changes the brief. The project is no longer “build an app because regulars need convenience.” It is “make the second purchase easier, while keeping the first purchase straightforward.” Both journeys deserve a place in the design.

Your website can have more than pages

A web app is software you use through web technology. The label is less important than what a customer can finish: access a private account, upload information, make a booking or manage an order. A progressive web app, usually shortened to PWA, adds app-like behavior such as installation and selected offline features. Those capabilities have to be built and tested; changing the name of a website does not add them. [2] (opens in a new tab)

For the roaster, the first version might use the existing shop’s account tools and a clearer return-order route. It may need a small integration if customer records and order records live in different systems. A custom portal becomes a larger project when business buyers need several delivery locations, purchasing roles or approvals.

The difficult part is keeping the transaction accurate. Last month’s coffee might be unavailable. The new address may change delivery cost. A colleague may be ordering for a different branch. Show those differences before confirmation, and connect the final order to the same stock and fulfillment records staff actually use. A second screen with separate, stale information would add work.

Start by checking what the current platform already provides. Ask the builder to demonstrate the complete return-order journey with test data before quoting a replacement. A feature list that says “customer accounts” leaves a lot unanswered: who can see which orders, how sign-in works and what happens when something changes.

Plan for shared office devices too. Give customers a visible way to sign out, keep one business’s order history away from another and request only the details the purchase needs. An emailed link or a Home Screen icon should never be treated as permission to expose private account information.

An icon is useful. It is not the whole experience.

A customer may appreciate opening the roaster from their Home Screen. That does not automatically require an App Store product. Apple’s current iPhone guide explains how to add a website and enable Open as Web App. MDN documents installation options across platforms, including differences between browser-installed apps and shortcuts. Test the devices your customers use instead of promising one identical installation experience. [3] (opens in a new tab) [4] (opens in a new tab)

Notifications are a separate decision. WebKit’s documented iPhone and iPad support, introduced with version 16.4, applies to Home Screen web apps and requires a permission request prompted by user interaction. A customer must agree. A normal visit to the shop is not permission to send messages, and adding an icon is not a guarantee that someone will return. [5] (opens in a new tab)

For this business, a delivery update might be useful; a daily coffee promotion might be irritating. Decide what customers actually want to hear before choosing the channel. Keep essential information available in the account even if a notification is declined or missed.

Offline use also needs a precise promise. A PWA can keep selected resources on the device, but a saved copy can be out of date. Browsers can stop background workers; they are not an unrestricted, always-running process. MDN describes these tradeoffs rather than promising that every web feature works without a connection. [6] (opens in a new tab)

The roaster could let someone read saved brewing instructions offline. An order is different: seeing a cached bag of coffee is not evidence that it is still in stock or that payment succeeded. Keep a clear connection-required state for checkout unless a more complex, explicitly designed process is justified. Never let a reassuring screen get ahead of the business record.

When a separate app deserves the investment

A native app is built for a particular operating system, although development tools can share some work across platforms. It deserves serious consideration when the mobile experience is itself your product, or when a valuable, frequent task depends on device behavior your tested web version cannot deliver reliably. Frequent visits are a reason to investigate, not a verdict by themselves. [2] (opens in a new tab)

Ask for a small prototype of the decisive feature. If the proposal depends on a device connection, prolonged background work or a complex offline workflow, test that exact requirement on the intended phones. Compare it with the web alternative. This is more useful than assuming either “the web can do everything” or “anything advanced needs a native app.”

If the only difference is that the same pages sit inside an app wrapper, ask what the customer gains. Apple’s review guideline 4.2 expects useful functionality and an experience beyond a repackaged website. That is an App Store requirement, not a guarantee that any particular design will pass review. [7] (opens in a new tab)

Compare the whole ownership plan: design, account and payment connections, device testing, content updates, release work, support and future fixes. Reusing a website or using a cross-platform framework can reduce duplicated effort, but it does not remove those responsibilities. There is no honest universal price for this decision; a simple store and a complex customer portal are different scopes.

Buy the improvement you can observe

Before choosing a build, try three short journeys with representative customers using test orders: a first purchase from a shared link, a repeat purchase with a changed address, and a return visit when the previously bought item is unavailable. Watch where people hesitate or need staff help. Include a phone, keyboard navigation and enlarged text in the review.

Then compare a proposed version against the current one. Record whether the person finishes correctly, how long the task takes and how much help staff provide. Later, compare real repeat-order completion and support requests over similar trading periods. Small samples and seasonal changes limit what you can conclude; an increase in installed icons alone does not show that ordering improved.

For a first build, the roaster might choose a clearer mobile storefront plus account-based reordering. If customers then want a Home Screen shortcut, test that next. If a valuable unmet device requirement remains, the evidence for a native app becomes much stronger. These are stages you can evaluate, not a promise that every business should follow the same path.

The portfolio’s Kundan HQ project shows a storefront connected to inventory, customer and shipping workflows. It is a real example of a website doing operational work; it is not this coffee-roaster concept or a claim that every feature described here has already been built. The useful starting conversation is the same: what does your customer need to finish, and where does the information go afterward?

You may eventually choose an app. First, give the existing website a fair test of the job you wanted the app to do. For the office manager, a successful result is simple: the right coffee reaches the right office, and ordering it took less effort.