The Freelancer system

I discovered Johnny Decimal yesterday and I am very intrigued and eager to start implementing it. I am, however, running into the issue described in 13.01 Multiple projects. As this part of the website is not complete yet, I was wondering what the best practices are for a multi-client, multi-project-per-client setup would be.

The projects approach as outlined in 13.01 doesn’t entirely feel right as I’d lose all client-project hierarchy, and my projects would not be part of my company Johnny Decimal system where everything else would reside.

Does anyone have more experience with this? Or tips & tricks?

Yeah sorry, still one on the to-do pile.

General advice from me – not a freelancer, but my partner was – is that I think this pattern requires a template.

Every job is similar, right? If you do graphic design then they’ve all got a spec, some sort of agreement/contract, quote, the art files, your output, reviews, and the final delivered product. Each job should be mostly similar to the last in structure if not content.

So design a small system to fit one project, and use the multi project notation to spin up a new project for every job. This is the exception to the ‘fewer projects is better’ rule. Because every project is essentially the same. And they’re all fairly small, keep it tight.

You would then probably have one unique project for the managing-the-business side of things. There’s no client stuff in there, that’s all internal.

Happy to help work through this one, I need to document it properly.

Thank you very much for the very quick, yet thorough, answer.

I was thinking about a setup along the same lines: a general project for managing, the business, along with a whole bunch of client projects.
The projects setup would look like this:

P01-P99: Personal projects
B01-B99: Freelancing business
- B01: Business management
- B02: Project A, client Alpha
- B03: Project B, client Beta
- B04: Project C, client Alpha

The one thing nagging me, however, is that a file management system is supposed to make it very easy to know where anything should be. The natural client > project hierarchy gets lost in this project-based system outlined above, making it harder to navigate to a specific project, as they’re all thrown on a big pile (B02-B99).

Another approach I was thinking about is to dedicate a single category to client projects, giving each project a unique ID. The reasoning behind this is that - in my case - every project has a limited number of files anyway. There won’t be much of a hierarchy on a lower level. So everything is pretty organized when I get up to the project level, and it’ll be clear where to find project-related files when I need them. This way my JD system can be simpler, I’ll just use it up to the project level and keeping things tidy in the project folders itself.
This setup would look like this:

P01-P99: Personal projects
B01-B99: Freelancing business
- B01: Business
    - 70-79: Clients and projects
        - 71: Clients
            - Client Alpha
            - Client Beta
        - 72: Projects
            - 71.01: Project A, client Alpha
                - photos
                    - photo1.jpg
                    - photo2.jpg
                    - photo3.jpg
                - spreadsheet.xlsx
                - schedule.xlsx
                - requirements.docx
            - 71.02: Project B, client Beta
            - 71.03: Project C, client Alpha

As I’ve never set up a JD system, I’m not sure how to think about the tradeoffs of doing this. Do you have any advice on that?

1 Like

I’ve got an interesting solution to this but it’s longer than I can easily type here. Give me a couple of days and I’m going to experiment with putting this up on YouTube.

1 Like

Wow that’s great, thank you!
I guess this is one of the most common issues people are having with the framework: what if 2 dimensions are not enough by the nature of the tasks at hand. In this case it’s just presented as the freelancer system.

Haven’t forgotten! But we went to test a recording setup and two days later I’ve totally reorganised the office. :smiley:

Before and after attached. This worked out really well: the office had a bit of the previous jobs mentally attached – my full-time, working-for-someone else life – and now it feels like a new space for this new life as full-time Johnny.Decimal. So, thanks!

Before – not much room to set up tripods and lighting


After – that’s mine on the left, Lucy on the right

…and a nice clear wall to the left to shoot against. It’ll be turned in to a massive whiteboard tomorrow.

Hah, thanks for the update! That’s really cool. Such a nice and clean setup! Much better to shoot video I imagine. I’m very much looking forward to it, but take your time of course. Any insights are much appreciated.

Alright! The first Johnny.Decimal YouTube Q&A is up.

I was expecting this to be a five minute video and … yeah, it’s half an hour. Sorry! :stuck_out_tongue: But I hope it’s helpful, it certainly has me closer to an official solution for this sort of pattern.

All feedback welcome!

1 Like

Thank you very much, this is exactly what I needed. I love how the JD system can be customized enough to accommodate varying use cases, yet is rigid enough to provide the much needed structure we’re all after.

It’s a great video, if you’ve never done this before: you’re really good at presenting in front of a camera. I’m looking forward to seeing more of these videos :wink:

At the moment I’m hard at work to set up a JD system for myself and my businesses, so being knee-deep in this myself I have a few critical remarks which could be valuable:

Structure: before and after the decimal
In your video you state how the first part of the JD number is all about structure, where the second part is not supposed to carry any meaning.

I feel like this is not really the case in your modified structure, as modelling the ID-level folder structure after a template structure implicitly indicates there is definitely some structure there. I’ll immediately add that I don’t really mind though, as it definitely brings the organization we’re all after, which is exactly the end goal of JD.

Folders within folders
At a certain point you mentioned your stance on nested folders on the ID-level is softening a bit. I really agree with this. When designing my own system I feel like getting rid of any substructures and flattening everything out to the ID-level makes things harder to find in certain situations. Even at a deeper level there might still be some hierarchical structure that you don’t just want to throw out just to adhere to the original JD design.

A simple example in a different business (not freelancing) I’m involved with: we’ve got a whole array of products, all belonging to different product categories, so my current structure looks like this:

70-79 Customers and sales
- 72 Products and services
    - 72.01 Product group 1
        - Actual product A
        - Actual product B
    - 72.02 Product group 2
        - Actual product C
        - Actual product D
        - Actual product E
    - ...

Another example from the same structure:

30-39 Technical
- 30 IT
    - 30.01 Hardware
    - 30.02 Software
        - Application 1
        - Application 2
        - Application 3
- 31 Infrastructure and machinery

If having any subfolders would be ‘prohibited’, we would have to redesign the entire JD structure to accommodate for the extra dimension, even though it works great for practically everything else in this company.

I feel like the actual goal should be (which you do emphasize in your video) to not have ANY files at all in the structured part (areas and categories) of your JD system.
Doing otherwise would ruin the entire structure, as it removes all barriers to just drop a file somewhere without taking a little time to reflect where it actually belongs.

At a certain point you’re organized well enough and it doesn’t make sense to optimize further. I feel like this point is reached at the ID level. From my point of view the area and category really need to be structured well and thought about deeply, the ID is a bit more flexible and might or might not carry meaning, and everything after that is just over-optimization.

What do you think?

I’m sorry for the long post. It’s not entirely related to the freelancer system, but I thought it would be useful to share my feedback. Don’t hesitate to point out where you agree or disagree, I feel like I could learn a lot from this.

Hello JD!

I’m new at this, and a freelancer, and I came here from the relevant video – where about 8 minutes in, you demonstrate letting the computer sort items by creation date when you want a chronological list.

It looks like you’re still at the stage of working out new solutions, so I just wanted to share a concern: I learned the hard way that the internal file system “date created” is not durable, and can’t be relied on as part of a long-term organizational system.

Depending on the OS, these internal creation dates may be overwritten in operations like syncing files between platforms, copying files to a new machine, or restoring from a backup. You can suddenly find that all your files were created TODAY. Linux and Android don’t even use creation dates.

But the file system won’t overwrite your filenames. Since a chronological sort is so useful (and an alphabetical sort pretty superfluous in a searchable digital context), I’ve developed the habit of using a sortable ISO date at the beginning of filenames:

2023-11-27 Johnny Decimal forum comment - draft

A JD system might use sequence indicator instead, but I’d still want filenames that facilitate a chrono sort. Something akin to:

2302 Aardvark Co

rather than:

Aardvark Co  [02]

Looking forward to more details as the Freelancer/Agency Solution evolves!

Interesting, thanks for the heads-up. I hadn’t even considered that Linux doesn’t have such a concept.

Yeah it does feel a bit fragile depending on the system like that. But then we’re still left with this conflict of number vs. alphabet for those cases where I think our brains really do want to use the alphabet.

My brain might be a little atypical, but I guess the alphabet loses that battle with me. It’s convenient to navigate an alpha list by scrolling with your thumb – but if I’ve forgotten the name of something/someone, an alpha list is really no more helpful than a randomized list. I’m more likely to whittle down by timeframe: I think I first did business with whats-his-name about 2017, shortly before the big Memorable Co. project…

I think JD will lead me to simple and consistent grouping I’ve never had, but at the lowest level, I’ll want to be able to reliably sort most items by chronology. It’s helpful for finding & systematically reviewing things, and facilitates peeling from the bottom for archiving.

And I currently have 14 years worth of files that were “created” July 22, 2023 because that’s when I restored a backup, so I’m glad most were prefaced with a date. :sweat_smile:

1 Like

Came across this post as I plan out my JD system and work through the workbook. This is how I’m currently thinking about this. All my folder structures within a client project are pretty systematized and templatized (I’m a brand designer), so I feel like the idea of having subfolders within an ID (client project) doesn’t cause that much brain strain because we know exactly what to expect when we get into that ID.

My JD system encompasses work (50%) and personal life (30%) with room to grow. I really didn’t want to separate these things as work is such a big part of my life. I have other areas (the one shown is 10-19 Clients) called “Marketing”, “Business Admin”, “Design Thinking & Writing”.

Interested to hear your thoughts if you have the time @johnnydecimal

As long as they all look basically the same then yeah, that should work okay.

Lucy has this same question — she used to be a writer so she wants this ‘creative pattern’ to organise her old work — which we’ll be addressing as part of the workshop.

As it’s kinda tangential to ‘core JD’ we’ve consciously pushed it aside for now. So I don’t have anything else to tell you at this stage. Sorry! :stuck_out_tongue:

1 Like