46 days of public building. 24 days of redesigning. Three named products. Two of them are now dead branches in the repo.
This post is what each one taught me and why v4.5.1, the version I shipped yesterday, is the first one that feels like it solves the actual problem.
April 21 · Cadence
Cadence was the first redesign. The hypothesis was that productivity needed a frame, and the frame should be time. A 7-day sprint ribbon at the top. Fitness-rings-style progress indicators. A board where each day was a column. The bet: if I made time visible, users would naturally pace themselves.
It shipped as a styling layer on top of the old v3 architecture. localStorage mock, no backend.
What it taught me: making time visible was the right instinct. Putting it on top of the wrong architecture was the wrong execution. Cadence was a skin, not a product.
April 25 · Canvas, v4.0, eleven-day life
Canvas was a ground-up rebuild. New design system, new routes, new everything. The product was an infinite-canvas workspace where users dragged goals, sprints, and tasks as cards on a freeform 2D plane. The hypothesis: productivity needed spatial freedom. Notion plus Miro plus a planner.
It looked beautiful. The demos were the best demos I have ever made. Every new user froze at the blank canvas and churned before setting their first goal.
What it taught me: spatial freedom is what designers like demoing. It is not what solo operators need. There is a difference between a product that looks like productivity and a product that produces it.
Canvas was retired to a dead branch eleven days after it shipped.
May 6 · Ember, the reshape that got deprecated
Ember killed the canvas and went vertical. A single column. Goals to sprints to tasks to checklists. No dragging. Mobile-first. The frame shifted from "what could you arrange" to "what should you do next."
Activation improved. Users praised the design. They also bounced.
This was the harder failure to admit than Canvas. Ember was a better organizer, but it was still an organizer. ClickUp Lite. The users who stayed were the ones who already had a system. The users I was actually trying to serve, the ones drowning in their own to-do lists, did not need a cleaner list. They needed something Ember could not give them.
Ember never got a version number. It was deprecated on its own branch and I went back to the v4.4 line and rebuilt the surface on top of it.
The breaking insight
I got on calls with five users between Ember and v4.5. I asked them to describe their week out loud. Not "show me your tool." Just talk through what was on their plate.
Every one of them did the same thing. They listed twelve things, then trailed off, then said something like "but really the only thing that matters this week is X."
They did not need a tool to organize twelve things. They needed a tool to finish one.
Cadence, Canvas, and Ember were all planning surfaces. What these users needed was a sprint engine. Something that would ask, every day, "what is the one goal this week, and what are the three things that move it forward today?" Everything beyond that was decoration.
Three lessons compounded into the v4.5 mental model:
Cadence taught me: make time visible.
Canvas taught me: rebuild the workspace, not the skin.
Ember taught me: force focus, do not offer options.
v4.5.1, the version that shipped
I rebuilt on the v4.4 line, which had been quietly growing in parallel while Canvas and Ember were eating my attention. I pushed it through 94 patch versions, then closed the line at v4.4.94 and opened v4.5 as the version where the sprint engine was the product.
Yesterday v4.5.1 went live.
AgileTask is a one-page sprint engine. You type one goal. AI drafts the five tasks that will ship it. Today shows only the three that matter right now. Goal, sprint, tasks, checklist, wrap.
One page. Three goals hard cap. No paid tier that lifts the cap.
Focus is not a feature in AgileTask. Focus is enforced by the product because the product literally will not let you load more than three goals at once.

Goal card on top. "Prepare AgileTask v4.5 for delivery to 50 builders by finalizing features, testing, and setting up onboarding by Friday." Status: Behind. 2 of 5 tasks shipped. Ends Sunday May 17. Plan card below with the tasks the sprint is working through. Footer reads "End of day in 0 minutes. 3 left to ship to stay on pace."
That footer line is the entire UI philosophy of the product. Most productivity apps comfort the user. This one keeps score.

The canvas in motion. Goal on top with status. Current sprint, AgileTask v4.5 pre-launch prep, Day 4 of 6. The one task you should be doing right now in the Now card. What is queued in Up Next.
Four cards. No inbox. No tag system. No workspaces.

The task editor. Title, description, a checklist for the sub-steps. An autosave indicator. An AI button that takes a vague task description and sharpens it. One button to ship the task.
No status field. No story points. No assignee dropdown. There is one of you.
The lesson under the lesson
If users praise the design and do not pay, the design is the problem. Praise is the consolation prize the product is giving you for not solving the actual job. I almost missed the Ember failure because the feedback was so polite.
Cadence, Canvas, and Ember are why v4.5.1 is one page. Every feature I want to add now has to survive one question: does this help the user finish the one thing, or is it decoration the next version will have to kill.
Where I am
46 days into publishing this build openly. v4.5.1 shipped yesterday. €19 a month, $21 outside the EU. The target is $1,000 MRR by May 31, which is 15 days from this post.
I am not going to dress up the number and I am not going to make it the headline. Hit or miss, the next post in this series will say exactly where the meter is.
The headline is that I killed three planning surfaces to ship a sprint engine, and the next 30 days will tell me whether that bet survives contact with paying users.
If you have a Cadence or a Canvas or an Ember of your own right now, a product that looks beautiful and does not pay, I want to hear which it is and what you think it is actually missing. The answer is usually the product.
This is a much stronger story than “I redesigned my productivity app.” The real insight is that users were not failing because they needed a better planning surface. They were failing because planning gave them more room to avoid committing to one outcome.
That makes AgileTask more interesting as a sprint engine than as another AI task app. The three-goal cap, the “today only” focus, and the product refusing to become ClickUp Lite are the sharpest parts. I’d lean harder into that: not “organize your work,” but “force one meaningful thing to ship this week.”
One thing I’d watch is the AgileTask name. It explains the function, but it also keeps the product close to task management, which is a crowded and low-trust category. If this becomes a sharper operating system for solo builders and founders, a cleaner platform-style brand like Xevoa .com would age better than an AI/task-descriptive name.
This is the comment I was hoping to get.
The framing you just gave — "users were not failing because they needed a better planning surface, they were failing because they were given more room to avoid committing to one outcome" — is sharper than anything I wrote in the post. I am stealing it.
And yes on the sprint-engine framing. That is the line I have been circling around for two weeks and could not quite land. "Refusing to organize your work, but force one meaningful thing to ship this week" is the right axis.
On the name. You are not the first person to raise it and the critique lands. The category is crowded and low-trust, you are right. The counterargument I have been making to myself is that descriptive names get cheap traffic early and platform names need more capital to defend. I do not yet know which side is correct for where this is going. Happy to take that conversation off-thread if you have time, it is the question I am most uncertain about right now.
That is exactly why I’d pressure-test it now, not later.
The risk with AgileTask is not that it is unclear. It is very clear. The risk is that it teaches people to place the product in the wrong category before they experience the real value.
AgileTask says task management.
But what you are actually building sounds closer to a sprint engine for solo builders: less planning, fewer options, one meaningful thing shipped this week.
That difference matters because once users, screenshots, posts, and early traffic start attaching AgileTask to the product, the cost of changing it goes up fast.
Xevoa.com came to mind because it gives you platform-style room without trapping the product inside task-app language. It can carry AI workflow, execution, sprint focus, and founder productivity much better.
I have access to Xevoa.com, so if that direction feels worth exploring, I’d take this off-thread now while the name is still cheap to change.
My LinkedIn:
https://www.linkedin.com/in/aryan-y-0163b0278/