Operazioni Solitarie su Larga Scala: Gestire Decine di Progetti con un Piccolo Team
There is a point in the growth of any small operation where the number of active projects exceeds what can be held in working memory. Orders need monitoring across multiple marketplaces. Infrastructure requires regular maintenance. New features are in development. Clients are asking questions about shipments, compliance, and projections. Everything is real work, and the hours available do not scale with the number of projects.
Most advice about managing this situation assumes you will hire more people. That is often the right answer. But it is not always the right answer, particularly when the projects are diverse — different tech stacks, different domains, different operational tempos — and when the incremental revenue from any single project does not justify a dedicated headcount. Small teams managing dozens of projects need systems, not just more people.
This post describes the approach we use: the tooling decisions that have held up over time, the operational principles that reduce coordination overhead, and the tension between building new things and maintaining what already works.
The Central Tension
The fundamental tension in small-team operations at scale is between the two things that compete for the same resource — attention. Building new things requires uninterrupted, exploratory attention. Maintaining existing systems requires reactive, responsive attention. These are not compatible modes, and switching between them has a cost that does not appear in any project management tool.
But in reality, most operational problems do not come from failing to choose one mode over the other. They come from not choosing — from allowing the boundary between maintenance and development to blur until neither gets done properly. The maintenance backlog grows because development work crowds it out. The development work stalls because maintenance interrupts compound. Both suffer.
The discipline we apply is time allocation by explicit design rather than by default. A defined proportion of each week is reserved for maintenance — infrastructure reviews, dependency updates, monitoring checks, client reporting — and is not available for development work regardless of what is currently exciting. Development time is protected from maintenance interruptions except for genuine incidents. The allocation is not rigid to the minute, but it is real enough that it does not get consumed silently by other priorities.
Tooling Choices
The principle we apply to tooling is: standardize ruthlessly within a stack, and minimize the number of stacks. Every additional tool is a surface for something to break, a thing to learn, a potential point of dependency that can hold up unrelated work when it has problems. The cost of a tool is not its license fee — it is the ongoing attention cost of everything that involves it.
For infrastructure, we run Docker on a single provider. Not Kubernetes, not a multi-cloud architecture, not a service mesh. Docker Compose on a well-specified VPS handles the workload for everything we currently operate, with clear documentation that makes recovery from failure straightforward. The operational complexity of a more sophisticated infrastructure would cost more in maintenance attention than it would save in any other dimension.
For application development, we standardize on a small set of technology choices: TypeScript for web frontends, Python for backend services and data pipelines, PostgreSQL (often TimescaleDB) for persistent storage, Redis for queuing and caching. New projects default to this stack unless there is a compelling reason to deviate. The compelling reason must be stated explicitly and weighed against the cost of maintaining a non-standard stack in the long run.
For project and task management, we use a system that is simple enough that the tool itself does not become a project. The overhead of maintaining a complex project management system often exceeds the overhead of the projects it is meant to coordinate. The structure that matters is: each project has a defined current state, a defined next action, and a defined owner. Everything else is optional detail.
The discipline here is resisting the pressure to adopt new tools that solve problems you do not yet have. A new observability platform, a new deployment pipeline, a new team communication tool — each of these is presented as a solution. But in reality, the adoption cost is real and immediate, while the benefit is speculative and deferred. We evaluate new tooling against the question: what specific problem does this solve that we currently have, and is solving it worth the adoption and maintenance cost?
Async-First Operations
Synchronous communication — calls, meetings, real-time chat — has a fixed cost per interaction regardless of the complexity of the topic. It also has a scheduling cost that often exceeds the cost of the interaction itself. For small teams with diverse project portfolios, the overhead of synchronous coordination can consume a disproportionate share of the available working time.
We operate on an async-first principle: default to written communication, default to documentation, and reserve synchronous interaction for situations where written communication is genuinely insufficient. A question that can be answered by reading documentation should be answered by reading documentation, and if the documentation does not exist, writing it is the response to the question — not a synchronous call that answers the question for this instance but leaves the next instance unanswered.
The practical expression of this principle is that decisions are made in writing. When a significant technical or operational decision is made — a choice of database, a change to a deployment process, a modification to a client workflow — the decision is documented with the reasoning, the alternatives considered, and the outcome expected. This documentation is not for posterity. It is for the next time the same question arises, which in a multi-project operation with a small team happens more often than anyone expects.
Status updates are written and scheduled rather than verbal and reactive. Each project has a brief weekly state — current status, recent changes, upcoming work, and any blockers — that is written rather than reported in a meeting. The act of writing the update often reveals issues that would not have surfaced in a verbal check-in, because writing forces the level of specificity that makes problems visible.
Build vs Buy
Every tool you build is a project you commit to maintaining indefinitely. This is easy to forget when the build decision is made, because at that moment the cost is the construction cost and the benefit is the capability the tool provides. The ongoing maintenance cost is not visible until later, but it is real and it compounds.
We apply three criteria to build-vs-buy decisions. First: does the tool exist in a form that solves the problem adequately? Adequate is not perfect. A commercial tool that solves ninety percent of the problem well is almost always preferable to a custom tool that solves one hundred percent of the problem at the cost of ongoing maintenance, because the ten percent gap is usually smaller than the ongoing maintenance cost of the custom tool.
Second: does the problem require knowledge of our specific data or systems that no external tool can have? Data pipelines, business logic, and integrations between systems we control are candidates for building. Generic functions — email delivery, payment processing, authentication, monitoring dashboards — are candidates for buying unless the commercial options are genuinely unsuitable.
Third: is the data involved something we are willing to share with a third-party service? Some operational data — order details, customer information, financial records — should not transit through commercial services that log, analyze, or use it for their own purposes. Self-hosted solutions for these functions are justified on privacy grounds even when commercial alternatives are technically superior. We self-host our analytics, our Supabase backend, and our monitoring stack for this reason.
But in reality, the most expensive build decisions we have made were not obviously wrong at the time. They looked like reasonable custom tools for specific needs. The cost became apparent eighteen months later when the tool needed updating to accommodate a dependency change, or when a new team member needed to understand a codebase with no external documentation, or when a bug in the custom tool blocked a client deliverable and there was no support channel to escalate to. The lesson is not to never build. It is to be honest about the lifetime cost, not just the construction cost.
The Portfolio View
Managing dozens of projects simultaneously is easier when each project is understood as an element of a portfolio rather than as an independent obligation. A portfolio has some projects that are compounding — generating returns that grow over time with relatively low ongoing investment — and some that are flat or declining. The resource allocation question is different for each.
Projects that are compounding deserve maintenance investment to protect what is working, but rarely need significant new development. An e-commerce operation with stable organic rank, healthy review profile, and reliable logistics has earned its return. The job is not to improve it but to not break it. This is a fundamentally different posture from a project that is still being built — and it requires less attention, which frees capacity for the projects that are not yet compounding.
Projects that are not compounding need a clear assessment: is the trajectory likely to improve with additional investment, or is it time to accept the outcome and reallocate? Small teams with many projects are particularly susceptible to the sunk cost fallacy — continuing to invest in projects that are not working because of the effort already spent on them. The portfolio view makes this failure mode more visible, because it forces a comparison: the attention spent maintaining a stalled project is attention not available to projects that could compound.
The Real Bottleneck
The conventional view of small-team scaling constraints focuses on money and time. More projects need more money to fund them and more time to execute them. This is true but incomplete.
The binding constraint for a small team managing diverse projects across multiple domains is attention — specifically, the quality of attention available for decisions that require context. Routine operational tasks can be systematized, delegated, or automated. Decisions about what to build next, how to respond to a market change, whether to enter a new marketplace, or whether a technical approach is sound require genuine judgment from someone with full context. That kind of attention does not scale linearly with team size, and it cannot be systematized away.
The implication is that the most important leverage point in small-team operations is not efficiency — doing the same things faster — but selectivity: choosing which things to do in the first place. A project that requires constant attention to remain viable is not a cheap project even if its direct costs are low. A project that operates reliably with minimal intervention is a more valuable portfolio element than its revenue suggests, because it is not consuming the attention that higher-judgment work requires.
We make this explicit in project selection. Before committing to a new initiative, we estimate not just the construction effort but the steady-state attention cost: how many hours per week will this require to operate once it is built? Projects where the steady-state attention cost is high relative to the return are less attractive than they appear when only the construction cost and the potential upside are considered. The attention budget is finite, and unlike money or time, you cannot buy more of it.
Approfondimenti Correlati
- Distribution Engineering: Building Systems That Sell So You Don't Have To — the underlying principle behind building low-attention operational systems
- Over a Hundred Docker Containers: Our Monthly Health Check Routine — the maintenance discipline that keeps infrastructure overhead predictable
- Building an Amazon Data Warehouse with FastAPI and TimescaleDB — an example of a build decision and the data infrastructure behind the portfolio