A founder can open five repositories in a weekend. Supporting five products through a difficult month is another job. Each brings promises, dependencies, customer questions, billing states, and decisions that cannot all wait for the founder’s next burst of enthusiasm. A portfolio becomes fragile when the number of active obligations grows faster than the operator’s capacity to meet them.
Limit active apps by the work they create, including interruptions and recovery, rather than by how quickly you can generate another release. There is no universal responsible app count. One complex product may exceed a solo operator’s capacity, while several narrow tools may share a manageable service model. This article models the constraint within the AI Software Factory series and our AI guides. The question is whether the next commitment fits the actual operating system, not whether the idea is attractive.
Count commitments before counting products
An app with no customers can still create work: security updates, abandoned trials, public claims, exposed infrastructure, and questions about availability. An app with paying customers adds explicit service and billing obligations. An internal tool can affect employees or business records even without an external subscription. Distinguish these states rather than placing every repository into one total.
For each product, identify the person relying on it, the promised task, its consequence when unavailable, the response commitment, and who can resolve an exception. A document-format checker that runs locally differs from a hosted reconciliation service connected to financial records. Both may have a simple interface. Their operating obligations are not comparable merely because both are called small apps.
An app registry makes those obligations visible. It should identify ownership, lifecycle state, dependencies, customer scope, and current operating concerns. A list of names and links is insufficient if it cannot tell the operator which product has an unresolved incident or an upcoming vendor migration. Count maintained commitments using that record, then inspect the actual work behind them.
A prototype can remain outside the active service portfolio if its use and exposure are genuinely bounded. Label it accurately and restrict access where appropriate. Do not call something a prototype to excuse a public sales promise. Once a buyer relies on the service, the obligation matters regardless of the internal project label.
Establish a maintenance floor for each app
A maintenance floor is the recurring work required to keep the current promise credible. It may include dependency review, access checks, billing reconciliation, backup verification, release testing, customer support, and rule maintenance. Define it for the actual product. A generic monthly checklist copied into every repository may miss the most consequential work while creating unnecessary administration.
Estimate the floor from observed time when available. If the product is new, use a clearly labeled forecast and record what would change the estimate. Support might be quiet during a friendly pilot and rise sharply when strangers arrive with unfamiliar inputs. A narrow parser may need little attention until an external schema changes. A floor should include ordinary work and a reasonable provision for foreseeable exceptions.
Separate owner-only tasks from work another person or system can perform. An automated test can detect some changes. It cannot necessarily decide whether a customer’s ambiguous record should be merged. A contractor may resolve routine setup issues but need the founder for a policy decision. The scarce resource is often judgment at the point of uncertainty, rather than total labor hours.
Do not erase the floor by moving it to unpaid evenings. If maintenance consumes twelve hours every month, those hours remain part of the business’s resource use even when no invoice records them. They can displace another product’s development, customer acquisition, or the owner’s personal time. The profit per owner hour guide examines that economic boundary.
Model capacity with a reserve
Consider a hypothetical operator with twenty-five hours a week available for the software business. Five hours go to administration and acquisition, four to planned maintenance across existing apps, and six to ordinary support and review. That leaves ten hours before a reserve. If four hours are protected for interruptions and recovery, only six hours remain for planned development. These figures are illustrative, not Salars operating measurements.
A proposed app that requires four more recurring hours would leave two development hours under the same assumptions. If it also needs a forty-hour launch, the founder cannot schedule that work as though ten spare hours remain. At two planned development hours weekly, that launch alone would take twenty weeks under the simplified model, before new delays or scope changes. They could reduce another commitment, narrow the proposed service, hire appropriate help, or delay the launch. The arithmetic exposes the decision rather than supplying a universal reserve percentage.
The reserve is not idle capacity to be filled at the first quiet week. Its purpose is to absorb the work that is difficult to schedule: an incident, a failed integration, a customer migration, or a reviewer’s absence. Some weeks will not use it. That does not prove the reserve unnecessary. Inspect actual interruptions over a meaningful period and revise the assumption when evidence supports the change.
If service commitments require immediate response, calendar availability matters as much as total hours. Four spare hours on Friday cannot satisfy a promised Tuesday response. A founder who works on the business only at weekends must design the offer around that availability or provide coverage. Average capacity does not repair a mismatch between when work arrives and when someone can do it.
Treat support as a queue
Support requests arrive unevenly. Three short questions can be easy to clear, while one ambiguous data issue can block several later tasks. Track arrivals, resolution effort, waiting time, unresolved age, and the category requiring escalation. A simple count of closed tickets can conceal a growing queue of difficult cases. The portfolio needs enough capacity to resolve the work, not merely acknowledge it.
Suppose ordinary requests consume six hours a week in the hypothetical model, but a new customer cohort adds four. The protected reserve may absorb that increase temporarily, leaving no cushion for an incident. If the increase persists, it becomes part of the ordinary workload. Update the maintenance model and acquisition pace rather than continuing to treat the reserve as a permanent source of extra support labor.
A waiting queue can reduce demand quality. Prospective customers who require an urgent result may leave, while existing customers may work around the service and generate more complicated reconciliation later. The operator can also make mistakes while switching between unfinished investigations. These mechanisms are plausible operational risks, not a quantified universal relationship. Observe whether they occur in the actual service.
Define an overload response. Stop adding customers to the affected workflow, publish realistic response expectations, triage consequential cases, and remove the recurring cause where possible. A queue is a capacity signal, not a moral failure. Ignoring it because the business is still small can turn a manageable constraint into a broken promise.
Account for correlated maintenance
Shared infrastructure can reduce repeated work. One authentication component, deployment process, or billing adapter may serve several products. But a shared dependency can also require simultaneous changes across the portfolio. An expired credential, vendor incident, or changed API can affect multiple apps at once. Savings during ordinary operation do not establish independence during a difficult week.
Draw a dependency map showing which products share external services, data stores, identity, templates, reviewers, and distribution channels. Identify the failure that would create the largest combined workload. The answer may be a person rather than a platform. If the founder alone understands every app’s reconciliation rules, an illness can expose the same concentration risk across apparently different products.
Estimate the response as a combined event. If a vendor migration needs three hours of common adapter work and two hours of verification in each of four apps, the portfolio task is eleven hours, not three. The common fix can be valuable, but each product still needs evidence that its own promise survives the change. Treating the template update as complete can leave hidden regressions in specialized behavior.
Use shared components where their contracts are stable and their testing is appropriate. Keep product-specific rules explicit. An overly broad abstraction can turn a local fix into a portfolio regression. The relevant question is whether sharing reduces the full maintenance burden, including verification and failure recovery, rather than whether it makes the architecture look like a platform.
Limit work in progress by the bottleneck
A founder can investigate several ideas without developing them all. Separate an idea queue, bounded discovery work, implementation, customer pilot, and maintained service. The limit should apply where work consumes the scarce resource. If domain review is the bottleneck, adding more coding tasks can create a pile of finished interfaces waiting for valid rules. If support is the bottleneck, launching more pilots can worsen the backlog.
Choose a proposed operating rule that can be evaluated locally. For example, permit one new customer-facing implementation while existing service queues remain within their defined response commitments. That rule is a management proposal, not evidence that one is the ideal number for every founder. Record what condition would justify changing it, such as dependable additional review capacity.
Finish a meaningful stage before beginning another commitment. A pilot should reach its review date and decision rather than remain indefinitely half-supported while the next app receives attention. Completion can mean a release, a narrower offer, a pause, or retirement. The goal is a resolved decision and clear obligations, not forcing every experiment to become a permanent product.
Keep exploratory work cheap and honest. A sketch, interview plan, or synthetic fixture can test an idea without a production deployment. Do not create a customer-facing service merely to make the work feel tangible. If the uncertainty concerns demand, another backend often supplies little relevant evidence. The portfolio benefits when the founder learns which work not to start.
Compare the next app with improving the current one
A new product has an obvious appeal: a fresh market and a clean implementation. Improving onboarding or resolving a costly exception in the existing product may look less exciting while delivering a better return. Compare both uses of the next hour. The relevant alternative is not doing nothing; it is the best available use of the same scarce resources.
Estimate the new app’s full path to a maintained outcome: validation, development, eligible acquisition, onboarding, support, and ongoing verification. For the existing product, identify a specific bottleneck and the evidence that removing it would help. Neither forecast deserves certainty. Use scenarios and a bounded next action to reduce the most important uncertainty rather than assigning precise returns to unsupported assumptions.
The software capital allocation guide develops that investment comparison. Here the portfolio constraint comes first. A financially attractive proposal may still be infeasible if it needs owner attention during hours already committed to consequential service. Cash can fund capacity only when a suitable person or process can actually perform the work and the transition is verified.
Expansion should not rely on a temporary absence of problems. A quiet week after launch may reflect low usage or a friendly cohort. Inspect recurring use, acquisition consistency, support distribution, and dependency changes before concluding the service is self-sustaining. The distinction between an early success and an expansion-ready operation is central to one software winner first.
Include money without confusing it with capacity
A product can generate enough revenue to cover hosting while consuming all of the founder’s judgment. Another can require little time while failing to cover its cash costs. Keep money and attention in separate columns so neither hides the other. The SBA’s business management guidance discusses financial records and cash-flow projections; those tools complement, rather than replace, a capacity plan.
Distinguish cash received, recurring-revenue measures, operating contribution, and funds available for future commitments. A prepaid subscription creates an obligation as well as cash. Spending all of it on a new launch can leave the operator without resources to provide the service already purchased. The exact accounting and contractual treatment depends on the arrangement, but the operating need to fund delivery remains.
Put predictable renewal costs into the plan: domains, hosting, required tools, specialist review, and any support coverage. Include a downside condition such as a major customer leaving or an integration requiring repair. A portfolio with several small revenues can still share one expensive risk. Diversification is not established by counting logos when all products depend on the same buyer channel or vendor.
If hiring is proposed, include recruiting, onboarding, supervision, and backup coverage. Ten contracted hours do not automatically become ten freed owner hours. The person may need decisions, incomplete documentation may cause rework, or the role may not cover consequential exceptions. Test the transfer of a defined responsibility before assuming the founder’s entire bottleneck has disappeared.
Pause or narrow before service degrades
When capacity falls short, the first response need not be closing every app. Narrow eligible inputs, stop accepting a difficult customer category, reduce an unsupported response promise for future buyers, or pause new acquisition while clearing existing work. Honor existing terms or resolve them appropriately. The adjustment should reflect the cause rather than simply moving the queue to another inbox.
The existing Wealth guide to expanding, revising, or retiring an offer uses demand, contribution, delivery, and capacity to choose an action. Software adds dependencies and data obligations, but the same practical discipline applies: growth should preserve the promise, and a pause should address the constraint. A public launch announcement is not a reason to keep adding obligations.
Retirement deserves a separate process covering customers, billing, records, data, integrations, and retained lessons. The app kill engine specifies that decision. Do not label an app retired merely because its repository is archived. If subscriptions continue or customers still depend on access, the service obligation remains active until resolved.
Review the portfolio on a regular cadence and sooner when an overload trigger occurs. Use current queues and commitments rather than memory. Decide which work enters, which work finishes, and which work stops. An explicit limit can be uncomfortable when ideas are abundant, but it protects the business’s ability to make useful promises and keep them.
What Would We Do at Salars?
We would propose an attention budget before allowing a second maintained customer-facing app. No current Salars software portfolio workload, support history, or staffing capacity is established here. The first budget would therefore label forecasts clearly and collect actual time by task category during a bounded pilot. We would distinguish ordinary support from interruptions rather than assume quiet operation proves low maintenance.
The registry would identify each proposal, experiment, pilot, maintained service, paused service, and retirement in progress. A named owner would be accountable for the maintenance floor and exception queue. Salars Forge remains a proposed system; it would make those commitments visible rather than automatically approve more launches because a template can create them.
We would reserve time and cash for current promises before allocating either to the next product. A proposed shared-dependency migration would include verification in every affected app. If a new candidate exhausted support capacity, we would narrow or pause its intake while resolving existing commitments. Candidate apps such as Supplier Margin Guard and Merchant Revenue Guard remain proposals, not evidence that these operating requirements have already been met.
Our proposed expansion gate would require a credible maintenance estimate, appropriate support coverage, a manageable interruption scenario, and enough remaining capacity for the next bounded step. We would revise the gate as local evidence accumulates, with its scope and limits recorded. The aim would be a small number of dependable assets that earn the next investment, rather than a large catalog whose obligations the operator cannot meet.
Sources
- SBA Manage your business: financial management and cash-flow planning, not a universal responsible app count.
Source checked October 7, 2026. Capacity figures, migration arithmetic, work limits, and Salars operating gates are hypothetical or proposed. They are not measured staffing requirements, observed Salars workloads, or guaranteed portfolio outcomes.
Loading comments…