One Solo Dev Shipped a SaaS in 30 Days. Here Is What a Claude Code Project Board Fixed.

More than one in three new U.S. startups now has a solo founder. Carta tracked that number rising from 23.7% in 2019 to 36.3% in H1 2025 [3] [4]. That is not a rounding error. It is a structural shift, and the obvious driver is AI: a solo developer with Claude Code or Cursor can cover ground that once required a team. What that solo developer still needs is a project board for Claude Code to hold the decisions the agent cannot.

One developer on Indie Hackers documented this cleanly. Max built Flowly, a tasks-and-timers workspace for freelancers, in roughly 30 days, compressing what he estimated as six months of boilerplate into one [1]. He celebrated. Then week four arrived.

By that point, the AI was producing components that worked individually but did not match each other. Decisions made in session one were contradicting decisions made in session eight. The speed that made the first three weeks possible had accelerated the context problem until it became unavoidable.

That week-four cliff is not a prompting failure. It is a state-architecture failure. This post walks through what it looks like in a real build, why the most common fix has a specific and predictable ceiling, and what changes when the assistant reads project state from an MCP board instead of from files you hand-maintain.

---

TL;DR

Max built Flowly as a solo dev in 30 days with Claude Code. By week four, the AI was producing locally correct decisions that contradicted each other globally. The standard fix (CLAUDE.md plus a memory folder) helps but breaks: it is local, manually maintained, and single-machine. An MCP-native board gives the assistant durable shared state to read and update across sessions. That is the architectural difference.

---

The Build That Actually Shipped

Flowly is not a toy. It is a workspace for freelancers that combines task tracking, timers, and analytics. Building it meant making real product decisions: what to include, what to cut, how the pieces should fit together.

Max described the AI-assisted portions honestly: scaffolding and boilerplate moved two to four times faster than without AI. The parts that stayed on him were the ones that always stay on the developer. Product judgment, scope, prioritization, distribution. The AI did not make those calls [1].

That distinction matters because it sets up the failure correctly. The context cliff is not about the AI being bad at product thinking. It is about what happens to execution consistency when decision state is distributed across dozens of sessions with no shared source of truth.

The Carta figure adds context. One in three new startups is now solo-founded [3]. That number is rising because solo developers are genuinely capable of shipping more with AI assistance. The week-four cliff is therefore not an edge case. It is the thing that happens to a growing fraction of the people building real software right now.

The Wall That Appeared at Week 4

Max named the failure mode with precision. Around week four, he started seeing "components that worked but didn't match each other, decisions that were locally correct but globally inconsistent" [1].

That is worth reading carefully. Each individual decision was defensible. The problem was not that the AI made bad choices in isolation. The problem was that it had no way to check its current choices against the pattern of earlier ones. The global picture lived only in the developer's head, not in any state the assistant could actually read.

The workaround Max reached for was a configuration-file approach plus what he called "lots of corrective prompting that should have been upfront constraints" [1]. That is not a bad response. It is the correct response given the tools available. And it points directly at the actual problem: the constraints that should have been durable state were being communicated at prompt time, one session at a time.

The pattern compounds. The faster you build, the more decisions you make per session. The more decisions per session, the sooner the context carries contradictory state. AI speed does not protect you from the context problem. It accelerates it.

The Standard Fix: Where It Breaks

The manual workaround has a name and a structure. HowToGeek documented the three-layer pattern that Claude users have converged on: a CLAUDE.md file as a hot cache for frequently-referenced context, a memory/ folder for everything else (glossary, profiles, project files), and a TASKS.md file for session persistence [2]. Anthropic's Productivity plugin formalizes the last piece, giving information a persistent home instead of letting it disappear between sessions.

This pattern is useful. It is not nothing. Teams that apply it consistently see real improvement in session-to-session continuity.

But it has a ceiling, and the ceiling is specific.

A local file is not shared state. When you work across two machines, the memory folder does not travel with you. When a second developer joins, they start with a different version of the local state. When the agent reloads after a context reset, it re-reads whatever is in the file at that moment, which is a snapshot you last updated manually, not a live system of record.

Anthropic's own context engineering guidance reinforces the point: context is a finite resource with diminishing returns, and as token counts rise, recall becomes less reliable. The recommended pattern is to keep structured notes and memory outside the context window rather than expecting the window to preserve state across sessions [5].

That recommendation is sound. What it does not specify is where "outside the context window" should be. A local file is outside the context window. So is a shared MCP board. They are not the same thing.

The problem with local files is not that they are imprecise. It is that the agent is reading state you hand-maintained, not state it wrote. The agent did not construct that file from its own actions. You did. That is a different class of problem.

See The Four Things Claude Code Tasks Cannot Store for the specific cases where cloud sync, team access, and artifact handling exceed what the file-based pattern can cover.

Before reading further: see how Agiflow stores project state over MCP.

A State Architecture Problem, Not a Prompting Problem

The corrective prompting Max described is expensive and fragile. It is expensive because you are restating constraints the agent should already have. It is fragile because the effect lasts only as long as the current session holds that context comfortably.

Prompting better does not close a state architecture gap. It papers over it one session at a time.

Anthropic's context engineering work makes this explicit: the recommended pattern for maintaining project state across agent sessions is structured external memory, not relying on the context window to preserve information between runs [5]. The window is volatile working memory. It is not a vault.

The reframe that matters is this: the question is not "how do I keep the agent on track?" That question points at prompting, and prompting has the ceiling Max hit. The question is "where does the agent read authoritative project state from?" That question points at architecture.

An agent that reads project state from a local file you maintain is doing something importantly different from an agent that reads project state from a board it can also write. In the first case, you are the synchronization mechanism. In the second case, the board is.

For the single-session mechanics of this problem, Why AI Coding Agents Lose the Plan covers how context decay works and why acceptance criteria survive where prose plans fail.

What a Claude Code Project Board Does Differently

The difference is not in the UI. It is in the read path.

When Claude Code or Cursor connects to an Agiflow board over MCP, the assistant reads task state, project context, and decision history from the board directly. It does not read a file you wrote last Tuesday. It reads the state the board holds right now, which includes updates from every prior session that touched it [6].

The practical consequence: a new session does not start from a prompt you assembled. It starts from the board. The assistant opens the task, reads the current state, and continues from there. Global consistency comes from the shared state the assistant reads. You stop enforcing it one session at a time.

A few things worth being direct about. Agiflow supplies the board: project and task state, shared across sessions and machines, readable and writable over MCP [6]. The assistant stays on your machine; Agiflow does not run or host it. Wins on simplicity and bring-your-own-assistant. Enterprise depth is not the play.

That boundary matters for understanding when the board actually helps. If your problem is "the agent keeps forgetting decisions from three sessions ago," an MCP board addresses that directly. If your problem is that the agent's model-level reasoning is inconsistent, a board does not fix that. Tools do not substitute for model quality.

The category this fits into is still forming. MCP Project Management Is Real. Nobody Owns It Yet. covers the landscape: at least seven independent MCP-native project tools launched in a roughly 12-month window, and no default has emerged. Agiflow is one working implementation. The pattern of externalizing durable state over MCP is the thing that matters, not the specific product.

The Lesson From 30 Days

Max's build was successful. Flowly shipped. Thirty days is genuinely fast, and the AI assistance was genuinely useful. The week-four cliff did not stop the project.

But it cost time, corrective effort, and consistency. And it arrived at week four because the build was fast, not despite it. That is the part the Indie Hackers post captures clearly: "output gets inconsistent" arrives "around week four, almost exactly" [1]. Not week twelve. Not when the project drags. When the build is moving.

The fix is not more prompting. More prompting is how you survive the cliff session by session. The fix is giving the assistant a place to read and write authoritative state: a board it can update, not files you maintain.

For a solo developer building with Claude Code, that means the project board is not a nice-to-have once the build gets complex. It is the thing that keeps the build from becoming complex in the wrong ways.

Connect Claude Code or Cursor to an Agiflow project board over MCP. Start from the setup guide.

---

References

[1] Indie Hackers - "I shipped a productivity SaaS in 30 days as a solo dev: here's what AI actually changed (and what it didn't)" - https://www.indiehackers.com/post/i-shipped-a-productivity-saas-in-30-days-as-a-solo-dev-heres-what-ai-actually-changed-and-what-it-didn-t-15c8876106

• Firsthand account of Max building Flowly in 30 days; source for the week-four context cliff description, workaround

used, and what the AI did and did not do.

[2] HowToGeek - "How to turn Claude into a project management system" - https://www.howtogeek.com/claudes-hidden-project-management-system-is-a-game-changer/ - Documents the three-layer manual memory pattern (CLAUDE.md, memory/ folder, TASKS.md) used to maintain Claude context between sessions.

[3] Carta - Solo Founders Report 2025 - https://carta.com/data/solo-founders-report/ - Primary source for the figure that solo founders rose from 23.7% of new U.S. startups in 2019 to 36.3% in H1 2025, based on data from tens of thousands of companies.

[4] TechRound - "The Solo Founder Era Is Here: Is This The Future Of Startups?" - https://techround.co.uk/startups/the-solo-founder-era-is-here-is-this-the-future-of-startups/ - Independent coverage corroborating the Carta solo-founder trend and AI's role in enabling one-person companies.

[5] Anthropic Engineering - "Effective Context Engineering for AI Agents" - https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Frames context as a finite resource with diminishing returns and recommends keeping structured notes or memory outside the context window rather than relying on it to preserve state across sessions.

[6] Agiflow product-knowledge MCP - internal product grounding (mcp-integration and project-management domains) - Verifies that Agiflow is an MCP-native project board for external AI assistants (Claude Code, Cursor); provides shared project/task state readable and writable over MCP; does not run or host the agent.