Bubble Chat MVP RoadMap
Or: stop inventing features in the order you thought of them, and write the product the way a person actually moves through a thinking session.
Source: /Users/nitishchauhan/Downloads/3 Final - Bubble Chat MVP RoadMap.md
Phase: final
Status: draft
Mode: Authority (product architecture)
Pipeline: CONSTITUTION - Publishable Asset Pipeline
Master: 00 - Master Index
Index: Index - Bubble Chat MVP RoadMap
Trajectory: Trajectory - Inner Map
Slug folder: Work/bubble-chat-mvp-roadmap/
Where this document starts
Brainstorm was no longer the bottleneck. Structure was.
Atlas / Bubble Chat already had a pile of good ideas: sessions, floating bubbles, canvas verbs, export packs, silent workers, compression. They were grouped by when they showed up in conversation. That is a terrible spine for a product. Chronology tells you the history of ideation. It does not tell an implementer what the user is doing, what must exist first, or which noun is root.
This piece is the pivot: stop acting like feature collectors, act like product architects, and reorganize the specification by user journey. Philosophy on page one. Modules in the order a thinking session actually needs them. Then the hard product decisions that stop a rewrite later: Workspace Objects, a Session → Workspace → Objects → Messages model, PRD before TDD, and one Cursor-facing rule about responsiveness.
What follows is that architecture pass, kept dense and buildable.
Page 1: product philosophy
Atlas is not another AI chat client.
It is a Thinking Workspace that removes cognitive friction while preserving the flow of thought.
Three principles. They should sit at the front of the specification because they decide hundreds of later calls.
Principle 1
Conversation is not linear.
People naturally split into parallel thoughts.
Atlas embraces this.
Principle 2
Capture should never interrupt thinking.
Everything else is secondary.
Principle 3
The computer should organize.
The human should think.
If a feature fights any of those three, it is the wrong feature for this product, no matter how impressive it looks on a roadmap slide.
Module 1: Sessions
Everything belongs to a Session.
Session
↓ contains
Multiple Chat Bubbles
↓
Exports
↓
Memory
A Session contains:
- metadata
- start/end time
- models used
- workspace layout
- exported files
- AI summary
- compression history
Closing the Primary Bubble closes the Session.
The Session is the container unit. Bubbles live inside it. Exports and memory hang off it. Future work does not invent a second parent for “where did this thinking live?”
Module 2: Bubble System
This is the heart of the product.
Every Bubble has:
- title
- model
- color
- icon
- importance
- memory
- status
Possible statuses:
- Active
- Thinking
- Idle
- Background Agent
Each bubble remembers:
- scroll position
- collapsed answers
- zoom
- cursor
- position
- size
Layout state is part of the object, not a disposable UI accident.
Bubble types
Seven types. The tiny icon alone improves workspace readability at a glance.
| Icon idea | Type |
|---|---|
| Conversation | main dialogue |
| Reading | long text / docs in focus |
| Research | search and synthesis |
| Coding | implementation thread |
| Idea | speculative capture |
| Question | open loop, unresolved |
| Scratch | disposable working surface |
You should be able to look at a crowded canvas and still know what kind of work each card is doing without opening it.
Module 3: Workspace
The Workspace is not a chat.
It is a canvas.
Features:
- Drag
- Resize
- Snap
- Dock
- Overlap
- Auto Arrange
- Free Mode
- Minimap
- Session Sidebar
- Bubble Preview
- Bubble Parking
- Replay Workspace
This is almost Figma-like: spatial control over thinking surfaces, not a single column of messages pretending to be a desk.
Module 4: Bubble Actions
Every Bubble supports a small, boring, complete set:
- Duplicate
- Snapshot
- Pin
- Close
- Rename
- Change Model
- Convert to Primary
- Export
- Minimize
- Background Research
No complicated menus. Actions should feel like card operations, not application window chrome.
Module 5: Conversation Features
This is different from workspace.
Conversation itself should support:
- collapsible answers
- multiple summary levels
- message numbering
- timestamps
- prompt numbering
- bookmarks
- question markers
- important answers
- drag response into another bubble
Workspace is how cards sit on the desk. Conversation is how a single card holds dialogue density without becoming a wall of text you never want to re-enter.
Module 6: Session Navigation
Two numbering systems must coexist. Not every session needs branching.
Session list style:
S1
S2
S3
S4
Structured mode:
1
1.1
1.2
1.2.1
Independent parallel style (when branching is the wrong metaphor):
Main
+ Electron
+ Python
+ Cloud
Branch trees for nested inquiry. Independent bubbles for parallel tracks that do not want a parent/child story. Both are valid session shapes.
Module 7: AI Workers
Deliberately separate these from the chat surface.
The chat should not “know about” them as UI characters. Workers consume the same session data and do jobs in the background.
Workers include:
- Historian
- Scout
- Compression
- Summarizer
- Question Extractor
- Relationship Detector
- Background Research
Silent infrastructure, not more bubbles competing for attention unless the user asks to surface a result.
Module 8: Memory
This is where the product becomes larger than a chat client.
Each session stores:
- Questions
- Insights
- Projects
- People
- Files
- Links
- Models
- Exports
- Concepts
- Open Loops
Future Sessions reference this automatically. Memory is not “chat history you can scroll.” It is structured residue of thinking that later work can attach to.
Module 9: Export
Export deserves its own chapter.
Support:
- Markdown
- JSON
- Workspace Snapshot
- Compressed Summary
- Question Archive
- Conversation Archive
- One Folder pack
Example layout:
Morning Research/
S1.md
S2.md
S3.md
summary.md
questions.md
session.json
workspace.json
Clean folder as first-class product surface. If leaving the app loses the structure of the session, export failed.
Module 10: Compression
This is the feature that could eventually define the product.
Compression pipeline
Raw Session
↓
Daily Compression
↓
Weekly Compression
↓
Monthly Compression
↓
Quarterly Compression
↓
Yearly Compression
Instead of knowledge growing forever, knowledge becomes denser.
Most tools hoard transcripts. Atlas should densify them on a deliberate time ladder. Raw stays available where needed; the default path of understanding gets tighter as time moves.
That philosophy is rare. It should not be treated as a storage optimization bolted on later.
Module 11: Search
One search. Everything.
Search across:
- Questions
- Bubbles
- People
- Projects
- Models
- Files
- Sessions
No separate search systems for each surface. Fragmented search reintroduces the cognitive tax the workspace is supposed to remove.
Module 12: Settings
Almost boring, on purpose.
- Models
- Providers
- Themes
- Storage
- OpenRouter
- OpenAI
- Anthropic
- Local Models
Settings exist so the desk works. They are not the product story.
The missing abstraction: Workspace Objects
Right now the mental model can still collapse into “every floating thing is a chat.”
It should not.
Everything floating becomes an Object. Objects can be:
- Chat
- Markdown
- Browser
- Image
- Todo
- Whiteboard
- Table
- Link Collection
- Notes
Imagine researching with all of these in one workspace:
- Main Chat
- Browser
- Todo
- Reference Note
That is when Atlas stops being “a chat application with extras” and starts becoming an operating system of thinking tools.
The biggest product decision: rename the root nouns
Internally, remove the words chat and branch from most of the architecture language.
Model everything as:
Session
↓
Workspace
↓
Objects
↓
Messages
A Chat is simply one kind of Object.
That decision buys flexibility later without rewriting the architecture when the second, third, and fourth object types become as important as dialogue.
Process gate: PRD before TDD
Before handing this to Gemini and Cursor, create a Product Requirements Document (PRD) before a Technical Design Document (TDD).
Why: strong technical documentation still fails if product intent is fuzzy. Intent has to be crystal clear first.
PRD structure
- Vision and Philosophy
- User Problems (the cognitive frictions being solved)
- Design Principles
- Core Data Model
- Information Architecture
- Feature Specifications (organized by module)
- User Flows (for example: start session, spawn bubble, export session)
- MVP Scope
- Stretch Features
- Technical Constraints and Non-functional Requirements (offline-first, local-first, smooth 60 FPS interactions, low memory usage, OpenRouter compatibility, and similar)
Then the technical job becomes translation: complete product vision into an implementation blueprint, not invention of product meaning mid-build.
Cursor instruction at the top of the doc
Optimize for responsiveness over feature count. Every interaction should feel instantaneous. The experience should resemble manipulating lightweight cards on a desk rather than opening heavyweight application windows.
If the app nails that feeling, it will stand out more than if it simply has the longest feature list.
What this roadmap is actually claiming
Three layers, stacked:
- Philosophy: Thinking Workspace; non-linear thought; capture without interruption; machine organizes, human thinks.
- Modules: Session container, Bubble System, canvas workspace, conversation tools, dual navigation, silent workers, memory, export, densifying compression, unified search, boring settings.
- Architecture bets: Objects not chats-as-root; Session → Workspace → Objects → Messages; PRD before TDD; responsiveness as the real differentiator.
That is enough to stop brainstorming and start building against a user journey instead of against a diary of feature ideas.
End of Final. Review against Trajectory - Inner Map and source fidelity before Labs ship.