Keeping monthly overhead low while running a portfolio of apps

Running several live applications as one person is only possible if the recurring cost of doing so stays low, and that does not happen by accident — it is a consequence of specific architectural and operational choices. This post is about the software-overhead side of running a multi-app portfolio: the categories of cost that exist, the discipline that keeps them lean, and, most importantly, the architectural decisions that make the marginal cost of adding another app close to zero rather than another full infrastructure bill. To be clear up front, this is about software infrastructure only — hosting, domains, tooling — not about any other kind of business cost.

The headline insight is that overhead is mostly determined at design time, not at the spreadsheet. You do not keep costs low primarily by hunting for cheaper vendors; you keep them low by building products whose architecture does not generate expensive recurring costs in the first place. A product designed to run heavy work on a server you pay for, per user, has an overhead problem that no amount of vendor-shopping fixes. A product designed to run that work on the user's own device does not have the problem to solve. The cost discipline starts in the architecture.

The recurring software costs of a portfolio like this fall into a few clear buckets. There is hosting — the platform that serves the applications and runs whatever server-side work exists. There are domains — each property needs its address, which is a small but real recurring cost that scales with the number of properties. And there is tooling — the development and operational services that support building and running the apps. That is essentially the whole picture for a lean software operation: serve the apps, own the addresses, support the work. The discipline is keeping each bucket as small as it can be while still doing its job, and refusing to add recurring services that do not earn their cost.

What is striking about this list is what is not on it. There is no expensive managed database tier for the hub, because the content is code rather than a database. There is no per-user processing cost for the consumer tools, because they run client-side. There is no content management system subscription, no separate analytics platform with a usage-based bill, no sprawl of SaaS tools each taking a monthly bite. The lean stack is lean not because each item was negotiated down but because the architecture removed whole categories of cost that a more conventional setup would have incurred. The cheapest line item is the one that does not exist.

The single most important cost decision is that the consumer tools do their heavy work on the user's device rather than on a server. When the background remover runs its AI model in the browser, the computational cost of someone removing a thousand backgrounds is paid by their hardware, not by a server bill the operation has to cover. When the visualizer encodes a 4K video client-side, the cost of that encode is the user's electricity, not a render-farm invoice. This is the difference between a marginal cost per use and no marginal cost per use, and at the scale of a free tool with many users, that difference is the difference between a sustainable operation and one bleeding money on every interaction.

This is why the architecture is the cost strategy. A server-side version of these tools would have a cost that grows with usage — more users means more server load means a bigger bill — which is exactly the dynamic that forces free tools toward usage limits and paywalls to cap the bleeding. The client-side version has a cost that is essentially flat regardless of usage, because the expensive part runs on hardware the operation does not pay for. Adding more users to a client-side tool costs almost nothing; adding more users to a server-side tool costs proportionally more. For a free product that wants to grow, that distinction is decisive, and it was decided in the architecture long before any cost showed up.

The most important and least intuitive point about keeping costs low is that overhead is mostly determined when you design a product, not when you review the bill. The instinct, when costs are too high, is to go looking for cheaper vendors — a better hosting deal, a discounted service — but vendor-shopping operates at the margins of a cost structure that was fixed by architecture. A product designed to run heavy computation on a server, per user, has a cost that grows with usage no matter how good a hosting rate you negotiate, because the expensive thing is structural. A product designed to run that computation on the user's device has no such cost to negotiate down, because it does not exist. The decisive cost decisions are made in the architecture, long before any invoice arrives.

This reframes cost discipline from a procurement activity into a design activity. The question that matters is not "how do I pay less for this recurring cost" but "how do I build so this recurring cost does not exist." The former saves a percentage; the latter removes a category. For a small operation, the difference is enormous, because a category of cost removed is a category that never has to be managed, monitored, or worried about again, whereas a cost negotiated down is a cost that still scales with usage and still demands attention. The leanest stack is not the one with the best-negotiated bills but the one with the fewest bills to negotiate, and that leanness is an architectural achievement decided at design time, not a spreadsheet achievement found later.

The most striking thing about the cost structure is the list of expenses that a more conventional operation would carry and this one does not, because the architecture removed them. There is no expensive managed database tier for the content hub, because the content is code rather than data fetched from a database. There is no per-user processing cost for the consumer tools, because they run on the user's device. There is no content-management-system subscription, no separate usage-billed analytics platform, no sprawl of SaaS services each taking a monthly cut. These are not costs that were minimized; they are costs that were designed out of existence entirely, which is a categorically better outcome than reducing them.

The reason this matters so much is that each non-existent cost is also a non-existent source of complexity, failure, and attention drain. A database you do not run cannot go down, cannot need scaling, cannot require backups, and cannot send a surprising bill. A per-user processing cost you do not have cannot force a paywall when usage grows. Every category of cost removed removes not just the money but the entire operational burden that comes with managing that category, which for a one-person operation is often the more valuable saving. The architecture's gift is not primarily cheaper bills but fewer things to operate at all, and the cheapest, most reliable component of any system is the one that was designed not to need to exist.

For a portfolio operation, the single most important cost figure is not the total monthly spend but the marginal cost — what it costs to add one more user, or one more app — because that is the number that determines whether the operation can grow and experiment freely. A high marginal cost per user means growth is expensive and has to be capped, which is what forces usage limits; a near-zero marginal cost per user means growth is nearly free, which is what allows unlimited use. The client-side architecture drives the marginal cost per user toward zero, because the expensive work runs on hardware the operation does not pay for, which is the precise property that lets the tools be free and unlimited rather than gated.

The same logic applies to the marginal cost of another app, which the architecture also keeps low: a new hub surface inherits the existing single application's infrastructure, and a new client-side tool adds no per-user server cost, so the main genuinely new recurring expense is a domain. Focusing on marginal cost rather than total spend is what reveals why the portfolio strategy is viable: it is not that the total is small in absolute terms, but that adding to it costs almost nothing, which means breadth is affordable. An operation with high marginal costs must stay narrow to control spending; an operation with near-zero marginal costs can afford to be broad and experimental. The marginal cost is the number that decides which kind of operation you can be, and architecting it toward zero is what unlocks the experimental, multi-app model.

Monetary overhead is the obvious cost of running apps, but there is a second, less visible recurring cost that matters as much for a solo operation: complexity. Every service, database, and moving part in a stack is not only a line on a bill but a thing that must be understood, monitored, kept updated, secured, and debugged when it misbehaves — a standing draw on attention that does not show up as a dollar figure but is just as real. For a one-person operation where attention is the scarcest resource, complexity overhead can be the more binding constraint, because money can sometimes be found while attention cannot be manufactured. A lean stack is lean in attention as well as dollars.

This is why the architectural choices that remove monetary cost categories are doubly valuable: they remove the corresponding complexity at the same time. A database you do not run is not just a bill you do not pay but a system you do not have to understand, monitor, back up, or fix. A content-management system you do not use is not just a subscription saved but an interface you do not have to maintain and a failure mode you do not have to handle. Each removed category subtracts both its monetary cost and its complexity cost, and for the operator the complexity saving is often what actually makes running several apps feasible. The leanest operation is not just the cheapest but the simplest, because simplicity is what one person can actually hold and operate, and complexity is a cost that compounds against a solo operator faster than money does.

A lean stack is not only cheaper and simpler but more reliable, because reliability is largely a function of how many things can go wrong, and removing moving parts removes failure modes. Every component in a system is something that can fail, and the failures interact in ways that grow harder to reason about as the number of components grows. A stack with a separate database, a content system, an analytics platform, and a sprawl of services has many independent things that can break and many ways their breakages can combine; a stack that has designed those components out has correspondingly fewer ways to fail. The most reliable component is the one that does not exist, because it cannot break, cannot be misconfigured, and cannot interact badly with anything else.

For a solo operation with no one on call, this reliability-through-simplicity is especially valuable, because every failure is the operator's problem to diagnose and fix, usually at an inconvenient time. A stack with few moving parts fails rarely and, when it does, fails in ways that are tractable to understand because there are not many interacting components to consider. A complex stack fails more often and in more confusing ways, which for one person is a recurring tax of incidents and debugging that competes directly with building. Designing for few moving parts is therefore designing for the operator's peace of mind as much as for cost, and it is part of why the lean, client-side, code-as-content architecture is not just economical but operationally calm — there is simply less that can go wrong, which is exactly what a one-person operation needs.

The ultimate payoff of low overhead is not the money saved but the freedom it buys, because an operation with low fixed costs has options that a high-cost operation does not. When the recurring cost of running everything is small, the operation does not need much revenue to sustain itself, which means it is not under pressure to monetize aggressively, can afford to keep products free, can take time to let experiments play out, and can survive lean periods without crisis. Low overhead is what lets the operation make decisions on the merits rather than under financial duress, which is a strategic advantage that compounds across every choice.

This freedom is what connects the cost discipline to everything else the operation does. The free-first model is possible because low overhead means ad revenue is sufficient; the experimental app-testing-lab model is possible because low marginal cost means experiments are cheap to run; the willingness to kill products that do not work is easier because little recurring cost was sunk into them. High overhead would constrain all of these, forcing monetization, limiting experimentation, and making each product's cost a reason to keep it alive past its usefulness. By keeping overhead structurally low, the operation preserves its freedom to operate the way it wants to rather than the way costs would force it to. The cheapest stack is the one that gives the operator the most room to make good decisions, and that room — not the dollar saving itself — is the real return on building lean.

The same architectural choices mean that adding another app to the portfolio does not add another full infrastructure stack. A new hub surface is a new section in the single existing application, so it inherits the hosting, the deploy pipeline, and the shared infrastructure rather than requiring its own — the marginal hosting cost of another section of one app is negligible. A new client-side tool runs on the user's device like the others, so it adds no per-user processing cost. The main genuinely new recurring cost of another property is its domain, which is small. This is what makes a portfolio strategy viable for one person: the architecture is designed so that the cost of breadth is low, which means the operation can afford to run several experiments at once without each one carrying the overhead of a standalone business.

That low marginal cost is what closes the loop with the app-testing-lab model. The lab works by building many small things, shipping them, and keeping the ones that earn their place — and that only works economically if building and running each new thing is cheap. If every experiment carried a heavy recurring infrastructure cost, the lab could only afford a few bets and would have to be conservative about which ones to make. Because the architecture keeps the marginal cost of another app near zero, the lab can afford to be experimental, to run more bets, and to kill the ones that do not work without having sunk much recurring cost into them. The cost discipline and the operating model are the same decision viewed from two angles: keep the overhead structural-low so the experimentation can stay high. The companion posts cover the deploy workflow and the free-first monetization that complete the picture.