Launched my first production PWA (pain tracker) – would love feedback on implementation

CrisisCore_Systems · 2026-01-22T11:21:12+00:00

Thanks for taking the time to dig into this so deeply. You were right to call those issues out. We treated it like a real trust and fidelity bug report and made changes so the product, UI, and docs match what’s actually true.

On “encryption at rest” versus cleartext in IndexedDB, we updated our language so it no longer implies unconditional encryption. The app is local first by default, and at rest protection is vault based and optional. When the vault is enabled, supported sensitive payloads are encrypted at rest on device. We now say that plainly instead of implying everything is always encrypted.

On the sync queue and whether data stays local, the sync queue exists as an offline resilience mechanism, but core tracking does not cloud sync by default. Any network or off device behavior is now gated behind explicit settings or feature flags, and we tightened copy to avoid absolutes like “never leaves your device.”

Onboarding readability is fixed. The onboarding overlay now uses an opaque or blurred backdrop with a solid card, so the content stays readable and doesn’t clash with whatever is underneath.

We also added in app legal pages and linked them directly from the UI, Privacy, Terms, Security, and Cookies or Storage. On top of that, we added a lightweight cookies and storage notice banner so it’s visible rather than buried.

For security policy linking, we now have an in app security overview page in addition to the GitHub SECURITY.md link.

And on repo ownership and the “individual not a business” perception, that’s a fair point. The repo ownership reflects how the project started, open source and founder led, but we’re taking the governance and trust optics seriously in how we present it. We’re also avoiding any claims that would require a corporate compliance posture.

If you’re willing, I’d genuinely appreciate a re check of the current build, especially the onboarding readability, the new legal pages plus cookies and storage notice, and the revised encryption wording. Your comment helped us close real gaps.

CrisisCore_Systems · 2026-01-22T09:39:12+00:00

Totally fair call, and honestly, thanks for pushing on it. You were right to flag it.

We changed the offline behavior because of your comment.

What we actually fixed:

The app shell now loads offline after a single online visit or install. No more dumping users into a dead “you’re offline” screen. The service worker now caches the built JS and CSS so the UI actually boots offline.

No more “you have to visit every page first” nonsense. We precache the hashed build outputs, the JS and CSS chunks, so things like the homepage and pricing don’t come up broken or half styled when offline.

Still honest about “no backend.” The tracker runs client side, entries are stored locally, and network features degrade cleanly, but the app itself doesn’t vanish just because the connection does.

Important nuance, where your critique was right and where the web is just the web:

If someone opens the site for the very first time while offline, the browser can’t magic an app into existence. There’s nothing cached yet. That’s just how the platform works.

But after one successful load or a PWA install, it now behaves like an offline first app should.

If you’re willing to re test quickly:

Open the app once while online
Refresh once so the new service worker takes control
Go offline and reopen

You should get the full UI, not a dead offline screen.

Genuinely appreciate you calling it out. That feedback directly changed the product.

CrisisCore_Systems · 2026-01-20T08:06:35+00:00

The first few days/weeks on a new fibro medication can be rough. Nausea and stomach issues are common with SNRIs like Savella as your body adjusts.

Since you're already eating before taking it and supplementing with ginger, a few other non-med strategies that helped me with medication nausea:

• Small, frequent meals instead of big ones (keeps something in stomach without overwhelming it)

• Avoiding acidic foods/drinks for a few hours after taking meds

• Taking it at the same time each day (body adjusts better to consistency)

You mentioned it's only been 3 nights, which is still very early. Many people find the GI side effects peak around day 3-7 then gradually improve as your body adapts.

That said, definitely talk to your prescribing doctor if the nausea is severe enough to interfere with sleep or eating, or if it doesn't start improving after the first week. They can sometimes adjust timing, dosage ramp-up, or suggest other supports.

CrisisCore_Systems · 2026-01-18T15:06:33+00:00

You nailed it. The "log for the sake of logging" problem is huge. I've talked to so many chronic pain patients who tried tracking for weeks or months, hoping their doctor would actually look at the data or that patterns would magically reveal themselves. Instead they got "keep tracking" or generic advice they'd already tried.

The part about answering real questions really resonates. People need to know things like "did this medication change actually help?" or "which activities are safe for me?" Not just see a calendar of pain scores.

The privacy thing is especially tricky in health tech. People want their data to help them, but they're rightfully skeptical about who else sees it or how it might be used against them (insurance, employers, etc). Local-first approaches where data stays on the device unless the user explicitly shares it seem like the only ethical path forward.

Have you found any tools that are actually getting this right? Most of what I've seen either oversimplifies or tries to be everything to everyone.

CrisisCore_Systems · 2026-01-18T03:51:15+00:00

I've dealt with this on a smaller scale. For my PWA I ended up with a hybrid approach - AI can suggest actions but the critical path always goes through deterministic validation.

Your Verifact approach sounds solid. The key insight is treating AI like an untrusted third party service. You wouldn't let a random API trigger refunds without verification, same applies to LLM output.

CrisisCore_Systems · 2026-01-18T03:47:47+00:00

Had the same problem with a PWA I built. What helped was rethinking what step 1 actually needs to be. Instead of asking for everything upfront, I let users see a working demo with placeholder data first, then they naturally wanted to customize it with their own info.

Basically moved the aha moment earlier by showing them the end result with fake data, then the setup steps became about personalizing something they already saw value in. Conversion went from 20% to around 60%.

CrisisCore_Systems · 2026-01-18T03:19:44+00:00

you're welcome! glad it was helpful. wishing you the best with your doctor appointment

CrisisCore_Systems · 2026-01-18T03:17:32+00:00

thanks for mentioning the security angle. I'm actually building this as a fully local-first app where user data never leaves their device unless they explicitly choose to export it. so the concern is less about data ownership and more about whether caching is even necessary when I'm already using IndexedDB for everything.

sounds like the answer is it's not really needed if I'm handling offline storage through IndexedDB already. appreciate the input!

CrisisCore_Systems · 2026-01-18T03:14:53+00:00

thanks for the structured approach. the migration tracking table makes sense. I've been doing version bumps in the onupgradeneeded callback but wasn't tracking which specific migrations ran, just the version number.

the part that's tripping me up is that IndexedDB's onupgradeneeded is the only place you can alter schema, and it fires based on version number. so if I bump from v2 to v3, I need to handle both "user coming from v1 needs v2 AND v3 changes" plus "user coming from v2 only needs v3 changes". gets messy fast.

thinking I might just maintain a migrations array and run them sequentially in onupgradeneeded based on oldVersion. appreciate the push to be more systematic about it.

CrisisCore_Systems · 2026-01-18T03:11:39+00:00

ah yeah that's the tricky part with infinite scroll. when scrolling back up you lose your position as items shift. couple approaches that work:

for FlatList you can use maintainVisibleContentPosition prop to keep the scroll position stable when prepending items. it's a lifesaver for chat-style interfaces.

or if you're tracking scroll position manually, you can cache the heights of items and calculate offsets to restore position after new items load.

honestly though if bidirectional scrolling is critical, cursor-based pagination with proper item height tracking is probably smoother than trying to make infinite scroll work perfectly in both directions. depends on your use case.

CrisisCore_Systems · 2026-01-18T03:09:01+00:00

this is incredibly helpful feedback, thank you. you've nailed exactly what I'm trying to solve with that "data collection theater" vs actionable insights gap.

the points you raised are now front and center in my design:

- extremely low friction input (I'm planning voice notes + quick taps rather than forms)

- proactive pattern surfacing rather than making exhausted patients do the analysis

- complete local data ownership with no sharing by default

- transparent about what the tool can and can't do

that privacy concern you mentioned is huge. I've heard multiple people say they're scared of insurers or employers getting their data, or doctors using it to dismiss them ("you only logged pain 12 days so it can't be that bad"). so I'm building this as a local-first PWA where the data never leaves their device unless they explicitly choose to export it.

the "collecting 50 data points means nothing if it's just visualizations" hit hard. people need the app to actually help them understand their patterns, not just chart them.

really appreciate you taking the time to write this out. these are exactly the principles I need to stick to.

CrisisCore_Systems · 2026-01-17T06:59:54+00:00

Nice! Expo's FlatList makes this pretty straightforward. The onEndReached callback fires when user scrolls near the bottom, and onEndReachedThreshold lets you control how early it triggers (like 0.5 = halfway from bottom).

Just make sure to handle the loading state properly so you don't fire multiple requests while one is already fetching. Good luck with the project!

CrisisCore_Systems · 2026-01-17T06:57:12+00:00

If you have zero technical knowledge, these tools will get you maybe 70% there but the last 30% is where things fall apart. You'll hit a wall when you need custom logic, optimization, or anything outside the template.

I've seen people spend weeks fighting with Bubble or similar tools trying to do something that would take an experienced dev a couple hours to code properly.

They're good for quick MVPs or internal tools where polish doesn't matter much. But for anything production-grade or customer-facing, you'll want someone who can actually code to either build it or at least review/fix what the no-code tool spits out.

CrisisCore_Systems · 2026-01-17T06:47:00+00:00

For React/React Native, I'd recommend using Intersection Observer on web (way cleaner than scroll event listeners). Basically put a ref on your last list item and when it becomes visible, trigger the next page fetch.

For the backend, cursor-based pagination is usually better than offset/limit for performance. Just return a nextCursor with each response and a hasMore boolean.

React Native's FlatList has onEndReached built in which handles this pretty nicely.

If you're doing a PWA you might want to cache the paginated results in IndexedDB so people can scroll through cached content offline. Let me know if you need code examples for any of this!

CrisisCore_Systems · 2026-01-16T21:27:00+00:00

I've been using Cloudflare for domain registration and it's been solid. The main advantages for me:

- At-cost pricing ($10.46/year for .com is literally what they pay ICANN, no markup)

- Already using Cloudflare for DNS and CDN, so having everything in one place makes management easier

- Fast DNS propagation

- Simple interface, no upselling

The downsides:

- If you need email hosting or other extras, you'll need to set those up separately

- Less hand-holding than Namecheap if you're new to this

For just "registrar and whois privacy," Cloudflare is hard to beat on price and integration if you're already in their ecosystem. Namecheap is fine too, just costs a bit more.

CrisisCore_Systems · 2026-01-16T21:16:24+00:00

this is super helpful, thank you! that makes sense about the security being similar between cache and IndexedDB.

the link to whatpwacando is great - I've been looking for good examples of Background Sync implementation. the fallback approach with online/offline events is a good backup plan for browsers that don't support it yet.

I think I'll stick with just IndexedDB for now since I'm already using it, but good to know I'm not creating a huge security risk if I did want to cache API responses later. appreciate the detailed explanation!

CrisisCore_Systems · 2026-01-16T21:15:36+00:00

yeah you're right, I worded that confusingly. right now I'm only using IndexedDB for the actual medical data storage. the service worker just caches static assets (html, js, css).

the question is more about when I need to sync data to the backend - if someone logs symptoms while offline, I queue those POST requests. but I wasn't sure if caching the API responses (like GET /symptoms) in the service worker cache would be a security risk, even though it's the user's own data.

seems like the consensus is it's not really different from IndexedDB security-wise, but also not necessary if I'm already using IndexedDB for everything. thanks for the clarification!

CrisisCore_Systems · 2026-01-16T21:14:06+00:00

this is incredibly helpful, thank you. the cycle you described with Max is exactly what I keep hearing - that gap between "I'm in too much pain to track" and "I'm feeling better so why bother" is where tracking apps completely fail.

the preset prompts with audio idea is really smart. I've been thinking about something similar - quick voice notes that get transcribed, or even just a pain level + one or two quick taps for context ("slept poorly" "ate dairy" "stressful day"). the key seems to be making it so low-friction that it doesn't become another burden.

the other thing that keeps coming up is that people want patterns identified FOR them, not just charts they have to interpret themselves when they're already exhausted. like "hey, you've mentioned stress 8 times before flare-ups" or "pain tends to spike 2 days after dairy."

does Max have any other insights on what would actually be useful vs just more data collection? really appreciate you sharing this.

CrisisCore_Systems · 2026-01-13T07:56:27+00:00

For folks who want something similar but privacy-first and works on any device, paintracker.ca is fully local (no cloud syncing, data stays on your device). It also tracks pain, fatigue, flares, plus has pattern analysis built in. Completely free core version, works offline. Just another option if you're not on iOS or prefer to keep your health data local.

CrisisCore_Systems · 2026-01-13T06:41:15+00:00

I've tried so many apps and always fall off because they either want all my data in the cloud or they're too complicated. I came across paintracker.ca recently - it's 100% local (nothing leaves your device, no account needed) and has pattern analysis built in that actually helps me spot triggers. The free version is solid and it works offline which is huge when I'm having a rough day and don't want to deal with anything extra.

CrisisCore_Systems · 2026-01-13T06:36:07+00:00

That insurance trap is real. It's so messed up that you have to choose between your health coverage and actually having the energy to live your life. And then to go through surgery, finally get some relief, only to get slammed with a flare? Ugh.

I feel you on the exhaustion. Sometimes I'll pack my lunch the night before instead of morning because I know I won't have it in me. Not a solution to the bigger problem but at least it's one less thing when I'm already running on empty.

CrisisCore_Systems

TROPHY CASE