A guide to hiring PWA developers
A progressive web app, or PWA, is a web app that uses a few browser features to act more like an installed app. Users can add it to their home screen, open it in its own window and keep using parts of it when the connection drops. A PWA developer is the person who builds and looks after those features. This guide explains what the role covers, how it differs from nearby roles and how to set up the work so the app is fast, reliable and easy to update. It suits a company that already has a website and wants it to feel more like an app, and a team that is planning a new product for mobile users.
What a PWA is made of
Three pieces make a site a PWA. The first is HTTPS, because the key features only work on secure pages. The second is a web app manifest, a small file that gives the app a name, icons, colors and a start page. The third is a service worker, a script that sits between the app and the network. It can store files and data on the device, answer requests when the user is offline and receive notifications. Around these sit the usual parts of a web app: screens, data, sign-in and a back end. The skill is in how the pieces work together over months of releases, not only on launch day.
What PWA developers work on
Some projects start from scratch and some add PWA features to a site that already exists. The first job is to decide what should work offline. A reading app might keep saved articles, a field tool might keep forms until the user is back in range, and a shop might show the catalog but ask for a connection at checkout. Then the developer writes the service worker, sets the cache rules, builds the install flow and tests the app on real devices. After launch they watch for errors, fix cache bugs and keep the app working as browsers change.
How this role differs from nearby roles
A web developer builds websites and web apps in general, and a JavaScript developer writes the code that makes pages interactive. A React developer works in one popular library. Native mobile work sits with Android developers and iOS developers. A PWA developer usually comes from the web side and adds the knowledge of service workers, offline data and install behavior. Use this page when the question is whether your web product should install, work offline or send notifications, and who can build it.
When a PWA is a good fit
- Your users open the product often and would like it one tap away on their phone.
- Many of them are on slow or unstable networks, or work in places with poor coverage.
- You want one team and one codebase for phones, tablets and computers.
- You want to ship changes quickly without waiting for a store review.
- You want to test a mobile product before you commit to separate native apps.
When another route may suit you better
A PWA is not right for every product. If your app needs close access to device hardware, runs heavy graphics or depends on being found in an app store, a native or cross-platform app may serve you better. If people use your site once and leave, install features add little. A good developer will say so early. Ask any candidate when they would advise against a PWA, because the answer shows how well they know the limits.
What to decide before you hire
- Which screens and actions must work offline, and which can ask for a connection.
- How fresh data must be, and what the user sees when it is out of date.
- Whether you want notifications, and what messages would actually help the user.
- Which browsers and devices your users have, so testing matches real life.
- Whether the app also needs a store listing.
Reading a PWA developer’s portfolio
Ask for live apps you can open on your own phone. Try adding one to the home screen, then switch to airplane mode and see what still works. Look at how it behaves after an update. A good portfolio includes a short note on the cache rules the developer chose and why. Be careful with a portfolio that shows only a Lighthouse score, because a score does not show whether the app is useful or whether updates reach users cleanly.
Interview questions to try
- Walk us through how a service worker handles a request. What can go wrong?
- How do you update a PWA so users do not get stuck on an old version?
- Which data would you keep on the device for our product, and which would you never store?
- How do you test install and offline behavior across different phones?
- Tell us about a PWA problem that only showed up after launch. How did you find it?
Listen for real examples with the mistakes included. Doubt anyone who says caching is simple.
Run a small paid build task
Give each finalist a short brief that matches your product. Good tasks include turning a small page into an installable app with an offline fallback, writing a cache plan for a screen you already have, or reviewing your current service worker and listing the risks. The time should be paid. Judge the plan for clarity, try the result on a real device and see how the person answers questions about updates.
Give them tools and a rhythm
Your developer needs the code repository, the hosting account and the project board, but nothing beyond that. The repository, domain and accounts should be registered to you. Early on, meet weekly and open the newest build together on a phone. Later a short written update each week and a demo every other week is enough, as long as the update follows the same shape each time.
Plan for life after launch
A PWA changes as browsers change, so plan for care after the first release. Decide who watches errors, who checks the app on new browser versions and how users hear about updates. Ask the developer to add basic tracking for installs and offline use, so you can see whether the features help. Keep a short list of ideas for the next version and add them one at a time.
Mistakes to avoid
- Caching everything without a plan to refresh it, so users see stale pages.
- Asking for notification permission on the first visit, before the user knows why.
- Testing only on a desktop browser and finding device problems after launch.
- Skipping documentation of the cache rules, which makes the next change risky.
- Handing the repository or hosting account to a contractor instead of keeping it in your name.
Need people to carry the product forward? Read about how to hire a web developer or a React developer, and see how hiring works on our pages.