Why I built TaskCue
Build notes for TaskCue, a free task and reminder app: the problem, my role, the stack, and the live link.
TaskCue is a free task and reminder app at tasks.samikhanapps.com. I built it as product owner and builder. It is a personal product, not a commercial one. I use it, and I left it open for anyone who has the same problem. This note is why it exists, what I took responsibility for, and what I deliberately did not build.
The project page, with the short version of problem, role, and stack, is TaskCue on the portfolio. The notes below are the longer cut.
The problem
Teams — and by teams I also mean a small group of people who simply work together — needed a lightweight way to share tasks and reminders without adopting a heavy project tool. That sentence is the whole brief. It came from friction I already knew professionally. I have spent years in Jira-centred delivery, including programmes with cross-functional teams of 30 or more. Those tools earn their place when you are running scope, risk, and a release train. They are the wrong weight when the job is "remind the three of us, on a shared calendar, and do not make us administer a project".
The workaround I kept seeing was a split brain. Real work sat in a serious tracker. The human layer — who is chasing what, what is due tomorrow, what was agreed in a conversation — sat in chat, inboxes, and private notes. None of those fail dramatically. They fail by silence. A reminder that lives in one person's head is not a shared reminder. A task tool that takes ten minutes to configure is a task tool people will not open for a small thing, so the small thing never gets captured.
I did not want another methodology. I wanted capture and follow-through to be faster than the workaround.
My role
I was product owner and builder. That meant discovery, the UX, the backlog, and hands-on implementation with Claude Code. There was no separate product trio. The advantage is speed of decision. The risk is building your own assumptions into the interface and calling it research. I tried to keep myself honest by writing the non-goals down before implementation, the same way I do on client work.
The UX follows from the refusal. Speed of capture first. A shared calendar so a reminder is visible to the people who need it, not locked in one login's private list. Operational workflows rather than a configurable process engine. Sign-in by mobile, email, or Google.
The backlog stayed short on purpose. Every extra concept — sprints, story points, custom fields, portfolio rollups — would have recreated the tool I was refusing to make people adopt. I have ordered backlogs for analytics SaaS and for compliance programmes. I know how fast a "lightweight" product stops being lightweight if the owner will not say no. Saying no was the product job. Implementing the yes was the builder job. I held both, and I reviewed my own output instead of treating generated code as finished.
The stack, and why it is boring
TaskCue is Claude Code, React, Node.js, and MySQL. I chose that because I can operate it. React for the interface, Node.js for the application surface, MySQL for the records, Claude Code as the implementation partner inside a scope I had already written. Nothing in that list is an architectural claim. It is a maintainability claim. A free tool I intend to keep running has to be a tool I can change on a weeknight without restaffing.
I have used Google AI Studio where a PWA was the better shape — that is how Medical Claims was built — and I did not need that shape here. TaskCue's problem was shared operational reminders, not offline-first clinical capture. Picking a stack because it is fashionable would have made the product about me. Picking a stack I can support makes the product about the reminder.
The way I used Claude Code matches the shipping note on this site. One behaviour at a time. Acceptance criteria before a session. I read the change and I click the path. If a session adds a concept that was not in the boundary, it comes out. I am not publishing prompts or code in this note. The process is the part worth sharing. The app is the part you can try.
What shipped
What shipped is a live production app for personal and shared operational reminders. Shared calendars. Workflows aimed at getting the thing done, not at reporting on the thing. Login by mobile, email, or Google. The success test I use is personal and concrete: do I actually capture the reminder here, or do I fall back to chat? If I fall back, the product has a hole, and the hole is mine to close.
It is free. It is not a startup, not a pilot for a paid tier, and not a client deliverable with a logo story. Some other workplace tools I use share Systems Ltd branding on a login screen because that is the context they run in. TaskCue's portfolio page is about this product: a personal build, live, and given away. I would rather be clear about that than imply a commercial traction story I do not have and do not want.
The two neighbours
TaskCue is one of three live free tools. They share a motive and not a domain.
Circles Finance replaced spreadsheets for billing windows, leave, and a budget ledger. The stack is Claude Code, React, and MySQL. The live app is finance.samikhanapps.com. The lesson next to TaskCue is the same shape of problem: a heavy or messy incumbent, and a first release that covers the real cycle so the old workaround can actually stop.
Medical Claims is the health-adjacent one: family medical expenses and a monthly claim PDF, built as a PWA with Google AI Studio, live at medical.samikhanapps.com. It is not an EHR. I keep that distinction sharp because my healthcare delivery record, including Panacea at 100 percent Meaningful Use Stage-2, is a different kind of work. TaskCue does not borrow credibility from it. Each product has to justify its own scope.
What I would repeat
Start from the tool people are refusing, not from a feature list copied out of a suite. Write non-goals while you are still enthusiastic, because that is when you will smuggle in sprints and dashboards. Choose a stack you can run alone. Use Claude Code inside a slice you can test the same day. Ship a free version if the point is to solve the problem and to show the work, and say so in public so nobody has to guess at a business model.
If you want to see the other shipped work — enterprise programmes as well as the live apps — it is collected at samikhanapps.com. If you are early in product management or business analysis and you want to talk about scoping a small tool without turning it into theatre, I am on LinkedIn.