Progressive Web App Development

What a progressive web app is, in practical terms

A progressive web app is a website built to behave like an app. It has a web app manifest that gives it a name, an icon and a full screen launch, a service worker that caches files and data so it opens offline, and access to the device features browsers expose, such as the camera, location and notifications. Users install it from the browser and open it from the home screen like any other app.

The appeal is reach and speed. There is one codebase, it runs on iPhone, Android, laptops and desktop computers, and you can ship a fix in the afternoon without waiting on store review. Tepia sees PWAs fit best for B2B ordering portals, internal operations tools, field forms used on mixed personal devices, and customer portals people visit occasionally and would never download an app for.

A PWA is still a real software project. It needs the same backend, authentication, testing and accessibility work as a native app, and Tepia scopes it with the same discipline. What you skip is store packaging and review, not engineering.

PWA, native and where each platform stands

The iPhone column decides most projects. If your users are mostly on iPhone and you need Bluetooth hardware, background location or deep OS integration, Tepia will recommend native or a cross platform app instead. Our native app vs progressive web app comparison walks through that decision in detail.

Where a PWA is the smarter first build

• B2B ordering and reordering for customers who order from a desktop at the office and a phone in the stockroom; see wholesale ordering apps.
• Internal tools used by staff on personal phones, where requiring everyone to install a managed app is hard to enforce.
• Occasional use portals such as warranty registration, service history or event check in, where nobody wants another download.
• Validating a product before investing in store apps, since a PWA can test demand with real users quickly.
• Audiences on older Android devices where a small install footprint and low storage use matter.

A PWA is a weaker choice for consumer apps that depend on store discovery, games, apps with heavy background work, and anything that must pass App Store review as a native product. Wrapping a PWA in a shell to get into the App Store often runs into Guideline 4.2 on minimum functionality. Tepia says so early rather than build something the stores will reject.

For many clients the honest answer is both, in sequence: a PWA first to serve customers on every device, followed by a native or cross platform app once usage shows which features deserve deeper device access. Tepia designs the API so the second step reuses everything the first one built.

Engineering a PWA that holds up offline

Offline support is where PWAs succeed or quietly fail. Tepia designs it feature by feature:

• Caching strategy: the app shell is precached, catalog data uses stale while revalidate, and account data always checks the network first.
• Local data: IndexedDB stores records and an outbox of changes, replayed in order when the connection returns. Because Safari lacks background sync, Tepia replays the outbox whenever the app regains focus or connectivity.
• Storage limits: browsers can evict data under storage pressure, so Tepia requests persistent storage where supported and never treats the device as the only copy.
• Updates: a new service worker waits until the user is ready, with a clear refresh prompt, so nobody loses a half filled form.
• Performance: code splitting, image optimization and Lighthouse performance checks in the build pipeline keep first load fast on mobile networks.

Our offline first app development page covers sync and conflict handling across web and native, and custom web application development covers the wider web platform work.

How Tepia approaches progressive web app development

1. Discovery: user interviews, a device and browser survey of your actual users, and a system investigation of the APIs and back office systems the app connects to. Deliverables are an Investigation Summary that includes a feature by browser support check, an Interview Summary and User Stories.
2. Design: a questionnaire, moodboards, style guide and responsive wireframes from phone to desktop, plus designs for the install prompt, offline states and update notices.
3. Development and Testing: React and TypeScript on the front end with a Node.js, .NET or Python backend, Alpha and Beta releases on real iPhones and Android phones, and test plans covering offline use, installation and WCAG 2.1 AA accessibility.
4. Training: sessions showing staff and customers how to install and use the app, built from user story scenarios.
5. Launch: data migration from spreadsheets or an old portal, a transition plan from the old system, and support reps during rollout.
6. Support: browser updates, issue resolution, bug tracking and feature requests, shipped continuously.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month. If the PWA later needs to become a store app, the backend and much of the design carry over. See our process, our work, or talk to Tepia.

Frequently asked questions