How I Ran a Full Product Sprint Without a Team

I want to be specific about what “a full product sprint without a team” actually means — because the phrase can mean a lot of different things, and I’ve seen a lot of vague accounts of AI-assisted development that don’t tell you anything useful.

This is an account of one week shipping a specific feature: a usage analytics dashboard for a B2B SaaS product. The feature had three components — a data pipeline to aggregate usage events, a backend service to query and serve the aggregated data, and a React frontend that displayed the analytics. Not a trivial feature, but not unusually complex either.

The constraint: one founder (me), one week, no contractors, no additional human help. Just Claude Code and Momental.

Here’s what actually happened.

What You’ll Need

Before I walk through the week, the setup:

• Claude Code (with an active Anthropic subscription — I was using Pro)
• Momental connected via MCP (momentalos.com)
• A Postgres database and a Node.js backend (existing infrastructure)
• React frontend (existing codebase)
• About 45 minutes of planning time at the start

Day 1: Setting Up the Sprint in Momental

Monday morning. Coffee. Plan the week before touching any code.

I built the sprint structure in Momental first. The goal went into the OKR tree: “Ship usage analytics dashboard that surfaces per-account usage for customer success conversations.” One key result: “Dashboard accessible and showing real data by Friday EOD.”

Then I decomposed that into tasks. I did this myself rather than having an agent do it, because I wanted to think through the architecture before anyone started building:

• Task 1: Design the usage events schema and aggregation pipeline
• Task 2: Build the backend service for querying aggregated usage data
• Task 3: Build the React dashboard component and hook up the API
• Task 4: Write integration tests for the data pipeline
• Task 5: QA pass and fix the issues that come up

Each task got a description with enough context that an agent could start without additional briefing. For Task 1, this included the existing event tracking setup, the database schema it would need to extend, and what the output should look like. For Task 3, it included a rough wireframe description and the expected API shape.

The planning took about 45 minutes. This investment paid back many times over.

Then I opened two Claude Code terminal windows. One for the data work (Tasks 1 and 4), one for the application code (Tasks 2 and 3).

Days 2-3: What the Agents Built

By end of Monday, agent 1 had designed the schema — two new tables, an event ingestion function, and an aggregation query that ran hourly. It wrote a DECISION atom explaining why hourly aggregation rather than real-time: “Real-time aggregation at query time will add 200-400ms per request at current event volume. Pre-computed hourly snapshots serve in under 10ms. Acceptable freshness lag for customer success use case.” I wouldn’t have written that down. The agent did.

Agent 2 had started on the backend service. By end of Monday it had the basic query structure and the API endpoint shape.

Tuesday: both agents ran full sessions. The data pipeline agent ran the initial migration, seeded test data, and confirmed the aggregation was producing correct results. It wrote three LEARNING atoms about quirks in the existing event tracking setup — non-obvious schema decisions from six months ago that would have taken me an hour to re-discover. Now they were in the knowledge graph.

The backend service agent hit the data that agent 1 had produced and found an inconsistency: the aggregation output format didn’t match what the service was expecting. It queried the DECISION atoms from agent 1, saw the original design reasoning, and updated the query to match — without asking me. This is the moment that justifies the whole setup. Without the shared context layer, this would have been a blocker requiring me to intervene.

By end of Tuesday: data pipeline running, backend service complete, React frontend at 60%.

Wednesday: frontend agent finished the component. Both agents ran integration smoke tests. Four bugs, all minor. Agents fixed three of them autonomously. One required a decision.

Day 4: Where I Had to Step In

Wednesday afternoon, agent 2 flagged a genuine judgment call.

The aggregation had two possible display modes: “total events per period” and “unique active users per period.” Both were possible with the existing data. The question: which one to show by default, and should we show both?

The agent wrote the blocker clearly: “Two display options available. Default affects the customer success narrative — ‘total events’ shows engagement intensity, ‘unique users’ shows breadth. Both are correct. Decision affects the feature frame in customer conversations. Please advise.”

This is the kind of escalation that should happen — and exactly what shouldn’t be resolved by context queries alone. This was a product judgment about how we wanted customers to understand their usage, tied to how sales frames the product. No decision atom could resolve it; I had to make the call.

I replied in the task comments: show unique active users by default, add a toggle for total events. Reasoning: customer success conversations are about whether users are adopting the product, not how much they’re clicking.

Agent 2 was back in action with clear direction in under thirty minutes.

This is what “autonomous” actually means: agents handle everything they can handle, surface only the things they genuinely can’t, with enough context that your decision time is minimal. One five-minute decision on Day 4. No other interventions needed.

Day 5: Ship Day

Thursday was QA and fixes. Both agents ran a structured QA pass against the acceptance criteria from the task descriptions. They found six issues, fixed five, flagged one: an edge case in the aggregation for accounts with zero events in a period that was producing a NULL instead of a zero.

I looked at this one. The fix was a COALESCE in the SQL query. I could have had the agent fix it, but I was there and it was a two-second change. I made it, noted it in the task comments.

Friday morning: final review. I pulled up the dashboard locally, walked through every state — accounts with lots of data, accounts with little data, accounts with no data, date ranges that span migration date (before and after events had the same schema). Everything worked.

I reviewed the PR the agent had staged. The diff was clean. The test coverage was reasonable. The DECISION atoms made the code readable — I understood why every non-obvious thing was done the way it was done.

Deployed Friday afternoon. Feature shipped.

What Surprised Me

The agents stayed on-track in a way I didn’t fully expect going in.

I’ve run Claude Code without Momental, and the session drift problem is real — agents get distracted by adjacent problems, gold-plate solutions, or go quiet for twenty minutes working on something that wasn’t the actual task. With the Momental task structure and OKR context, this mostly didn’t happen. The agents worked within the scope of their assigned tasks, flagged out-of-scope discoveries as new potential tasks rather than going off to fix them, and stayed focused on the acceptance criteria.

The knowledge graph also produced a side effect I didn’t anticipate: by the end of the week, I had a complete technical account of how the feature was built. Every decision, every tradeoff, every quirk of the existing system that affected the implementation — all logged. The next engineer (human or AI) who touches this feature will know exactly why it’s built the way it is.

That’s the kind of documentation that almost never gets written in a solo sprint. It happened automatically.

What I’d Do Differently

Scope tasks smaller from the start. Task 3 (React dashboard) ended up being three tasks worth of work. Mid-sprint task splitting is manageable, but the initial scope was too large and slowed the agent down in the middle of the session when it had to make sequencing decisions. Smaller tasks with clearer done criteria run cleaner.

Use the OKR tree earlier in feature planning. I added the sprint goal to the OKR tree on Day 1, but I should have built the strategy context earlier — specifically, clarifying that the target user was the customer success team, not the end customer. That context influenced several decisions the agent had to ask me about. If it had been in the graph from the start, those wouldn’t have been escalations.

Set up the MCP connection before the sprint, not during. I spent 20 minutes on Day 1 debugging the MCP connection. That time is better spent on planning.

---

A full product sprint without a team is real. The agents handle more than you might expect, but only when they have the strategic context to stay on-track. Momental provides that context — and the compounding record of everything that gets built.

→ From the author

Want an AI team that actually ships?

Momental gives your agents shared memory, strategy context, and coordination — so they work like a full product team. No more one-shot prompts.

Get started →Book a demo