Dreamsea

At a glance

Who it serves

People trying to capture a dream before the details disappear.

What I owned

Product design and implementation with a psychotherapist partner shaping interpretation context.

Key decision

Capture voice first; save generation progress and let the domain expert edit prompts and knowledge.

Current state

Released iPhone app, with on-device persistence and cloud AI generation.

Evidence and gap

Public App Store release and recorded product flow. Retention and interpretation-quality benchmarks are not published here.

Problem

Dreamsea started in my partner's therapy room. She is a psychotherapist, and clients would often come to sessions wanting help with dreams. There was real demand for the way she interpreted them, but the dream itself was usually half gone by the time they arrived.

People could remember the feeling, maybe one image, a room, a person, a threat, or a colour. But the order, texture, and small strange details that make a dream worth reading were often lost.

That was the product problem: someone wakes up with something vivid, reaches for a notes app, writes two stiff lines in the dark, then tries to reconstruct the rest days later in therapy. The moment has already passed.

Dreamsea was my attempt to catch the dream closer to the source, then democratise my partner's interpretive method to a wider audience who could benefit from it outside the therapy room.

Architecture

Model: Dreamsea uses Gemini for audio understanding and text generation. The first model task is transcription: the user records a dream as audio, and that audio is sent to Gemini as audio input. Later, the iOS app can read interpretations aloud through Apple's built-in speech tools.

I chose a Flash model because the product lives in a fragile moment. Someone has just woken up, might be groggy, and might only remember the dream for another minute. The model needed to handle spoken audio, produce a transcript, then move into interpretation without making the app feel heavy.

After transcription, the generation pipeline supports titles, subtitles, symbolic readings, symbol extraction, monthly themes, and affirmations. A separate image-generation step turns the dream transcript into watercolour-style imagery through a custom prompt.

Apple AVFoundation sits underneath the model input layer. Gemini does not record the dream; the app uses AVFoundation to request microphone access, capture the dream as a local .m4a file, enforce the recording limit, then hand the saved audio file to Gemini for transcription.

Context: Dreamsea has two primary context sources. The first is the recorded dream itself. The user speaks the dream as soon as they wake up, and that recording becomes the source material for the transcript, title, interpretations, symbols, image, theme, and later regeneration.

The second context source is the Dream Wiki. I built a CMS so my partner could update the interpretive material herself without editing Swift code or waiting for a new app build. She can update both the Dream Wiki and the prompts that guide the model.

The Dream Wiki is used twice: users can read it in the Learn section, and the model receives the relevant tradition as context when it writes an interpretation. Jungian interpretations receive Jungian wiki material; Persian interpretations receive Persian material; the same pattern applies to Egyptian and Japanese.

Orchestration: when someone records a dream, the app saves the audio locally, creates a dream record, queues the work, transcribes the audio, generates a title, writes a subtitle, creates each interpretation, saves each result, then adds symbols and imagery.

The user does not manage that pipeline. They press record, speak, and leave. The app does the slow work behind the scenes, with stateful handling so a dream can be pending, partly complete, failed, or complete.

This mattered because AI fails in boring ways. A model call can time out, the phone can lock, the app can close, and image generation can fail even when the interpretation worked. So each step is saved as it finishes, unfinished dreams resume when the app reopens, the Library shows progress, and users can regenerate after editing the transcript.

Governance: dreams are not normal user content. They can include very personal things the person does not fully understand yet, so Dreamsea treats the dream record as sensitive from the start.

The product combines on-device persistence with cloud processing. AVFoundation captures the recording locally and Core Data persists dream records; audio and text are sent to AI services for generation. Local-first describes the storage approach, not an offline experience or a promise that no data leaves the device. Users control deletion of their local records. Social sharing is deliberately absent in the first version because sharing changes what people are willing to say.

There is also a clinical boundary. Dreamsea can help someone capture and reflect on dream material, and it can make my partner's interpretive style more available, but it should not pretend to be a psychotherapist, diagnose, or replace a therapy session.

Human: the human layer is the collaboration between me and my partner. My job was to take a real pattern from her work and turn it into an app that could provide thoughtful support outside the therapy room, while asking where the app should be poetic, where it should be quiet, what should be stored, what context the model should receive, and what should never be automated.

Why this approach

The obvious first version of the app was a text box that said "interpret my dream." I chose voice-first because the real problem was not interpretation alone; it was the way dream data was captured.

People lose dreams fast, and typing while half awake forces them to clean up the dream too early. A voice note preserves more of the original material: the weird phrasing, the gaps, the emotional residue, and the sentence that does not make sense yet but may matter later.

I chose a Dream Library / archive approach because one dream can be useful, but patterns across dreams are more useful. Dreamsea is built to become a private record that compounds over time, rather than a one-time answer box.

I chose a CMS because my partner's method had to stay alive inside the product. If she learns that a prompt is too vague or wants to improve a tradition, she can change the Dream Wiki herself. The domain expert should be able to shape the AI without waiting for an engineer.

I chose watercolour image generation because dreams rarely feel photographic. They blur and carry mood more than clean scene data, so the image output should feel suggestive rather than literal.

Tradeoffs

I kept social features out of the first version. That probably makes Dreamsea less viral, but virality would damage the core behaviour. If people think a dream might be shared, they start editing themselves. The honest dream matters more.

I chose local-first storage, which makes backup and sync harder. But trust is the product here. If a user believes the app is casual with their dream material, the whole experience breaks.

I chose a richer generation pipeline over a single model call. That gives the dream more depth, but it creates more failure points. The work became less glamorous and more useful: save each step, show progress, retry, resume, and fail clearly.

I built the CMS because it gives my partner control, but it also creates a new governance surface. Bad prompt edits could affect output quality, so the next version should include preview testing before changes go live.

Demo / proof

Dreamsea is live on the Apple App Store as a production iPhone app, not a TestFlight-only prototype.

The implemented product includes voice recording, transcription, title and subtitle generation, multiple interpretation traditions, symbol extraction, watercolour image generation, dream archive, transcript editing, regeneration, merge flows, Dream Wiki education, and monthly theme aggregation.

The public App Store link demonstrates the live surface, while the product architecture demonstrates the deeper system: Apple capture, Gemini interpretation, editable Dream Wiki context, local-first storage, resumable orchestration, and human expert control through a CMS.

What I would improve

First, I would build an eval layer around roughly fifty anonymised examples scored for specificity, emotional restraint, invention, tone, and whether each tradition adds something distinct and healthy. Without that, prompt and wiki changes are hard to validate.

The CMS is already one of the better architectural decisions because my partner can update the Dream Wiki and prompts without a new build. The next step is a test panel so she can preview how a change affects real interpretations before pushing it live.

On transcription, I would benchmark speech-to-text options against consented examples of quiet, fragmented dream recall before changing providers. The decision should follow transcription quality, latency, and privacy requirements.

Finally, I would add encrypted sync, treated as a trust decision first. Dreamsea is local-first for a reason, and encrypted sync would extend that trust to multi-device use without changing the privacy stance.