Public tags exist to route readers, and they are covered elsewhere. A personal catalogue answers different questions entirely: which piece was that, who commissioned it, what reference did I use, where has it been published, and can I license it. Almost nobody builds one, and almost everybody eventually needs one.

The failure is predictable. After a few hundred pieces, finding a specific one becomes genuinely hard, and reconstructing the surrounding facts becomes impossible. The information existed at the time and nobody wrote it down.

What a personal catalogue answers

Practical questions rather than descriptive ones. When was this made, for whom, at what price, under what terms. What can be reused and what cannot. Where the master file is. What reference was used and where it came from, which is the record recommended in the piece on using reference.

It also answers questions about your own work: which pieces did well, which took longer than estimated, which client was straightforward. Those answers shape pricing and scheduling, and nobody remembers them accurately after a year.

Record at the moment of finishing

The only reliable time is immediately. Two minutes when a piece is finished captures everything; two months later most of it is gone. Retrofitting a catalogue is a project everybody plans and nobody completes, because it is dull and the information has already degraded.

Making it a fixed step in finishing a piece is what makes it happen. Export, back up, record the row. Three actions, done in the same order every time, and the catalogue builds itself as a by-product of ordinary work.

What to record

A date, a stable identifier matching the file name, a short description, the client or project, the rights position, where the master lives, where it has been published, and a note on references or assets used. Eight columns, most of which take seconds.

The rights column is the one that repays most and is skipped most. Being able to say confidently whether a piece can be reprinted, licensed, or included in a collection is what makes a back catalogue an asset rather than a pile of files, which is the licensing point in the piece on where the money comes from.

A spreadsheet is enough

Elaborate cataloguing software is a common trap, because it takes time to set up, imposes its own structure, and eventually stops being maintained or supported. A plain spreadsheet or text file opens anywhere, survives every software change, and can be searched and sorted immediately.

It also travels. A catalogue in a proprietary format that will not open in fifteen years is not a catalogue, which is the same durability argument as keeping archival copies of images in the piece on archiving your own work.

The catalogue is only useful if a row can be connected to a file, which means the identifier in the spreadsheet must match the file name exactly. Dates first, then a project code, then a description, is the convention that sorts sensibly and stays legible.

Once that link is reliable, everything else becomes possible: finding a piece from a vague memory, producing a client's whole set on request, or assembling a collection from a query rather than from browsing folders.

Using it for more than retrieval

A catalogue with dates and effort estimates becomes a record of how long work actually takes, which is the single most useful input to pricing and scheduling. Most artists estimate badly because they are remembering rather than measuring, and a year of rows fixes that.

It also shows patterns: which kinds of work are profitable, which clients return, which subjects you keep coming back to. None of that is visible from inside a working week.

Keeping a catalogue that actually gets kept

Use a plain spreadsheet, eight columns, filled in at the moment of finishing as a fixed step, with identifiers matching file names. Include rights and references. Then use it for estimating as well as for finding things.

Our own record-keeping approach is described in the data page.