I’ve been experimenting with the idea of caching a web app so it continues working even when the internet drops. Apps like Google Docs already do something similar for documents. It made me wonder.
I’m a first-year college student and currently in the basic learning phase. Lately I’ve been doing a lot of “vibe coding,” and the offline idea came to my mind as something interesting to try.
So I started building a very simple task management web app.
My main goal wasn’t to build another task manager, but to experiment with an offline-first web app that still works when the internet is unstable. I focused more on the offline system than the front-end features.
What it does:
Offline-first workflow: tasks, routines, and analytics remain usable offline
Local sync queue that pushes updates to Neon/Postgres when connection returns
Productivity scoring that separates routine consistency from one-off task completion
I would really appreciate candid, critical feedback, especially on:
Offline sync edge cases I might have missed
UX friction in the dashboard/workspace flow
Whether this feels genuinely useful for daily use vs just a cool demo
If you’re into local-first apps, I would love an honest teardown of where it breaks or feels weak.
I mostly just want to know is this idea actually interesting.
github : https://github.com/ShadowXByte/TASKFLOW
vercel demo : https://tasflow.vercel.app/
Top comments (2)
I think the offline-first idea is actually very interesting. Many apps still depend heavily on internet access, so having something that continues working offline can be very useful, especially for productivity tools. The local sync queue approach also makes sense. One challenge you might want to consider is handling sync conflicts when the same data is modified in multiple places. Overall, it sounds like a solid learning project and a good experiment with offline architecture.
Thank you for the feedback! You hit the nail on the head, handling those sync conflicts is the biggest challenge I’m facing now. Every new feature seems to introduce a new edge case for stability, and I’ve had to prioritize fixing the 'guts' of the sync logic over adding more UI features. It's been a constant cycle of refactoring to keep everything robust, but I'm determined to make the architecture as stable as possible before moving forward.