Progressive Web App Development Company

Progressive Web App Development

A progressive web app installs from the browser, works offline, and sends push notifications, one codebase that covers every platform without a separate iOS or Android team. For many businesses, that is the right call. For others, native wins on hardware access or App Store distribution.
RaftLabs builds both PWAs and native apps. We scope your use case first and tell you which architecture actually fits, including when a PWA would cost you less without giving anything up, and when native is worth the extra build.

See our work

Offline-first architecture using Service Workers, IndexedDB, and background sync so the app keeps working without a network connection
Web Push notifications via the Push API and VAPID keys, with opt-in flows designed to get permission rather than lose it
App shell architecture with code splitting and lazy loading so the installed app opens in under two seconds on repeat visits
Web App Manifest configured for every platform, including maskable icons for Android adaptive launchers and legacy splash images for iOS

Recent outcomes

Voice AI · Research

Text-based interviews converted to automated phone calls

6× deeper insights

AI Automation · Ops

Manual invoice OCR across 40+ gas stations

20k+ txns day one

Loyalty · Retail

SuperValu & Centra loyalty platform with receipt validation

1,062 users in 4 weeks

SaaS · Logistics

Multi-carrier shipping hub for Indonesian eCommerce

2,000+ shipments yr 1

4.9 / 5 on ClutchSee all work

Recognition

Sound familiar?

Paying for separate iOS and Android teams to build the same customer-facing workflow on two codebases?
Mobile site that loads fine in the browser but can't be installed, can't push a notification, and stops working when the network drops?

In short

Progressive web app development is the practice of building a web application that installs to a user's home screen, works offline, and sends push notifications, all without an App Store submission. PWAs use three browser primitives: a Web App Manifest (tells the browser the app is installable), a Service Worker (intercepts network requests and serves cached responses offline), and IndexedDB (stores structured data on the device). What PWAs cannot do vs native: full hardware API access on iOS, reliable background sync on Safari, and App Store distribution for consumer discovery. RaftLabs builds PWAs starting from $15,000 to $40,000 for a focused build, and $40,000 to $80,000 for complex offline-sync or native-replacement projects. We also build native apps and help you decide which fits.

Trusted by

Two native codebases for the same customer workflow is a cost, not a feature

Most businesses building a customer-facing mobile experience default to native iOS and native Android without asking if that's actually required. Two teams, two review cycles, two sets of bugs, two deployments every time you ship a change. For some products, that overhead is justified. For many others, a PWA covers the same ground at a fraction of the cost.

A PWA installs from the browser, works offline, sends push notifications, and loads in under two seconds on a repeat visit. It is not a compromise. It is a different architecture with specific tradeoffs, and those tradeoffs favour the majority of B2B and customer-facing use cases where users are on a phone but don't need the full hardware layer.

The one thing that changes the answer: iOS still has gaps in push and background sync. Some hardware APIs aren't exposed to web apps. For products where those gaps are blocking, native wins. We scope your specific requirements before recommending either, so you aren't paying for a build that doesn't fit the problem.

Capabilities

What we build

Offline-first architecture

Web apps designed from the data layer up to work without a network connection, not as an afterthought bolted on after the fact. IndexedDB is the local store for structured application data, accessed via a typed wrapper like Dexie or the idb library so schema versions are managed and queries stay readable. The Cache API handles HTTP responses and static assets. The Service Worker sits as the network layer between the app and the server, serving cached responses when offline and queuing outbound requests for when connectivity returns.

Sync architecture is scoped during discovery, before any code is written, because the right approach depends on your data model. Last-write-wins is simple and works when one user is editing one record. Operational transform or CRDT-based sync preserves all edits when multiple users work offline simultaneously on the same records. We scope which model fits your use case and design the conflict resolution logic before the first sprint, not after a user reports data loss. Background Sync queues failed mutations and replays them when the network returns. Users see an explicit sync status in the UI so they know whether their edits have reached the server.

Push notification systems

Web Push notifications built on the Push API and VAPID (Voluntary Application Server Identification) keys, the standard for sending push across Chrome, Edge, Firefox, and iOS Safari 16.4+ on home-screen-installed PWAs. Permission flows designed around the moment users actually want notifications, not a prompt on first load that gets dismissed before they've seen the product. We test opt-in rates across prompt placements and timing before settling on the final flow.

Server-side push delivery via a Node, Go, or Python push service with VAPID key management and subscription storage scoped per user. Notification triggers built from your business events: a new order, a support reply, a document ready for review, a field service job assigned, a SLA about to breach. Delivery tracking and failed-delivery retry with exponential backoff. We document the iOS caveat in plain language during scoping: push only works on iOS for PWAs the user has added to the home screen, and only on iOS 16.4+. If your user base includes older iOS devices and push is mission-critical, we flag it and recommend a fallback channel or a native iOS app before you sign anything.

App shell architecture

App shell architecture separates the static application frame, navigation, skeleton screens, and layout, from the dynamic data that fills it. The shell is cached by the Service Worker on first visit and served from cache on every subsequent visit, so the app opens in under two seconds regardless of network conditions. Dynamic content loads into the shell after it appears, so users see a fast, responsive interface rather than a blank screen while the network is busy.

Code splitting at the route level keeps the initial bundle small. Route-level lazy loading defers page code until the user navigates to that route. Critical CSS inlined into the HTML document eliminates render-blocking stylesheets. Workbox handles the Service Worker lifecycle, including registration, activation, version skew, the claim and skipWaiting patterns, and cache cleanup so old cached files don't accumulate on users' devices. Lighthouse performance audit at 90+ before we ship, because that score reflects real-world experience on mid-range Android hardware, not just a fast desktop connection.

PWA installation and onboarding

Web App Manifest configured correctly for every platform. The display mode set to standalone for most apps, fullscreen for media experiences, minimal-ui for apps that need browser chrome visible. Icon set covering every required size from 48 to 512 pixels, maskable icons for Android adaptive launcher icons that respect system-level icon shapes (circle, rounded square, squircle), and legacy apple-touch-icon tags for iOS. Splash screens configured per iOS device resolution using the apple-touch-startup-image link tags that iOS still requires.

Install prompt UI that captures the beforeinstallprompt event on Chromium-based browsers and surfaces a custom install call-to-action at the right moment in the user journey, not immediately on landing. iOS Safari doesn't fire beforeinstallprompt, so we surface a custom in-app instruction for iOS users on first visit with a clear visual guide to Add to Home Screen. The installed PWA on iOS doesn't share cookies or storage with Safari, which affects authentication. We handle that explicitly in the auth layer so users aren't asked to log in twice. Lighthouse PWA installability audit passing before launch because a failing audit means the install prompt never fires on Chromium browsers.

Web API hardware access

Modern browsers expose a growing set of hardware APIs that let PWAs do things that used to require a native app. Camera and microphone access via the MediaDevices API for document scanning, barcode reading, video calls, and photo capture, no App Store download required. Geolocation via the Geolocation API for location-aware features, field service job routing, and location-tagged submissions. Device orientation and accelerometer data via the DeviceOrientation and DeviceMotion events for fitness apps and spatial experiences. Bluetooth (Web Bluetooth) for connecting to peripherals like scanners, printers, and IoT sensors from within the browser, currently supported in Chrome and Edge.

We scope which Web APIs cover your use case during discovery and document the platform gaps clearly. Web Bluetooth is not available on iOS. Web NFC is Chrome Android only. Some APIs require the device to be on HTTPS and the feature flag to be user-granted. For any hardware requirement we can't cover with Web APIs, we tell you in discovery and recommend either a React Native or native build for that specific platform rather than a workaround that will frustrate users.

Performance and Core Web Vitals

Performance is not a post-launch task. Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1 are built into the architecture from the first sprint, not fixed in a final audit pass. We target Lighthouse scores of 90+ across Performance, Accessibility, Best Practices, SEO, and PWA before shipping.

Concrete techniques: image delivery via a CDN with WebP/AVIF format negotiation and correct sizes attributes so browsers download the right resolution. Font loading with font-display: swap and preloaded critical weights. Third-party script loading deferred until after the main thread is free. Bundle analysis at every sprint to catch dependency bloat before it ships. React component code splitting at the route and feature level using dynamic imports. Service Worker pre-fetching likely next pages so navigation feels instant after the initial load. HTTP/2 or HTTP/3 delivery for parallel asset loading. We run performance tests on real mid-range Android hardware, not just a MacBook on a fast office connection, because that's what your users are actually on.

Paying for two native apps when one PWA would cover both?

Tell us your app use case, who uses it, and what it needs to do offline. We'll scope the PWA, compare it against native, and give you a fixed cost before you commit to anything.

Talk about your app

Related services

How it works

From first call to shipped product: how every build runs.

The same four steps on every engagement. A 6-week voice AI deployment runs the same shape as a 16-week enterprise build.

Week 1
01
Discover
We spend the first week understanding the problem, not presenting a solution. Discovery session, interviews with the people closest to the work, workflow mapping, and a technical audit of what you already have. You leave knowing exactly what's broken and why previous attempts didn't fix it.
Weeks 2–3
02
Design
Low-fidelity wireframes before any code is written. You see the product before we build it. Scope, timeline, and fixed price locked at this stage. No surprises after work starts.
Weeks 4–12
03
Build
Bi-weekly agile sprints. Weekly progress calls. Direct access to the team and project management tools. Working software at the end of every sprint. Not a big-bang delivery at the finish line.
Weeks 12–16
04
Ship
Production deployment, QA sign-off, load testing, and team handover. You own the full codebase from day one. We stay on for post-launch iteration and support. Nothing gets thrown over the wall.

Frequently asked questions

: A progressive web app is a website that browsers treat as an installable app when the right conditions are met. A Web App Manifest tells the browser the site is installable. A Service Worker intercepts network requests and can serve cached responses when the network is unavailable. IndexedDB stores structured application data on the device. The Web Push API delivers push notifications. When a user visits on Android Chrome or a Chromium browser, a prompt appears to add the app to the home screen. On iOS Safari, the user taps Share and selects Add to Home Screen. Once installed, the app runs in its own window without browser UI, loads from cache on repeat visits, and behaves like a native app for most everyday workflows.
: Build a PWA when you want one codebase across iOS, Android, and desktop, you don't need deep OS integration, and you can accept the platform gaps browsers impose on installed web apps. PWAs install to the home screen, work offline, send push notifications on supported platforms, and ship updates instantly without store review. Build a native app when you need full access to platform APIs that browsers don't expose, when push notifications are mission-critical and iOS limitations are not acceptable, when App Store presence is part of the product's discoverability strategy, or when you need integration with Apple Pay, HealthKit, ARKit, or similar platform-only frameworks. RaftLabs builds both and will tell you in scoping which one actually fits your use case.
: Yes, if it's designed for it from the start. Offline support in a PWA is built on three things. The Service Worker intercepts network requests and returns cached responses when no network is available. The Cache API stores HTTP responses and static assets. IndexedDB stores structured application data on the device so the app can keep functioning with no connectivity. When the network returns, a sync layer reconciles local changes with the server. We design the conflict resolution logic during discovery because offline sync shapes the data model from the beginning. Adding offline support to an app that was not designed for it is harder than building it in from the start.
: Yes, with conditions. Apple added Web Push support to iOS Safari in iOS 16.4, released in March 2023. Web Push only works for PWAs the user has added to the home screen; it does not work for the same site accessed as a browser tab. Older iOS versions have no web push support. On Android and desktop browsers, web push works reliably via the Push API with VAPID keys. If your audience skews toward older iOS devices, or if push delivery is mission-critical, we flag this in scoping and discuss fallback channels: SMS, email, or a native iOS app for the iOS audience.
: A focused PWA, core workflow, offline support, installable manifest, and push notifications on supported platforms, typically runs $15,000 to $40,000. PWAs that replace a native app or that need complex offline sync with conflict resolution run $40,000 to $80,000. Migration from an existing web app to PWA status, adding the Service Worker, manifest, install prompt, and offline layer to an existing app, usually runs $15,000 to $35,000 depending on how the existing app is structured. We scope every project before pricing and give you a fixed cost.
: A focused PWA with defined scope ships in 8 to 14 weeks. That covers discovery and architecture, design and front-end build, Service Worker and offline layer, push notification system, QA on real devices, and Lighthouse audit to 90+ before launch. Larger builds with complex offline sync, multi-role workflows, or migration from an existing app run 14 to 20 weeks. We give you a timeline before the project starts, not a range we adjust as we go.
: Google Play accepts PWAs packaged via Trusted Web Activity (TWA), which is a Chromium browser wrapper that runs your PWA inside a Play Store-listed app. The experience is identical to a native install. Apple's App Store does not accept PWAs as-is. To distribute via the App Store, you would need a native shell app, at which point the effort overlaps with a native build. If App Store distribution on iOS is a hard requirement, we recommend a native iOS app rather than a workaround. We'll say that during scoping, not after the build is underway.

Work with us

Tell us what you need. We'll tell you what it would take.

We scope Progressive Web App Development in 30 minutes. You walk away with a clear cost, timeline, and approach. No commitment required.

Scope and cost agreed before work starts. No surprises. No obligation.
Working prototype within 3 weeks of kickoff.
Pay by milestone. You see progress before each invoice.
60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
All conversations are NDA-protected.