Synapse

I built Synapse because most journaling tools stop at storage.

They help you write down what happened, but they do not help you notice the deeper patterns: the people who keep appearing in your story, the emotions that return in cycles, the moments that quietly rhyme with each other, or the questions your life keeps asking you.

Synapse is for people who want reflection to become more than a private archive. It is for builders, seekers, thinkers, and anyone trying to understand their own life through multiple lenses without being locked into one worldview.

The core idea is simple: your life moments are a personal corpus. Synapse helps you record them, connect them, and read them back through whichever interpretive framework fits the season you are in.

Synapse is built as a full-stack AI reflection platform.

Frontend:

• React 18
• TypeScript
• Vite
• Zustand
• Supabase Auth client
• Three.js
• react-force-graph-3d
• i18n for English and Korean

Backend:

• Python
• FastAPI
• SQLAlchemy
• Supabase Postgres
• Supabase Auth with JWT verification

AI:

• OpenAI GPT-4o
• OpenAI gpt-4o-mini
• text-embedding-3-small
• Anthropic Sonnet / Haiku support through provider flags

Hosting:

• Vercel for frontend
• Railway for backend
• Supabase Cloud for database and auth

Key product surfaces:

• Moment recording
• Entity graph
• AI interpretation
• Framework Marketplace concept
• The Oracle chat experience
• Journey summaries
• Multi-framework reflection plugins

The most important AI workflow in Synapse is not a single prompt. It is the interpretation pipeline.

Each recorded moment can be interpreted through a selected framework. The default Synapse lens mirrors the user’s own past notes without using an external corpus. Other frameworks, such as Bible, Stoic, architect, and Buddhism, can bring in different reference systems, tones, and concepts.

A key design choice was to make every interpretation framework-agnostic at the API level. The AI returns a structured shape with:

• interpretation
• references, when the framework uses them
• reflection question
• observed pattern
• narrative connection
• framework id
• extra metadata

The Bible framework uses a two-pass workflow: first generating a grounded reflection, then critiquing and rewriting it against a rubric for accuracy, specificity, tone, freshness, and question quality.

The Oracle chat prompt also mattered a lot. It needed to feel like a reflective companion, not a generic chatbot. The system prompt changes depending on the active framework, while still grounding answers in the user’s recorded moments.

AI tools used during the build:

• Codex for implementation support
• ChatGPT for product thinking, prompt iteration, and copy
• OpenAI models for interpretation, summaries, extraction, titles, tags, and embeddings

The biggest architecture decision was making Synapse multi-framework from the beginning.

At first, it would have been easier to build one fixed interpretation system. But that would have made the product too narrow. I wanted Synapse to support many ways of reading a life: personal memory, scripture, philosophy, systems thinking, contemplation, and eventually user-installed frameworks.

So the backend uses a framework plugin layer. Each framework owns its own interpretation logic, retrieval, journey summary style, motif taxonomy, and chat persona fragment. The rest of the app talks to a common orchestrator.

That decision added complexity, but it protected the product’s future.

Other trade-offs:

• Events are saved instantly, while heavier AI work runs in background tasks.
• Graph edges are computed from co-occurrence instead of stored permanently.
• The user’s life moments are the shared corpus; frameworks are lenses on top.
• Supabase owns auth, while the FastAPI backend verifies JWTs and owns business logic.
• Interpretations are cached on events so users do not pay the AI cost repeatedly.

The hardest problem was keeping the product identity clear.

Synapse started with a strong Bible interpretation direction, and that made the early product feel powerful but too narrow. The challenge was evolving it into a multi-framework reflection platform without losing the emotional depth that made the first version interesting.

That touched almost every layer: copy, data models, API contracts, frontend gates, interpretation storage, chat prompts, journey summaries, and future marketplace design.

The dangerous moment was that the app could have shipped with Bible-specific assumptions hidden everywhere. That would have made future frameworks feel bolted on instead of native.

The fix was to move framework-specific behavior into plugins and make the core product about recorded life moments, entity connections, and interpretation lenses.

With another week, I would focus on making the Framework Marketplace real.

Right now, the architecture is ready for multiple frameworks, and several framework concepts exist, but the user experience can become much stronger. I would add:

• Install and activate framework flows
• Side-by-side interpretation comparison
• Better framework onboarding
• A cleaner view of how each framework reads the same moment
• More transparent controls for what data each framework uses
• Stronger visual storytelling around the user’s evolving life graph

I would also improve the onboarding so a new user understands the magic faster: record one moment, see the graph form, ask The Oracle, and immediately feel the loop.

The biggest lesson: do not confuse a powerful first lens with the whole product.

A narrow interpretation can create a magical prototype, but the architecture needs to protect the larger idea. For Synapse, the larger idea is not “AI explains your journal.” It is “your life becomes a connected corpus you can revisit through many meaningful lenses.”

I also learned that AI products need strong boundaries. The model is powerful, but the product should decide what the model is allowed to do, what structure it must return, and how the user stays in control.

Things I would tell another Builder:

• Start with the emotional loop, not the feature list.
• Make your data model match the future product, not just the demo.
• Cache expensive AI results early.
• Keep prompts modular.
• Separate core user data from interpretation layers.
• Do not let one use case leak into every file.
• Build the thing that makes the user say, “Oh, this understands my life differently.”