Project management for solo developers, and when a text file still wins

The most useful answers to the question of project management for solo developers are the ones telling you not to bother.

"I find managing and learning any of those tools to be a big waste of time," wrote rywils21 in a February 2020 Indie Hackers thread asking exactly this. Another reply in the same thread, from voidmonk: "Over two decades in the tech industry, and I've always come back to plain text files for to-dos and task planning" (indiehackers.com). Later, in a September 2024 Ask HN thread, lukev put the objection more precisely: "Using standard software development practices (issues, backlogs, kanbans) definitely feels like overkill, way too much ceremony and a waste of time" (news.ycombinator.com).

That is the honest baseline. A tracker exists to coordinate people, and there is one of you. Assignment, notification, shared state, permissions — every part a text file lacks solves a problem you do not have.

So the question is not which tool. It is what has to become true before any of this stops being overhead.

The tipping point is not the number of projects

The usual framing is volume. One roundup tiers the answer by project count — one to three projects means a spreadsheet or GitHub Projects, four to twenty means a dedicated tool, twenty and up means something more robust (projectshelf.dev) — though its own product appears in all three tiers.

Volume is the wrong axis, because it predicts nothing. Sixty tasks on one product you open every morning stay manageable in a file: the state is already in your head, and the file is a prompt rather than a record. Six tasks across three products you touch in rotation are not, because nothing in that arrangement tells you what is waiting.

When project management for solo developers starts to pay

Two conditions change the answer. Neither is about size.

One: more than one thing is in flight

Not more than one task. More than one context — a second product, a client project beside your own, the contract that funds what you actually want to build.

On that Ask HN thread, ilovefood keeps TODO comments across each codebase and compiles them with a script: "As I'm working on a lot of projects, the important thing for me is keeping it easy to start/stop working on a project." JohnFen keeps a wiki page per project plus an "overview" page that is "a directory to all of the projects and is where I keep my 'Top 10 task' list across all projects".

Both hand-built the same missing piece. A file per project separates contexts perfectly and aggregates them not at all, so once there are three you need a fourth artefact whose only job is to answer "what is mine, across everything". That artefact is a tracker, and it arrived because of the number of contexts, not tasks.

Two: there are days between sessions

The second condition is time, and the cost is not the expected one. You do not forget that the task exists. You forget why you picked it, what you had already ruled out, and where you stopped.

Two replies on the same thread name it. newaccount74, twelve years solo: "I use Github issues to track features and bugs that I am working on. It's useful because sometimes I come back to a feature months (or even years) later, and I don't have to start from zero again." And moi2388: keep a list of your todos "and their state and context in case you come back to it a couple of weeks later or so".

For one person, a tracker is not a coordination device. It is a context cache, and all of its value is in what it holds while you are not looking.

What that means you should look for

Once both hold, the requirement is awkward: the two halves pull in opposite directions.

The last row is where enterprise tools fail a solo developer specifically rather than generally. Configurability is paid for once by an organisation with somebody whose job it is, and continuously by whoever is left holding it — alone, that is you, in the hours you were going to ship in. That is the argument in being the Jira admin for a small team.

Where we fit, and where the ceiling is

We build a tracker, so read this as an illustration of the shape above, not a recommendation.

Kevta has two containers: a board is one stream of work with its own columns, properties and saved views, and a workspace owns a set of boards. Running several things alone, a board per product inside one workspace is usually the right shape.

Aggregation is the half a pile of files cannot do. My issues collects everything assigned to you across every board you can reach, grouped by due date into Overdue, Today, This week, Later and No due date. The home page adds recently viewed and pinned boards. That is JohnFen's overview page, except nobody maintains it.

Every board renders the same issues as a board, list, table or calendar, switched with the number keys, and a saved view stores the whole arrangement — view type, grouping, filters, sort — as a named tab that can be the board's default (how boards work). The client project opens as a calendar, the product opens as a grouped board. A new board arrives with Title, Assignees, Status, Priority and Due Date already on it, so there is nothing to design first (the quickstart).

The caps, stated as caps. Free is $0 with 2 workspaces, 5 boards in each and 10 members per workspace; Pro is $10 per workspace per month — not per person — for 10 workspaces, 10 boards each and 50 members (pricing page). Alone, the member cap is irrelevant. The one that binds is boards: five products in one workspace on Free, and if you want a workspace per product instead, the third is where Free stops. There is also no importer, no export, no reporting and no time tracking, and Kevta is in beta.

When a text file still wins

If one project, one repository and no gaps describes your life, stop here. GitHub's Free plan includes Issues and Projects on private repositories at $0 a month (github.com/pricing), in a tab you already have open. A text file is better still, and chatmasta's version of the argument on that Ask HN thread is the one worth keeping: "Keep the single text file as long as you can, because that way at least the cost of your issue is contained in one place and you don't need to pay even more context switching tax."

If you have several contexts but few issues, Linear's Free plan meters on a different axis from ours and is a genuine option: $0 for 250 issues and 2 teams, with no limit on members (linear.app/pricing).

And there is a failure no tool fixes, which several replies told lukev directly: if the problem is that you keep changing your mind about what matters, no board resolves it. A tracker records a decision. It does not make one.

If both conditions describe your week, this is the shape we think fits, and you can join the waitlist for an early invite, a founding-member price at launch and a direct line to what we build next.