A couple of years ago, I wrote about reorganizing my digital workspace around a single Dev folder. It worked well for a while, especially when most of my energy was going into code and side projects. Since then, my work has become messier: client engagements, product development, NuGet packages, and the business paperwork that comes with trying to run things like an actual adult.
The old structure started to creak under that load. I had client docs too close to repos, personal experiments mixed in with deliverables, and an increasing sense that the filesystem no longer matched how I work.
So I reworked it.
This post is a practical walkthrough of the folder layout I use today, centered on a ~/Projects directory for active workspaces and a ~/Business directory for business records. The goal is simple: when I sit down at the keyboard, I want to know whether I’m doing work or documenting it, and where to go next without having to think about it.
I know I switch between folder and directory, a lot
The core idea: doing vs documenting
Many file-organization systems start by grouping files by topic: finance, marketing, clients, personal, and so on. That works, but my daily behavior is driven by a different question:
Am I doing work right now, or am I documenting work?
Once I split my world that way, the structure became much easier to design.
~/Projectsis where I do the work. It contains active workspaces, technical projects, experiments, product ideas, internal initiatives, and anything else that behaves like a project with a lifecycle.~/Businessis where I keep the record. It contains contracts, invoices, reports, communications, and other business documentation that should be easy to retrieve later.
That means I can hold two ideas at once without mixing them together.
- A project can be active in
~/Projects. - The official paper trail for that same work can live in
~/Business.
Those two things are related, but they are not the same.
Why don’t I use something like ~/Business/client/projects? I keep all my business documents backed up in several ways, including Git, and I don’t want to have multiple submodules under ~/Business.
Why the old Dev folder stopped working
My old Dev folder reflected an earlier version of my work life. It made sense when I mostly needed a place for source code, packages, experiments, and a few supporting notes.
Over time, that stopped being enough.
I now have multiple kinds of work happening at once:
- Personal software projects.
- Professional software projects.
- NuGet packages.
- Business initiatives that are not software projects, but still need their own workspace.
- Client work with both a live project side and a formal record-keeping side.
The problem was not that the old structure was bad. The problem was that it answered an older question than the one I am asking now.
The old question was, “Where do my dev things go?”
The new question is, “How do I organize all the active work in my life so I can move between it without friction?”
That shift pushed me away from a single, general-purpose Dev directory toward a structure that explicitly reflects status, ownership, and purpose. The layout matches how I move through work.
The Projects layout
The center of the new system is ~/Projects.
This is the place for anything that is actively being shaped, maintained, explored, or moved through a lifecycle.
Here is the high-level structure:
~/Projects
inbox/
active/
personal/
professional/
nuget/
other/
paused/
personal/
professional/
nuget/
other/
archive/
personal/
professional/
nuget/
other/
templates/
example-project/
src/
infra/
docs/
ops/
research/
scratch/The key design choice here is organizing the top level by status first, so the first question is always what state something is in.
That means I don’t start by asking whether something is personal or professional. I start by asking what state it is in: active, paused, archived, or unsorted.
inbox/is for things I just created or have not fully sorted yet.active/is for current work.paused/is for projects I am intentionally not touching right now.archive/is for things that are done, abandoned, or retired but still worth keeping.templates/is for starter structures.scratch/is for rough experiments and disposable work.
This works well for me because the first thing I want to know is not “what kind of thing is this?” but “am I actually working on this right now?”
Why status comes first
This was the biggest design decision because it determines how every folder choice starts.
I considered organizing the folder tree by category first, using top-level folders like personal/, professional/, and nuget/. This matched an older mental model and mirrored parts of my previous Dev folder.
When I thought about how I actually navigate, that system felt backward.
When I am switching contexts, the first filter in my head is almost always status.
- What is active?
- What is paused?
- What is done?
- What is still just an idea?
Only after that do I consider whether something is personal, professional, or package-related.
So the folder tree mirrors that thinking, keeping the status question in the foreground and the category question in the background.
Inside each status folder, I then split work into categories:
personal/professional/nuget/other/
That second layer preserves the distinctions I value without forcing them to dominate the whole structure.
Category meanings
Inside active/, paused/, and archive/, the category folders are straightforward once the status is clear.
personal/
This is where personal projects and initiatives live. Some are software, some are not.
Examples:
~/Projects/active/personal/Archimedes
~/Projects/active/personal/home-maintenanceprofessional/
This is where client work, business initiatives, products, and internal company work live.
Examples:
~/Projects/active/professional/CabinTrailSoftware/CTS-Website
~/Projects/active/professional/CabinTrailSoftware/rebrand-2026
~/Projects/active/professional/Clerk/DotNet-Documentaionnuget/
This is where package-oriented projects live. I create internal, reusable tools, so it’s easiest to have a dedicated folder as a NuGet source.
Example:
~/Projects/active/nuget/JsonLoggingExtensionsother/
This is the escape hatch. I try not to overuse it, but it is helpful for things that do not cleanly fit anywhere else.
Naming rules: PascalCase vs kebab-case
I wanted the names to carry meaning, so I settled on a simple rule.
PascalCaseis for software projects that live in git and are intended for GitHub or Gitea, as well as proper names.kebab-caseis for projects that are private, local, document-oriented, or otherwise only meaningful to me.
That gives me a lightweight visual signal without including another layer of folders or metadata.
Examples:
~/Projects/active/personal/Archimedes
~/Projects/active/professional/CentralRise
~/Projects/active/nuget/JsonLoggingExtensions
~/Projects/active/personal/home-maintenance
~/Projects/active/professional/CabinTrailSoftware/rebrand-2026This convention distinguishes “this is probably a repo” and “this is probably a workspace or initiative,” keeping folder names aligned with how I use them.
It is not a hard law of the universe but a useful rule that makes the tree easier to scan.
Business initiatives can be projects too
One of the most useful changes in this setup is that I stopped treating “project” as synonymous with “software repository.” This lets the system hold the full range of work I do.
Some of the most important things I work on are not codebases.
A rebrand is a project. A pricing review is a project. A business process overhaul is a project. A strategy sprint is a project.
Those things still have drafts, decisions, notes, assets, and a lifecycle, so they still benefit from having a dedicated workspace.
So they live in ~/Projects too.
Example:
~/Projects/active/professional/CabinTrailSoftware/rebrand-2026That folder might contain documents, moodboards, messaging notes, reference materials, and decision logs. It does not need source code to deserve a place in the project system.
A reusable project template
I also wanted a default internal structure for new projects to avoid reinventing the layout every time.
That is what templates/example-project is for.
templates/example-project/
src/
infra/
docs/
ops/
research/Here is how I think about those folders:
src/— Source code or the primary working files.infra/— Deployment configs, Docker files, infrastructure manifests, environment setup, automation, or operational plumbing.docs/— Project docs, specs, architecture notes, decisions, planning docs, and internal documentation.ops/— Runbooks, maintenance notes, procedures, support notes, and other operational material.research/— Exploratory notes, links, experiments, comparisons, and findings that may or may not become part of the final project.
Not every project will use every folder equally, and that is fine. The point is not rigid compliance, but having a familiar place to put things as projects grow and change.
Scratch and inbox are different on purpose
I like having both inbox/ and scratch/ because they solve different problems in the same work stream.
inbox/ is for things that might become real projects but are not fully classified yet. It is a staging area.
scratch/ is for messy experimentation. It is where I drop rough ideas, quick notes, temporary files, and random spikes without pretending they are proper projects.
The distinction matters.
If something sits in scratch/ and becomes important, it gets promoted to inbox/ or directly to active/. If something in inbox/ can be deleted or promoted without guilt, that keeps the path from rough idea to real work clear.
That lets me explore without polluting the main project tree.
The business documents layout
Alongside ~/Projects, I keep a separate root for business records:
~/Business
archives/
clients/
it/
marketing/
operations/
resources/
brand_assets/
scripts/
strategy/This directory is not a workspace like ~/Projects; it is where the business record lives.
It is primarily for documents and records.
That includes things like:
- Contracts.
- Invoices.
- Client communications.
- Reports.
- Reference files.
- Marketing assets.
- Operational documents.
- Strategy material.
The client folder pattern
Inside ~/Business/clients, each client gets a standard structure.
~/Business/clients/ClientName
archive/
assets/
communications/
contracts/
invoices/
projects/
reference/
reports/That gives me predictable places for the kinds of materials that accumulate around real client work.
archive/keeps older material.assets/stores client-provided files or other useful resources.communications/holds meeting notes, exported emails, summaries, and other correspondence records.contracts/holds agreements, SOWs, amendments, and related paperwork.invoices/holds billing records.projects/holds client-facing or document-level project summaries.reference/holds stable background information.reports/holds formal updates and deliverables.
This structure is boring in the best way. Once established, it’s easy to find what I need without guessing.
How Projects and Business documents relate
The important thing is that these two roots are not competing with each other.
They are complementary.
A single engagement can exist in both places.
For example:
~/Projects/active/professional/Clerk/DotNetDocumentaion
~/Business/clients/Clerk/contracts/msa-dotnet-documentation.pdf
~/Business/clients/Clerk/invoices/2026-06-invoice.pdfThe first path is the live workspace. The others are the paper trail.
That distinction reduces clutter and makes retrieval easier.
If I want to build, I go to ~/Projects.
If I want to verify, bill, reference, or report, I go to ~/Business.
Organizing business work inside professional projects
One thing I changed during this rework was dropping the idea of a separate “business projects” directory under the business documents root.
At first, I considered keeping something like this:
~/Business/projects/The more I thought about it, the less useful it felt.
If something behaves like a real project, I want it to live in the project system.
So instead, business initiatives now live under professional/, usually grouped by business name.
Example:
~/Projects/active/professional/CabinTrailSoftware/
CentralRise/
rebrand-2026/
pricing-strategy-2026/That lets software products and business initiatives live side by side where they belong, while contracts, invoices, and records remain in the business documents structure.
A day-in-the-life example
Here is a realistic cross-section of what this looks like in practice.
In the morning, I might work on:
~/Projects/active/professional/CabinTrailSoftware/CentralRiseLater, I might switch to a business initiative such as:
~/Projects/active/professional/CabinTrailSoftware/rebrand-2026Then I might need to send an invoice or check a contract, which moves me over to:
~/Business/clients/Clerk/invoices/
~/Business/clients/Clerk/contracts/Finally, in the evening, I may pick up a personal software project like:
~/Projects/active/personal/ArchimedesThat flow feels natural because the tree clearly distinguishes between active workspaces and formal records.
What I like about this system
So far, a few things stand out.
It reflects how I actually think
This is the biggest win.
The structure holds up when I am tired, context-switching, or trying to find something quickly. This matters more than whether it follows some abstract organizational philosophy.
It scales through different kinds of work
This layout can handle:
- Software repos.
- NuGet packages.
- Private planning projects.
- Client work.
- Internal business initiatives.
- Business documentation.
I do not need a separate root for every kind of work.
It keeps records and workspaces from contaminating each other
This has reduced the most friction.
I don’t need to ask whether a contract should sit next to a source code folder. It does not belong there. It belongs in the document system.
It gives me room for both discipline and mess
templates/, inbox/, and scratch/ give me enough structure to stay organized without forcing every new idea to become a perfect project immediately.
Things I am still flexible about
I do not think this is the one true file system.
There are parts I may refine over time.
For example:
- How often I want to review
inbox/. - Whether
other/becomes useful or mostly unnecessary. - Whether some personal non-code projects deserve their own template.
- Whether some business initiatives should get a slightly different internal layout than software projects.
But those are smaller adjustments.
The important part is the system now has a clear shape.
If you want to build your own version
If you are designing a folder layout for yourself, the most useful question may not be “what categories do I have?”
It may be:
- What states does my work move through?
- What kinds of work do I need to separate?
- What belongs in a live workspace versus a permanent record?
- Which naming rules help me recognize a project at a glance?
For me, the answers led to a status-first ~/Projects tree and a document-first ~/Business tree.
That separation has made my workspace calmer, more predictable, and easier to navigate.
Honestly, that is probably the real goal of any system like this.
Not perfection.
Just less friction.
Directory structures
A quick reference for you and me.
~/Projects
inbox/
personal/
professional/
nuget/
other/
active/
personal/
professional/
nuget/
other/
paused/
personal/
professional/
nuget/
other/
archive/
personal/
professional/
nuget/
other/
templates/
example-project/
src/
infra/
docs/
ops/
research/
scratch/~/Business
archives/
clients/
ClientName/
archive/
assets/
communications/
contracts/
invoices/
projects/
reference/
reports/
it/
marketing/
operations/
resources/
brand_assets/
logo/
pdfs/
excels/
docs/
images/
ppts/
graphics/
scripts/
strategy/