I built an app to remember my own work

A client asked me what I had done for them the previous month.

It is a reasonable question. I had been working on it for weeks. And I sat staring at the screen trying to reconstruct it from commits, Slack history and closed tickets, like an archaeologist of my own month. It took me nearly an hour to assemble a five-line answer that I was not even sure was complete.

It is not that my memory is bad. It is that I never wrote anything down.

Where the context actually lives

If you work in software, the information about what you do is scattered roughly like this:

The ticket says what you were asked for. The PR says what code changed. Slack has the conversation where something got decided, buried in a thread from three weeks ago. Your editor has a branch whose name you no longer remember choosing. And the rest — why you discarded the other option, who you are waiting on, what blocked you for two days — is in your head, which is exactly the place it leaves from.

Every tool keeps a fragment and none of them keeps the story. The ticket knows it closed. It does not know you closed it halfway through because the data team changed the schema and it all had to be redone.

And so, weeks later, questions that should be trivial turn out to be surprisingly expensive:

What was I on yesterday?
What happened with this ticket?
Why did we make this decision?
What am I waiting for?
What did I do for this client last month?
What do I say in tomorrow’s standup?

None of them requires intelligence. All of them require a record that did not exist.

Why a task manager does not fix it

My first instinct was everyone’s: this is what lists are for. And I tried a few.

I started with Todoist, which is excellent at what it does: it tells me what I have to do today and keeps reminding me until I do it. But when I finished something I ticked it off and it vanished. A month later the list was spotless and I still could not say what I had done.

Then ClickUp, which is the opposite problem: it does everything. Statuses, sprints, custom fields, views, automations. I ended up spending more time configuring the system than recording work, and a log that is expensive to maintain gets abandoned in the first busy week.

The problem is that a task manager models the future. It is a list of things I am going to do. What I kept losing was the past: what happened, and why.

Those are different things and they behave differently. A to-do list has to be maintained — move items, update states, clear out the old ones — and that is a second job on top of the work. A record of what happened needs no maintenance. You write it once and you are done.

There is one detail that took me a while to understand and that ended up being the principle behind the whole product:

“Pending: review Aurora’s PR” is a state. It has to be updated, and if you do not update it, it lies.

“Aurora asked me to review her PR” is a fact. It was true when I wrote it and it will still be true three years from now.

What I needed was the second kind. Write facts, and let everything else — what is still open, what happened this week, what I am on — be computed from them.

Notion came closest. It is flexible enough to model exactly this, and I did write there for a good while. Its problem was not the shape but the place: it lives in the cloud, on somebody else’s servers. That is the one that pushed me out.

Why text files in a folder I own

I did not decide this part for technical elegance. I decided it out of distrust.

I have been doing this for nearly twenty years and I have watched enough tools die. Services that shut down, formats that become unreadable, exports that technically exist and in practice hand you a JSON file nobody can read. A work log has to outlive the application that writes it, or it fails at the only thing it has to do: remember old things.

So the log is Markdown files in a folder I own. One file per project. They open in any editor, version with Git, search with grep, copy to a USB stick and archive. If I delete the app tomorrow, the log is still there and still makes sense.

There is also a less philosophical reason: those files contain client names and internal decisions. I do not want to upload them to someone else’s service, and I do not want to have to trust anyone’s privacy policy. Them never leaving my Mac is not a feature, it is the condition.

So what is the app for?

That is the fair question, because for a while I had the files and nothing else. I wrote by hand, in Markdown, and it worked for writing.

It stopped working for reading.

With twenty-seven projects and hundreds of events, a pile of plain Markdown will not tell you what is still open across every project at once, or what you did for one client in a date range, or which ones have been silent for three weeks. That information is in the files, but it is spread across fifty places and reading it by hand costs more than it is worth.

So the app owns nothing. It is a reader. It shows the timeline day by day, derives what is still open, assembles a recap of the last day actually worked, counts activity per week and searches the whole history.

It does write, but under strict rules that come from the same distrust as before: it only appends, it never rewrites lines it did not write, it refuses any write it could not read back, and if I edit a file by hand in my editor, it notices on its own and updates. Editing the Markdown outside the app is not an edge case it tolerates. It is a normal way to use it.

What I decided not to build

This is half the product, and possibly the more important half.

Automatic priorities. I was going to infer them from the text with a local model. I measured it before building it and the agreement with my own judgement was zero — I wrote it up with the numbers in Priority was never in the text. The feature died there.

A Markdown editor inside the app. Being able to edit the files outside is a capability of the product, not a gap to close. If I add an editor, I start competing with yours and end up owning the files. The app opens the file in the editor you already use.

Deleting events. The log is append-only on purpose. It is the one operation you cannot undo by reading the file again, and a log that can be rewritten without a trace is not memory, it is a current opinion about the past.

AI, for now. It will come, but as an interface for asking questions about data that is already trustworthy. Not as a source of facts nobody wrote down. That distinction is exactly what the other post measured.

Is this useful to anyone else?

Honestly, I do not know.

I built it for me, it solves a problem I have in a fairly specific way, and it is at version 0.2. It is entirely possible that a notes file is enough for you, or that your company already has the process solved, or that you simply do not need it.

The real test is not whether you like the screenshot. It is whether I am still using it in six months, when it stops being a new project and becomes just one more thing to open. That is where it shows whether the habit holds, which is the only thing that makes a work log useful.

For now what I can say is that the client’s question no longer costs me an hour.

Noonly is for macOS, keeps everything in Markdown you own and sends nothing anywhere. It is at infante.io/noonly.