Freelancers get sold project management software built for teams of twenty, and then spend a Sunday configuring workspaces, statuses and custom fields for a business consisting of one person and three clients.
It is the wrong tool, and not because it is bad. It is built to answer questions a team has — who owns this, what is blocked, what is the status — and those questions have trivial answers when the team is you. Who owns it: you. What is blocked: nothing, you just have not done it.
The questions a solo practice actually has are different, and smaller.
The four questions
Almost everything you need from a system is one of these.
What did I promise this client, and when? The commitment question. It is the one that damages relationships when it goes wrong, and it goes wrong through ordinary drift rather than negligence — a thing said on a call in week two that neither of you wrote down.
What did we agree it costs? Scope. The most expensive failure in freelancing, and almost always a documentation failure rather than a negotiation one.
Where did we leave it? The context question. Six clients means five stale contexts at any moment, and reconstructing one from memory before a call is where the time goes.
What am I owed? Invoices sent, invoices paid, invoices quietly not paid for eleven weeks.
None of those needs a Kanban board with swimlanes. They need writing things down in a place you can find again.
The shape that works
One note per client. Not a folder, not a project, not a database — a note, which grows.
At the top: the boilerplate. Rate, contact details, how they like to be invoiced, the thing they told you in the first call that explains everything about how they work. Under that, dated entries, newest first, each a few lines: what was discussed, what was agreed, what you owe them, what they owe you.
That is it. It looks too simple to be a system, which is why it survives — there is nothing to maintain, and adding to it costs four lines after a call.
Why one note and not one per meeting: because the question you ask is almost always "where are we with this client", not "what happened on 14 March". A single scrolling note answers the common question directly and the rare one via search. A file per meeting inverts that, and you spend your time in a list of files instead of in the content.

The one discipline
Write the entry immediately after the call. Not later that day.
This is the entire method and the only part that requires anything of you. Four lines, in the two minutes while you are still holding the conversation. What was decided, what changed, what you now owe. Later that day, you will remember perhaps half of it, and the half you lose is disproportionately the commitments, because those were said quickly at the end while both of you were wrapping up.
Everything else in this post is optional. This is not.
Where the tasks go
Promises become tasks, and they should leave the client note.
A commitment buried in a paragraph in a client note is not tracked — you will only see it if you happen to reread that note. The line you wrote goes in the note as a record; the task goes in the to-do list with a date on it, because that is the thing that will surface on the right day.
This is where the type-it-as-a-sentence capture matters more for freelancers than for most people, since the moment you have to write it down is thirty seconds after a call, and any friction there means it does not happen.
The board view earns its place too, but not as project management — as one glance across clients: what is waiting on me, what is waiting on them, what is done and unbilled. Three columns. Personal kanban, applied to a business.
What to write down that people do not
The scope conversation, verbatim-ish. "Agreed the redesign covers the marketing pages, not the app." One sentence, written the day it was said, has settled more disputes than any contract clause, because it is not a legal instrument — it is a shared memory that turns out to be one-sided otherwise.
Every "could you also". They are not scope creep individually; they are scope creep in aggregate, and you cannot make the case in month three without a list.
How long things actually took. Not for billing — for quoting. The single most valuable dataset a freelancer can have is what their own estimates are usually wrong by, and it takes one number per project to build.
When you sent the invoice. With a date. The chase conversation is much easier when you can say which day.
What still needs a real tool
Being straight about the boundaries.
Invoicing and accounts. Use proper software. This is not a notes problem; it is a legal and tax problem, and the tools are cheap.
Contracts. Also not this. A note recording what you agreed is a memory aid, not an agreement.
Time tracking, if you bill hourly. A dedicated timer is better than anything you will improvise, though a focus timer pointed at a task will give you a rough count of sessions if you mostly want the shape rather than the invoice line.
Anything involving a team. The moment a second person needs to see status, everything above stops working and shared software starts making sense.
The honest version
If you are running eight simultaneous projects with subcontractors and deliverable dependencies, that is a small agency and it needs agency software. The advice here is scoped to one person with a handful of clients, which is the majority of freelancing and the case most tools are not designed for.
For that case the system is: one note per client, four lines after every call, promises moved to a dated task list, and a board when you want the overview. It fits in any app that has notes and tasks in the same place, and it fails in any arrangement where writing the four lines means opening a second app.
Cyanote keeps them in one window: notes that nest and link, tasks that take a date out of a typed sentence, a board view of the same tasks, and full-text search across every client note you have ever written. One SQLite database on your own Mac, no account, and a readable JSON export — which for client work is not a philosophical point but a practical one, since the confidential notes of a working practice are exactly the material that should not require somebody else's server to remain readable.