DEV Community

Simple Memo
Simple Memo

Posted on

The issue tracker was built for a team I don't have

This is going to be a rant. I'll earn it before the end.

Here is what set me off. Last Tuesday I spent forty minutes grooming a backlog that exactly one person will ever read. That person is me. I moved cards between columns, I set a priority field on each one, I dragged four of them into something my tool insisted on calling a sprint, and at no point in those forty minutes did I produce a line of code, a fixed bug, or a piece of information I did not already have in my head when I sat down.

I have run my product alone for over a year. For most of that year I kept reaching, by reflex, for the same category of software every team I ever worked on used to coordinate itself: the issue tracker. Jira, Linear, GitHub Issues, a Trello board with a tasteful column layout — the brand kept changing, the reflex did not. I want to talk about why that reflex is wrong for a solo dev, because it took me an embarrassingly long time to name what was bothering me.

What I was actually doing for forty minutes

Break down the ceremony of an issue tracker and almost every ritual in it exists to answer a question that a second person would ask.

Story points exist so a team can forecast capacity across several people and argue about it in planning. Status columns exist so that when I hand a ticket to you, you can watch it move from "mine" to "yours" without either of us sending a message. A "definition of done" exists so that two people who disagree about what finished means can settle it in writing before it becomes a fight. Assignee fields, sprint boundaries, WIP limits, triage labels: every one of them is a coordination primitive. They are answers to the problem of getting work through more than one pair of hands.

I have one pair of hands. When I set a story-point value, I am estimating my own capacity to myself, then reading my own estimate back later and feeling vaguely accused by it. When I move a card from "In Progress" to "Review," there is no reviewer. The card is moving from me to me. I had built an entire apparatus for handing work off, and then I stood on both sides of every handoff.

Why this is worse than wasted time

If the tracker only cost me forty minutes a week I would shrug and pay it. The real cost is that the tool quietly reshapes the work to fit its own shape.

A board wants to be tended. An empty column feels like failure; a full "Done" column feels like progress even in a week where I shipped nothing that mattered. I caught myself making tickets for work I had already finished, purely so I could drag them to Done and feel the small hit of it. That is status theater, and I was performing it for an audience of nobody.

Then there is the guilt. A stale board is a quiet daily accusation. Forty-one open tickets, six of them older than a quarter, all of them technically "mine" and none of them moving: the board turns an ordinary backlog into a monument to my own unreliability. On a team that pressure is sometimes useful, because a colleague can see the same board and the shared visibility creates real accountability. Alone, it is just a machine for manufacturing low-grade shame, and I was paying a monthly subscription to run it.

The mismatch underneath all of this is simple. An issue tracker is optimized for state that is shared and asynchronous: many people, touching the same work, at different times, needing a durable record of who holds what. My work is neither. It is one person, holding the whole thing in one head, in more or less continuous time. I was using async-coordination software to coordinate with no one.

What I reach for instead

I keep a single plain-text file. Every line starts with a date and a verb. 2026-07-06 fix the timezone bug in the CSV export. When the line is done I do not drag it anywhere; I put an x in front of it and move on. There are no columns, because there is nobody to hand a column to. There is no status beyond "still here" or "struck through."

Time-bound obligations go in the calendar, because a calendar is honestly better than any tracker at the one job it has: telling me a thing must happen on a specific day. And the only real queue I keep, the only place where work actually arrives from other people, is my email inbox. I wrote a whole separate piece about treating the inbox as the single task queue, so I won't relitigate it here, except to note the principle is the same one running through the text file: the thing that assigns me work is allowed to be the thing that tracks it, and I refuse to keep a second copy by hand.

The one rule under all of it is that capturing a task has to be cheaper than the thought that produced it. If writing a task down takes eleven seconds of choosing a project and a label and a priority, I will not write half of them down, and the unwritten half is where the real bugs hide. So capture is a dated line and nothing else. It is the same instinct that made me build Simple Memo, my own capture app, around a single action instead of a menu: the instant you force someone to decide where a thought goes, you have already lost some of the thoughts. Sorting can happen later, on a quiet Sunday, when sorting is cheap. The capture moment has to stay too dumb to ask questions.

The part where I argue against myself

I said I would earn this rant, so here is the half of it I think is wrong.

There are cases where an issue tracker earns its place even for one person, and they share a tell: a second human shows up somewhere in the loop. The moment my project has outside contributors, a public bug tracker stops being ceremony and becomes the actual shared surface those people need. I cannot ask a stranger on the internet to append a dated line to my private text file. Anything with a compliance or audit requirement needs the durable, timestamped, who-changed-what record that a tracker gives you for free and a flat file does not. And there is one more that has nothing to do with other people at all: scale over time.

That last one is the trade-off I am genuinely unsure about. My text file is fast to write and miserable to query. Ask me what I was working on in March and I am reduced to grepping the file and reading around the matches. A real tracker would let me filter by label and date in a second. For a project I intend to run for a decade, I may be trading away a queryable history that future-me will badly want, in exchange for a capture speed that present-me enjoys today. I have chosen present-me every time so far. I am not at all certain that is the right person to keep choosing, and I notice I grow less certain the older the file gets.

Before you tell me I'm wrong

Some of you run a personal tracker and love it, and some of you are on teams where the board is the only reason the work ships at all. I am not coming for your board. I am coming for the reflex: the assumption that because real software teams track work in Jira, a party of one should too.

So here is the question I actually want answered, because I think it exposes the whole thing. What is the one field in your tracker that you fill in on every single ticket and have never once read back? Story points is my bet. Tell me I'm wrong, and tell me which field genuinely earns its keep when nobody but you will ever look at it.


I build Simple Memo alone — an iOS app that turns a line of text into a sent email in about a second, then gets out of the way. I post here a couple of times a week, usually when one of my strong opinions survives a fight with my own logs.

Top comments (0)