Build a progressive web app in one week: 6 step developer checklist

A progressive web app is a website built with a service worker, a web app manifest and HTTPS so it can be installed, work offline and feel like a native app without leaving the browser. It matters because you write one codebase and get near-app-store capability across desktop, Android and (with caveats) iOS. The rest of this guide walks through the technical ingredients, the build steps, the trade-offs, and where a PWA genuinely beats a native build.

TL;DR:

PWAs rely on a web app manifest, service worker, and HTTPS to enable offline functionality and installability across multiple platforms.

They can be built on existing websites without a complete rewrite by adding fundamental files and registering a service worker.

Browser support is strong on Chrome, Edge, and Android, but iOS Safari limits background sync and push notifications, requiring feature detection.

Using cache-first for static assets and network-first for dynamic content ensures optimal performance and freshness, with cache versioning to prevent stale data.

For most small business needs, hiring an agency to build and maintain a PWA offers faster deployment, better security, and ongoing optimisation than in-house development.

TTOY Digital

Build A Better Online Experience

TTOY Digital creates mobile-first websites and bespoke web applications that help small businesses turn online visitors into customers.

Explore TTOY Digital

How does a PWA compare to a website or a native app?
What are the core technical ingredients of a PWA?
How do you build a minimal, installable PWA?
What makes a PWA installable in the browser?
Which offline and caching strategy should you use?
Where do browser support and PWA limitations stand?
What benefits does a PWA actually deliver?
What do real PWA examples look like?
How do you deploy and test a PWA properly?
Where can you learn more about building PWAs?
Should a small business build a PWA in-house or hire an agency?
Why TTOY Digital for your next PWA build
Sources
FAQ

How does a PWA compare to a website or a native app?

Think of a PWA as sitting on a spectrum. A plain website has reach (anyone with a link can open it) but limited capability (no offline mode, no home screen icon, no push notifications). A native app has capability but limited reach, since someone has to find it in a store, download it, and accept the update cycle. A progressive web app tries to grab both ends: the same URL works for a first-time visitor and a returning user who has installed it to their home screen.

The principle behind this is called progressive enhancement: build a functional core experience for every browser, then layer on richer features for browsers that support them. One codebase, deployed once, running everywhere.

Typical use cases include:

Retail sites wanting a fast, installable mobile checkout
Content or news apps needing reliable offline reading
Booking and service tools where repeat visits matter more than app-store discovery
Internal business tools where deploying updates instantly beats waiting on app review

What are the core technical ingredients of a PWA?

Three things have to be in place before a browser will treat your site as a progressive web application: a web app manifest, a service worker, and HTTPS.

The manifest.json file tells the browser how your app should behave once installed. At minimum it needs a name, a set of icons, a start_url, and a display mode (usually standalone, which strips away browser chrome so it looks like a real app). MDN’s PWA documentation covers the full manifest schema if you want every optional field.

The service worker is a background script that intercepts network requests, decides what to cache, and can wake up later to handle push notifications or background sync, even when your site tab is closed. Microsoft Learn’s PWA overview confirms service workers are what enable offline operation and the caching that makes repeat visits fast.

HTTPS is non-negotiable. Service workers simply refuse to register over plain HTTP, because they have enough power over network traffic that browsers treat it as a security risk.

Manifest: identity, icons, launch behaviour
Service worker: caching, fetch interception, push, background sync
HTTPS: mandatory transport security for service worker registration.

Pro Tip: Register your service worker from the root of your site, not a subfolder. Its scope is set by file location, so a service worker sitting in /scripts/sw.js only controls pages under /scripts/ unless you explicitly widen its scope, a classic “works on my machine” bug that only shows up in production.

How do you build a minimal, installable PWA?

Start with a working website. Nothing here demands a framework rewrite.

Scaffold or use your existing HTML, CSS and JavaScript site.
Serve it locally over http://localhost (browsers treat localhost as a secure context, so service workers register fine during development).
Write and register a service worker file.
Implement a caching strategy inside it (covered in the next section).
Add your manifest.json and link it from the <head> of every page.
Test installability, then move to a real HTTPS host before launch.

A minimal manifest link and registration pattern looks like this:

<link rel="manifest" href="/manifest.json">

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Checklist before you call it done:

manifest.json present and linked, with at least a 192px and 512px icon
Service worker file registered at the correct scope
HTTPS in place on the live domain (Let’s Encrypt covers this for free)
Site tested with the browser’s DevTools application panel

What makes a PWA installable in the browser?

Browsers decide whether to offer an install prompt based on a short checklist: a valid manifest with the required fields, a registered service worker, and delivery over a secure origin. Meet those and Chrome or Edge will typically fire the install prompt automatically.

You don’t have to rely on the browser’s default prompt, though. Listen for the beforeinstallprompt event, store it, and trigger it later from your own branded “Install” button when the moment suits the user, not the browser’s timing. OneSignal’s PWA breakdown makes an important point here: installation is an enhancement, not a requirement, so the non-installed experience still needs to work well on its own.

Manifest + service worker + HTTPS triggers the native prompt
beforeinstallprompt lets you build a custom, better-timed install button
Packaging through a tool like PWABuilder is worth it only if app-store discovery genuinely adds reach for your audience

Pro Tip: Don’t show your install button on first visit. Wait until someone has completed a meaningful action, like adding an item to a basket, so the prompt feels earned rather than pushy.

Which offline and caching strategy should you use?

Two patterns cover most needs. Cache-first serves files straight from the cache and only hits the network if nothing is cached, ideal for icons, fonts and app shell files that rarely change. Network-first tries the live network first and falls back to cache on failure, better suited to content that updates often, like prices or articles.

Whichever pattern you pick, version your cache names (my-app-cache-v2) and clean up old caches during the service worker’s activation step, so a deploy doesn’t leave users stuck with stale UI, a pattern MDN documents in detail.

Cache-first: static assets, app shell, icons
Network-first: prices, feeds, anything time-sensitive
Version and clean caches on every deploy to avoid stale content
Background sync queues failed requests (like a form submission) and retries once connectivity returns

Where do browser support and PWA limitations stand?

Chrome, Edge and most Android browsers support the full stack: service workers, manifests, push notifications, background sync. iOS Safari is the sticking point. Apple has historically limited background sync and push support, and installed PWAs on iOS behave a little differently from their Android counterparts.

Chrome and Edge: full support, automatic install prompts
Android browsers generally: strong support across the board
iOS Safari: install via “Add to Home Screen” works, but push and background features remain restricted

Build with progressive enhancement in mind: feature-detect (if ('serviceWorker' in navigator)) rather than assuming support, so the site still functions cleanly for visitors on a limited browser.

What benefits does a PWA actually deliver?

The gains show up in three places: speed, engagement and cost. Faster repeat loads from caching translate into fewer abandoned sessions, and businesses that have adopted PWAs report measurable jumps in conversion and engagement after the switch, alongside increases in add-to-home-screen actions.

One codebase instead of separate iOS and Android builds cuts ongoing maintenance cost
Faster load times feed directly into better conversion rates
No app-store approval delay when you ship a fix or new feature
Best suited to retail, booking, content and internal tools with frequent repeat visits

What do real PWA examples look like?

The scale of PWA adoption ranges from global retailers to a single-location trades business. Large brands cited by web.dev and Microsoft Learn report faster load times and higher engagement after rebuilding as PWAs, largely down to caching removing the repeat-visit wait, with measurable performance gains reported. Mid-market retailers have used the same install-and-offline pattern to keep a checkout usable on patchy mobile signal.

Picture a small trades business with a paper price list and a website nobody checks twice. A PWA version gives them an offline catalogue customers can browse without signal, a faster mobile checkout, and a home-screen icon that keeps the business one tap away instead of forgotten in a browser tab.

See MDN’s installability guide for worked examples
web.dev’s PWA learning path walks through full demos

How do you deploy and test a PWA properly?

Host on a provider that supports HTTPS out of the box; Let’s Encrypt certificates cover this for free on most modern hosting stacks. Before launch, run a Lighthouse audit in Chrome DevTools. It checks your manifest, service worker registration and performance score, and flags exactly what’s missing against PWA criteria.

Confirm HTTPS is active on the live domain, not just staging
Run Lighthouse’s PWA audit and fix every flagged item
Watch for cache errors in production logs after each deploy
Roll out service worker changes gradually rather than to everyone at once, so a caching bug doesn’t lock out your whole audience at once

Where can you learn more about building PWAs?

For anything code-level, MDN’s Progressive web apps documentation is the most complete reference on manifests, service worker APIs and caching. web.dev’s PWA learning path and Microsoft Learn’s PWA guides both cover deployment and installability. Use Lighthouse and browser DevTools for testing, and PWABuilder if you need an app-store package.

Should a small business build a PWA in-house or hire an agency?

If your site needs little more than an offline catalogue and a manifest, a competent developer can do it in a week. Once you’re weighing push notifications, background sync, security hardening and ongoing monitoring, that’s the point where an agency’s deliverables (manifest, service worker, hosting, monitoring) start costing less than the hours you’d burn learning it yourself. Weigh the build cost against the maintenance you’ll carry afterwards.

Why TTOY Digital for your next PWA build

Why TTOY Digital for your next PWA build — overview diagram

If you’ve read this far and thought “that’s a lot to get right on top of running a business,” you’re not wrong. A specialist digital agency can build PWA-capable, mobile-first websites for small businesses as standard, so you get the offline catalogue, the install prompt, and the fast checkout without learning service worker scope rules yourself. They handle the manifest, the caching strategy, the HTTPS hosting and the ongoing monitoring that keeps it all working after launch, and pair it with local SEO so the app-like speed actually shows up in more searches finding you. If a competitor’s site loads instantly and yours doesn’t, that gap costs you customers every single day it stays open. Have a look at our custom web application development service and get in touch for a build assessment.

Sources

FAQ

What is a progressive web app?

A progressive web app is a website that uses a service worker, a web app manifest and HTTPS to become installable, work offline and behave like a native app while remaining a normal website for anyone who doesn’t install it.

Is the progressive web app still relevant in 2026?

Yes. Browser support for service workers, manifests and push notifications remains strong across Chrome, Edge and Android, and businesses continue to report engagement and conversion gains from PWA adoption, though iOS Safari still limits some background features.

What is an example of a progressive web app?

Large retailers and content platforms have rebuilt as PWAs to gain faster load times and offline reliability, and the same pattern works for a small business site adding an offline catalogue and a home-screen install option through a build like those TTOY Digital delivers.

Do I need a native app if I already have a PWA?

Not usually. A PWA covers offline access, push notifications and home-screen installation for most business use cases; native app-store packaging is only worth the extra complexity when store discovery specifically drives your audience.

Does a PWA help with SEO?

Yes, indirectly. Faster load times and reliable performance are ranking factors, and pairing a PWA build with local SEO work or an SEO audit helps that speed advantage actually convert into more search visibility.