Lumatara is now installable — why I built a PWA instead of a mobile app

There’s a version of this post where I smugly announce a native iOS app, a polished App Store listing, and a developer account that cost me $99/year just for the privilege. That’s not this post.

This post is about why I shipped a Progressive Web App instead — and why I think I’ll never need the native route.

---

I didn’t want to do mobile at all

Lumatara started as a single always-open browser tab. That was the entire design brief I gave myself: one tab to replace eight. A command center for my financial life, my calendar, my feeds, my tasks — sitting in a pinned Chrome window on my laptop.

Mobile wasn’t part of the plan. I’m a desktop-first person. I do real work on a laptop. I wasn’t building this for anyone else, so I didn’t need to optimise for use cases that weren’t mine.

That lasted about two weeks of actually using the app.

---

Then reality hit

Here’s what happened: I opened Lumatara one morning to check my portfolio before a meeting. The markets had moved overnight — US positions especially. I wanted that same glance on my phone, the way you’d check a weather widget before stepping outside. Quick. Ambient. No friction.

I reached for my phone and… nothing. A web app URL. A browser chrome. Not the same.

That’s when I admitted it to myself: I actually want this on my phone too. Not in a “let me build a startup” way. In a “this is my daily tool and I use my phone” way. The personal-use test I’d set for every feature — would I miss it if it disappeared? — applied to the mobile experience too.

---

Why not just build a native app?

I considered it. For about forty-eight hours.

Then I thought about what that actually means:

• A separate codebase (React Native or Flutter) that diverges from day one
• A review process I don’t control, with rejection risks for financial data features
• App Store guidelines that could force me to add in-app purchases for my own subscription
• A build pipeline I have to maintain in parallel with the web app
• Two sets of bugs. Two sets of updates.

I build Lumatara alone. The whole value proposition is that I move fast and ship things that are exactly right for how I work — not compromised by committee or platform rules. A native app would add a tax on every single feature I ship.

The web already has the APIs I need: offline caching, home screen installation, push notifications (where they matter), background sync. These aren’t approximations of native features anymore. They’re genuinely good.

---

What “PWA” actually means for Lumatara

I spent a few days optimising properly rather than bolting things on:

Install prompt — Lumatara now prompts you to add it to your home screen on first visit. On Android, it installs like a real app. On iOS, it’s an “Add to Home Screen” flow that’s not as slick, but it works. Once installed, there’s no browser chrome — full screen, icon on your home screen, it feels native.

Offline shell — The service worker caches the app shell, so Lumatara opens instantly even on a slow connection. Data still requires network, but you’re not staring at a blank screen.

Mobile layout — The dashboard reflows properly at phone widths. Nothing is pinched or overflowing. Portfolio cards, net worth numbers, the calendar strip — all of it works at 390px.

Viewport and touch targets — Buttons are properly sized. Scroll regions work the way you expect on a touchscreen. No accidental zoom on input focus.

---

The outcome I didn’t expect

After installing Lumatara as a PWA on my phone, I realised something: I don’t miss a native app at all.

My morning routine is now: pick up phone, open Lumatara from the home screen, check overnight portfolio movement, glance at the day’s calendar, mark one task done. That’s it. Thirty seconds. Then I put the phone down and open the laptop.

The app loads fast. It looks right. It works. Nobody reviewed it. I shipped it in a few days of focused work rather than months of platform wrangling.

---

A note on “progressive”

The word “progressive” in PWA is doing real work. It means the app is good on every surface — not degraded on mobile, not a mobile-only experience that ignores desktop. Lumatara was already good on desktop. Making it progressively better on mobile didn’t require burning the desktop experience down.

That’s the model I’ll keep: desktop-first, but mobile-capable. The single codebase gets better for every device I care about. No compromise, no fork.

---

Will I ever build a native app?

Honestly? I doubt it.

The gap between what a PWA can do and what a native app can do has narrowed to the point where the things in the gap are things I don’t personally need. Background location? No. Bluetooth hardware? No. Deep OS integration? Not for a finance and productivity dashboard.

The things I do need — fast load, offline shell, home screen presence, good mobile layout — all exist in the browser today.

If the day comes where I hit a wall that only a native app can solve, I’ll reconsider. But I’ll be building that native app to solve a specific problem, not as a default assumption that mobile means App Store.

For now: install Lumatara from your browser. Tap “Add to Home Screen.” Tell me if it breaks.

That’s the whole announcement.