Dream Journal

What it is

Dream Journal is a local-first web app for capturing dreams with as little friction as possible. You can write down what you remember for the current day, mark a day as No dream, assign a primary category, and review entries later through a color-coded calendar and history view.

The product is intentionally small. No login, no backend, no cloud sync, and no pressure to turn a private habit into a dashboard.

Why I built it

I built Dream Journal because most journaling tools feel too generic, too busy, or too cloud-dependent for this kind of use case. I wanted something calmer: a product that made it easy to capture a dream quickly, reflect on patterns over time, and keep the data on-device.

It was also a chance to explore local-first architecture in a more product-driven way. For a dream journal, privacy is not just a technical property. It changes the tone of the entire experience. If the app is supposed to feel personal and low-pressure, it should not start by asking for an account or sending your entries to a server.

How it works

The app is built as a React + TypeScript SPA with Vite and React Router. Data is stored locally in IndexedDB through Dexie.js, which gave me a structured way to manage dream entries, categories, tags, and settings without introducing backend complexity.

The main flow is centered on Today. That screen only cares about the current local date, so capturing a dream feels immediate instead of administrative. Past entries are handled through the calendar and history routes, which keeps the primary writing flow focused.

The calendar uses category colors to surface recurring themes over time, while export and import provide a basic ownership story for a product that deliberately has no sync layer.

Key features

• Fast Today flow for recording a dream on the current local date
• Support for No dream days so the journal reflects absence as well as recall
• Color-coded calendar view for spotting recurring patterns over time
• Editable history for reviewing and updating older entries
• Local export and import for backup and portability
• Browser dictation support where available

What I learned

The main lesson was that simplicity still needs structure. Keeping the product calm meant being strict about scope, careful about date handling, and deliberate about what local-first should promise.

I also came away with a better sense of where browser persistence is enough on its own, and where a product still needs explicit data portability to feel trustworthy.

Status

Built and working as a fully local-first app. The strongest part of the project is the product boundary: private by default, fast to use, and intentionally narrower than a typical journaling platform.