Daymark: Letting Gemma Hold the Story So I Can Put My Phone Away

What if an outing companion helped you remember the day without asking you to spend the day staring at your phone?

That question became Daymark, a local-first outing planner and diary. It helps you choose a nearby place that fits your mood, gives you a voice or text companion while you're out, then turns the conversation into a reflective diary page. The intended rhythm is simple: plan briefly, go experience the day, and come back to a story you can keep.

Project: Daymark on GitHub

Live demo: Try Daymark on Render

The outing, not the chat, is the point

Daymark starts with a place, time, and the kind of outing the user wants. A nearby search can use GPS, an entered area, or a pasted map point. The server looks up named places from OpenStreetMap and can use Geoapify as a fallback. Gemma can rank the returned places against the user's mood and interests.

When the outing starts, the user can type or choose a voice conversation. Speech recognition runs through the browser's available speech API; Gemma replies locally, and ElevenLabs can speak those replies. The transcript is saved as the outing progresses. At wrap-up, Gemma receives the whole conversation, not only the last answer, together with the user's notes and saved moments.

That last part matters. A diary should reflect how the conversation unfolded: what the user kept returning to, whether their mood seemed to shift, and what their choices might suggest. It should not paste the user's sentences back at them or treat an AI companion's guesses as facts. The prompt asks for a short, fresh entry grounded in the shared details, with interpretations kept tentative rather than presented as a diagnosis.

An attached photo can also inform the page. If the user explicitly opts in, Phi-3.5 Vision describes visible details locally; Gemma can weave a relevant observation into the entry. The photo itself stays in browser storage. When the page is ready, the user can read it silently or ask ElevenLabs to narrate it.

Why put an open model in the browser?

Gemma 2 2B runs in the browser through WebLLM and WebGPU. The diary prompt and generation stay on the device. There is no hosted LLM endpoint receiving the user's conversation or diary. Entries, profile details, and attached photos are stored in that browser rather than in a Daymark account or database.

This makes the open-weight model central to the product, rather than a label on a cloud API call. The model can be inspected, changed, or replaced, and the sensitive act of turning a personal conversation into a diary entry can happen locally. A related browser WebGPU experiment explores the same shift of inference into the user's browser; its discussion also raises the first-load wait as a real user-experience cost.

There is a real setup cost: Gemma's model files are about 1.49 GB, plus runtime assets. A compatible browser and GPU are required, including WebGPU support for shader-f16 and enough available GPU memory. So I don't describe Daymark as instant or universal. The model can be cached after setup, but a first-time user has to wait and their device has to be capable.

Local-first doesn't mean every part is offline

I want to be precise about the privacy boundary. Gemma's conversation and diary writing run locally, but the app is not entirely offline:

• Nearby search sends approximate coordinates and broad place categories to Daymark's server and the map providers.
• The browser's speech-recognition provider may receive microphone audio.
• When the user requests spoken replies or diary narration, the text goes to ElevenLabs.
• Model files and runtime assets must be downloaded before local inference can work.

Those are deliberate, visible features with different data paths. The diary content is not sent to a hosted language model. The user can also skip voice, skip photo analysis, and add a place they already know instead of searching.

A related React-and-Node deployment write-up describes keeping a compiled interface and its API on one origin. Daymark uses that same practical shape with a small Node server: the same service serves the app and the nearby-search and speech endpoints.

What I want to learn outside

Voice mode is meant to let the user put the phone away between thoughts, but I don't want to claim that it has already solved that problem in the field. The next useful test is a real outing: how often does the user actually reach for the screen, does the conversation feel natural, and does the final entry sound like the day rather than a transcript? Those observations matter more than adding another AI feature.

Challenge categories

Based on the features in this build, Daymark fits:

• Best Use of Gemma — Gemma 2 2B is the local model for place matching, conversation, and diary writing. (Featured category; $200.)
• Best Use of ElevenLabs — ElevenLabs gives the companion a voice and narrates diary pages on request. (Partner category; $100.)

Best Use of Render (featured category; $200) — Daymark's front end is now live on Render, so I can enter this category too.

Best Use of GitHub Copilot (partner category; $100) — GitHub Copilot’s coding agent helped diagnose slow, overloaded Overpass requests and improve Daymark’s bounded timeout and retry behavior. The change passed all 17 tests and the production build.

Daymark's open approach trades a large first download and hardware requirements for local diary inference and a smaller amount of personal data sent to hosted AI. That's the trade I wanted to explore: an AI tool that helps make a day outside easier to remember, then gives the day—and the user—the screen back.

Watch the demo video