From Idea to Shipped: How a Technical Founder Builds With Claude Code and Full Context

The operator

A technical founder building two SaaS products while contracting on four client projects is running a context-switching operation as much as a software operation. Each product has its own roadmap, backlog, and set of stakeholder conversations. Each client project has its own repo, its own communication thread in Slack or email, and its own expectations about what is being built and when. The founder is both the engineering team and the account manager, which means every context switch carries a real overhead: pulling back into the right mental model before a single line of code can be written.

The tools already exist to build the software well — Claude Code handles the implementation, testing, and iteration at a level that would have taken a small team a few years ago. The gap is not in the brain doing the work; it is in what the brain knows when it starts. Every work session begins with the same questions: what was I building, where did I leave off, what has changed in the stakeholder conversations since the last session, and who needs to know when this ships.

The breaking point

The overhead accumulates in small ways that do not feel like a structural problem until they are added up. The founder spends the first thirty minutes of most sessions reading back through Slack threads and email to reconstruct the spec context they last held clearly two days ago. A feature they shipped last week generated a stakeholder question they have not yet answered, not because they missed it but because it arrived in the wrong tab. A client project milestone that was agreed in an email has not made it onto any task or timeline because there was no moment to stop and log it.

The deeper problem is that Claude Code, as powerful as it is, starts each session knowing nothing. The founder pastes context in — the spec, the relevant thread, the current state of the codebase concern — and then the session is productive. But the paste-in step is manual, lossy, and never quite complete. The model reasons brilliantly over whatever context it receives; the constraint is that assembling that context takes human time and human judgment before the real work begins.

When something ships, the communication step falls to the bottom of the priority stack. The feature is done; telling the right people is friction. A stakeholder who was waiting on a deliverable finds out days later, not because the founder forgot them, but because there was no system that turned a completed task into an outbound notification.

The setup

The technical founder connects Gmail for client communication threads and Google Drive for specs, design docs, and project briefs. Each product and each client engagement gets its own organisation and project inside Lodestar — two product organisations with their own roadmap projects, four client organisations each with a delivery project. The MCP server is connected to Claude Code so that every terminal session can reach the full operating picture without switching to a browser tab.

Lodestar ingests the existing email threads and Drive documents and begins extracting action items with evidence — each one linked to the exact quote or file it came from. Within a day, the open items across all six contexts are visible in one place, organised by project, with due dates inferred where they appeared in the source material. The founder did not enter any of this manually; it surfaced from the communication history that already existed.

The workflow

A typical work session starts with a natural-language prompt to Claude Code: what is the current state of the day. From that point, the session runs entirely in the editor. No tab-switching, no manual context assembly, no separate comms step at the end.

• ·Sense — Claude Code calls `dashboard_today` via the MCP to get the ranked daily picture. The response shows three due action items across the six contexts: one blocking a product release, one a client deliverable, one a stakeholder reply that has been waiting.
• ·Sense — The founder says: implement the blocking item. Claude Code calls `action_items_retrieve` on that item's ID to get the full structured record: the spec fragment it was extracted from, the linked Drive document, the email thread where the stakeholder last weighed in, and the related codebase context.
• ·Sense — Claude Code calls `knowledge_search` and `files_content` to pull the current spec and any prior design decisions logged in Drive. It calls `context_resume` to surface what was last decided in the stakeholder thread. All of this arrives in the session without the founder opening a single browser tab.
• ·Decide — With full context assembled, Claude Code plans the implementation: what to build, in what order, how to test it. The founder reviews the plan, confirms or adjusts the approach, and the implementation session begins.
• ·Act — Claude Code writes the code, runs tests, and iterates. When the implementation is ready, the founder says: ship it and close the loop. Claude Code calls `action_items_partial_update` to mark the item done, then `timeline_events_create` to log the completion against the project's timeline.
• ·Close — Claude Code calls `emails_reply_link` to draft a stakeholder notification — grounded in the exact item that was completed, referencing the original request from the thread. The draft opens in the founder's compose window; they review it and click send. Claude Code calls `milestones_partial_update` to advance the project milestone if the completion triggers one.
• ·The same pattern repeats for the client deliverable: retrieve context, implement, close, notify. The entire session — context assembly, implementation, status update, stakeholder notification — stays inside the editor.

What changes

The paste-in step disappears. Claude Code arrives at each session with the spec, the thread history, the prior decisions, and the open commitments already in scope — because Lodestar holds them in structured form and the MCP surfaces them on demand. The friction before the real work begins goes from a half-hour reconstruction exercise to a few seconds of model retrieval.

Stakeholder communication becomes a byproduct of shipping rather than a separate task. When an item closes, the notification draft is generated from the real completion context, not from memory. The founder reviews and sends instead of composing from scratch. The gap between something shipping and the right person knowing about it collapses.

The operating picture across six contexts stays current without manual maintenance. Action items surface from communication threads automatically. Milestones advance when the evidence arrives. The timeline reflects what actually happened, built from the same source material Claude Code used to build the software.