sprintrr.ai
An AI project manager I designed, built and shipped end to end: brand, product and code.
- Client
- Self-initiated
- Role
- Brand, product design & build
- Year
- Jun 2025 to Jun 2026
- Discipline
- AI-Assisted Development

I have spent my career designing products and handing them to engineers to build. With sprintrr I wanted to find out if I could do the whole thing myself: the brand, the product design, the code, the launch, and the marketing. One person, end to end.
sprintrr is an AI project manager. You describe a project in plain English and it drafts the tasks, milestones, and a timeline in about a minute. The idea was simple, take a project from chaos to clarity, but building it taught me how much sits between a good idea and a shipped product. This is the story of that year.
From chaos to clarity
Every project I run starts the same way: a blank board, a pile of half-formed ideas, and an hour of admin before any real work begins. Project tools are good at storing a plan once you have written it. They are not much help writing it in the first place. That blank page is where most momentum dies.
sprintrr starts there instead. You type what you want to build in plain language, and it returns a complete, editable plan, milestones, sequenced tasks, estimates, and categories, in about sixty seconds. From there it behaves like a normal project tool: a board, a timeline, analytics, and collaboration. The difference is that the cold start is gone.
Turn ideas into actionable plans
This is the core of the product, so it had to feel effortless and be genuinely reliable. You describe a project, and the AI returns a structured plan you can review, tweak, and turn into a live workspace.
What I built
A generation flow that reads a plain-English brief and produces milestones, sequenced tasks with estimates, and a timeline. Everything is editable before it becomes a project, so the AI proposes and you decide.
Making the AI reliable
Getting a model to return valid project structure every single time was the hard part. Long responses love to wander and truncate the JSON mid-object, and different providers fail in different ways. I built a provider-agnostic repair layer that strips code fences, escapes stray control characters, and balances truncated brackets so a plan never fails to parse. A validation pass then drops anything the model hallucinated before it reaches your board.
Quality or speed, your choice
Generation runs through a provider abstraction rather than a single hardcoded model. Quality mode uses Claude Sonnet for fidelity; Speed mode swaps in Gemini for a faster draft. If you would rather use your own model, bring your own key and your sprintrr credits pause, preserved, not consumed.
Everything you need to ship faster
A generated plan is only useful if the workspace around it is good. Once a plan exists, sprintrr is a full project tool: a board, a timeline, a calendar, a table, and milestones, all on the same data. I designed and built every view.
Every task, by status
Time tracking is status-driven: time accrues as a task moves through In Progress, so it stays honest without anyone babysitting a timer.
A timeline that reads like a plan
The Gantt snaps to real week boundaries with milestone diamonds and deadline markers, rebuilt to read like a plan rather than a spreadsheet.
Scheduling, in context
Milestones and tasks land on the day they are due, so the plan and the calendar are the same thing.
Everything, at a glance
Every task with its status, priority, category, milestone, and dates in one sortable view.
Progress you can see
Each milestone shows its progress and the tasks assigned to it, so you always know what is done and what is left.
Talk it through, and it files the tasks
Plans drift in meetings. Decisions get made out loud and never make it back to the board. So sprintrr reads transcripts.
Paste the text from any call, Zoom, Teams, Meet, Otter, Fireflies, or hand-typed notes, and it reconciles what was said against your live project. It proposes new tasks, status updates on existing ones, and the cancellations the call actually decided. Nothing auto-commits: you review the diff, uncheck anything, then apply, and removals are opt-in by default.
The same reliability problem, reused
This feature leans on the same JSON repair layer as generation, plus a check that validates every proposed task against the real ones in your project, so a hallucinated reference is dropped instead of corrupting your board. Honest by construction.
A week of work, in one update
Writing a status update is the chore nobody wants. sprintrr drafts one from what your team actually did, the tasks completed, milestones moved, and risks flagged, then ships it to Slack or email. About ten seconds to generate, a couple more to edit.
You can put it on a schedule for a Friday-morning draft, but it never auto-publishes. Every send is a deliberate click, because a bot quietly emailing a stale report to your stakeholders is exactly the kind of thing that erodes trust.
Wire it into the tools you already build with
I built sprintrr with Claude and Cursor, so it felt obvious that it should connect back to them. sprintrr ships its own MCP server: one npx command gives Claude Desktop, Claude Code, and Cursor around thirty tools to read and modify your projects, tasks, and milestones. Prefer your own scripts? The same tools are available over a plain HTTP API with the same scoped, revocable keys.
The bring-your-own-key story runs deep too. Connect your own Anthropic, OpenAI, or Gemini key on any plan, and every AI or agent change is attributed to a named key in an Activity feed, so there is always a reviewable audit trail of what changed and who, or what, changed it.
Take it to market
Building the product was only half the brief I set myself. A product nobody hears about is a hobby, so I ran the go-to-market too: the brand, the landing page, the launch, and a set of short ad spots.
For the spots I briefed a roster of UGC creators, cut against a calm brand and the line that holds the whole thing together: from chaos to clarity. These ran as paid social, and shaping them taught me as much about positioning as the product did about engineering.
How I built it
sprintrr is a Next.js and TypeScript app on Supabase, with Postgres row-level security scoping every record to its owner. The AI runs through a provider layer that can call Claude or Gemini or a user's own key. Ask, the question-answering feature, retrieves context with Gemini embeddings stored in pgvector. Billing is Polar, hosting is Vercel, and Slack and Jira plug in at the edges.
I pair-programmed the whole thing with Cursor and Claude Code, roughly seven hundred and eighty commits across a year, sixty-four database migrations, and more late nights than I will admit to. The least glamorous and most important part was a security and compliance program I documented in the open: encryption, multi-factor auth, data export and deletion, and SOC 2 and ISO 27001 readiness, written down rather than claimed.
What a year of evenings buys
sprintrr is in early access: a working product that turns an idea into a structured plan in about a minute, an MCP server and API that developers can wire up today, and a security program that is written down in the open rather than claimed.
The year taught me that shipping features was the smaller half of the job. The product became real in the unglamorous parts, the row-level security, the sixty-four migrations, the billing edge cases, the compliance pages nobody reads until they need to. Design got me to a convincing demo inside a month; operating it like a company is what filled the rest of the year, and that is the half I could never have learned from a prototype.
Next case study04
View all workTypeDeck
