One of the common questions we’ve gotten since launching is why we chose to begin life as a progressive web app. It’s a great question. To explain our approach, Jeremy Jones, Engineering Lead, wrote-up the following piece.
Hi there! There are two parts to the answer: the business and technical strategic reasoning. I’m going to focus on the technical strategy. To be clear, they’re interrelated. At the moment, our business exists as a rapidly testable hypothesis followed by equally rapid iteration. Our bottom line conclusion was that by building a Progressive Web App, we’re best able to deliver on these requirements. Here’s why.
First, web technologies continue to improve and the gap between what’s possible with web and native is closing. Today, we’re able to deliver an app that is installable to the home screen, appearing alongside other native apps. And like a native app, we can deliver custom icons, splash screens and accent colors. We can control chrome and go edge-to-edge. We can persist data locally on the device using Cache Storage and IndexedDB, and combine with a Service Worker to provide an offline-first experience. We can access device capabilities such as media capture, multitouch, geolocation, and more. In fact, the first release of majr takes advantage of many of these features today.
Second, the web is universal. It remains the closest way for us to write code once and it run anywhere. iPhone, Android, Windows 98, Chromebook - it should work. To build/test/scale rapidly while maximizing reach, the web remains the most compelling option.
Third, the speed of development and release is faster. With a native app, we’d have to maintain iOS, Android and a responsive web and/or a desktop experience. That’s ~3x the effort. Also, native apps come with their own challenges: app content isn’t indexed by search engines, deep linking and ‘seeing’ into an app is challenging and the app store review process is a bottleneck for Continuous Delivery. For a startup with constrained time and money, web wins.
With this being said, we’ve also worked hard to forward optimize for native when it comes time. We’ve implemented a streamlined design and development flow supported by a standardized design system. Our UI is declarative, composable and built with reusable components that will translate efficiently to native views. Our backend consists of independently scalable functions exposed via an API built to support many types of endpoints, including web and mobile. While we’re not starting on native, we can certainly head there when we’re ready.
A PWA allows us to deliver a near-native experience to our early users while keeping costs down and development speeds up. We feel this will allow us to build and test our hypothesis quickly, leading to a better return when we do build native down the road.