You understand the principles. You know what to delete and what to keep. Now you need to see how this works in practice.
This section gives you case studies. Not to copy exactly, but to see how the principles apply across different contexts.
Your work is different from these examples. But the thinking is the same. Learn to see the principles, and you can apply them anywhere.
Before we dive into specifics, let's review the principles that guide all right-sized infrastructure:
Do you own your infrastructure or rent it?
Ownership means: your files, your data, your control. You can leave anytime. You can change anything. You're not dependent on someone else's business model.
Rental means: monthly fees, platform lock-in, feature changes you don't control. If the service goes away, so does your infrastructure.
Neither is always right. But know which you're choosing and why.
Choose ownership when: The infrastructure is core to your practice and you need long-term stability.
Choose rental when: The service is peripheral and you value convenience over control.
More features sound better. They're not.
Every feature adds complexity. Every option adds decisions. Every capability adds maintenance.
Simple infrastructure does one thing well. Feature-rich infrastructure does many things adequately.
Choose simple unless the specific feature genuinely solves a specific problem you actually have.
The best infrastructure makes no sound.
It works when you need it. It disappears when you don't. It never announces itself.
Infrastructure that demands attention—notifications, dashboards, reports, maintenance—is infrastructure that's failing its purpose.
Over-engineering infrastructure is often about trust.
You don't trust yourself to remember what matters, so you build comprehensive capture systems.
You don't trust yourself to make good decisions, so you build elaborate review processes.
You don't trust simplicity to work, so you add layers of backup and verification.
Right-sized infrastructure requires trusting yourself. Trusting your memory. Trusting your judgment. Trusting that you'll figure things out when you need to.
Context: Creating content while traveling. Limited physical space. Variable internet. Need for reliability without maintenance burden.
In mobile work, constraints aren't problems to solve. They're design parameters.
Limited space means: only tools that earn their space. No redundancy. No "just in case."
Variable connectivity means: offline-first infrastructure. Local files. Sync when possible, work when not.
No fixed workspace means: systems that travel. Nothing that requires specific setup. Nothing that breaks when conditions change.
Content Creation:
File Management:
Publishing:
Communication:
Context: Working with ideas, writing, research. Need to capture thoughts and develop them over time.
Most note-taking systems become their own project. Elaborate structures. Comprehensive taxonomies. Linking everything to everything.
Right-sized note-taking has one job: get thoughts out of your head so you can keep thinking.
Simple approach:
The goal isn't perfect organization. It's capturing thoughts quickly so you can return to thinking.
You don't need Asana. You don't need Trello. You don't need a Kanban board.
You need: a list of what you're working on now, and what's next.
Simple approach:
That's it. This works for individuals. Teams need more. Individuals need less than they think.
Email works everywhere. Everyone has it. It's asynchronous. It's searchable. It doesn't require special apps or platforms.
Use it more than you think you should:
The simplest infrastructure is often the oldest infrastructure.
Context: Creating with large files. Video, audio, images. Need for organization without drowning in files.
Media work generates massive amounts of data. Right-sized infrastructure manages this with a simple flow:
Capture:
Edit:
Archive:
The key: aggressive archiving. Most footage is never needed again. Archive it and move on.
Every piece of equipment is infrastructure. It needs space. Maintenance. Decisions about when to use it.
Right-sized equipment stack:
Gear accumulation happens because you're solving theoretical problems, not actual ones. If you haven't needed it in 60 days, you don't need it.
The most important infrastructure for media work isn't technical. It's temporal.
A fixed shipping rhythm—weekly, biweekly, monthly—becomes infrastructure that prevents over-optimization.
When you must ship Thursday at 9am, you stop endlessly refining. You finish and move on.
The deadline is infrastructure. Protect it.
Based on these case studies and your own context:
You've seen how principles apply across different contexts. You understand that right-sized infrastructure isn't about specific tools—it's about specific thinking.
The case studies aren't prescriptions. They're examples of how to think about your own infrastructure.
Your context is unique. But the principles are universal:
In Part 4, you'll learn how to maintain what you've built without it becoming a burden again.