A founder with three promising apps can still make a poor investment decision. One app has revenue but expensive support. Another has a beautiful prototype but no credible route to buyers. The third could become useful after a small compatibility test. If the founder divides money equally among them, the allocation looks balanced while avoiding the real question: which next commitment is most likely to improve the business under its actual constraints?
Allocate the next dollar and hour to a defined decision, with current obligations funded and uncertainty visible. An app is an operating commitment, not a financial security. The investment analogy concerns how a software business uses cash, attention, and learning capacity; it does not promise returns or prescribe a personal investment portfolio. Within the AI Software Factory series and our AI guides, this chapter develops the operating comparison that a list of attractive ideas cannot supply.
Establish what is available to allocate
Start with a dated resource boundary. Identify the accounts, people, and period included in the decision. Separate money already received from expected payments, money committed to existing delivery from discretionary funds, and owner hours available from hours already promised. A revenue dashboard cannot establish that the entire bank balance is available for a new app. A quiet calendar cannot establish that maintenance has disappeared.
Suppose a hypothetical software business has $8,000 in the defined cash accounts. It identifies $2,500 of near-term operating commitments and chooses to protect $1,500 for interruption and transition scenarios. The initial discretionary ceiling is $4,000. If a previously omitted $700 renewal is discovered, it becomes $3,300. These numbers are an original planning exercise, not Salars finances or a universal reserve rule.
The ceiling is a limit on exposure under the stated assumptions, not an instruction to spend it. A weak opportunity remains weak when the founder has spare cash. A strong opportunity can remain unaffordable when current commitments leave little room. If expected customer receipts arrive later, reconsider the boundary when they are actually available rather than spending them twice through overlapping forecasts.
Apply the same discipline to attention. If twenty weekly hours are available and current service, administration, and interruption coverage consume fourteen, only six belong in the discretionary development plan. An experiment requiring twelve owner hours is a two-week commitment under those simplified conditions, before dependencies and timing constraints. It cannot be completed in one week merely because a budget sheet approves the cash cost.
Define the unit of investment
Do not rank whole apps when the actual decision concerns a smaller change. A maintained product might need a $500 onboarding improvement. A prototype might need a $200 demand test. A new integration might require a $2,000 implementation after a compatibility check. Those are different commitments with different evidence. Naming the next stage prevents a product’s ambitious future from absorbing unlimited current spending.
Write a proposal containing the eligible buyer and job, the change being funded, the present evidence, the uncertain mechanism, the cash and attention requirement, the review date, and the decisions the result could support. If a proposal cannot say what will be learned or delivered, it is not yet ready for comparison. “Develop the platform” is usually too broad to establish a manageable exposure.
Separate maintenance, improvement, discovery, and expansion. Maintenance funds the current promise. Improvement changes an observed bottleneck. Discovery tests whether an opportunity deserves a delivery commitment. Expansion increases the scope or volume of an already supported service. An attractive discovery proposal should not quietly consume money required to maintain paying customers, and a maintenance obligation should not be marketed internally as growth.
The software opportunity score helps organize early hypotheses. Allocation requires more than a score: available resources, current commitments, incremental economics, uncertainty, and timing. A high early score can justify a small investigation without justifying a production launch. Keep the authority proportional to the evidence rather than letting the score become an automatic spending instruction.
Build the current contribution baseline
Before forecasting improvement, understand the present app’s contribution under a defined cost boundary. List receipts or appropriately defined revenue, transaction and infrastructure costs, routine support, specialist review, acquisition costs where relevant, and other attributable expenses. State whether owner time is included and how shared costs are handled. A result cannot be compared fairly when one app includes support and another excludes it.
The software contribution margin guide develops the product-level boundary. Allocation needs that baseline and the expected change caused by the proposed investment. Avoid using total historical revenue as the investment’s benefit. A feature that adds $200 monthly contribution to an app already producing $2,000 should be assessed on the $200 increment, with any effect on existing customers considered separately.
The SBA’s business management guidance distinguishes financial records and cash-flow planning. It does not supply a universal software return threshold. Its relevance is the discipline of tracing money and obligations rather than replacing them with a model’s summary. Use records that can be reconciled, and preserve uncertainty when a cost or receipt remains unresolved.
Stripe’s subscription analytics documentation describes provider-specific recurring-revenue measures and settings. A monthly-normalized recurring figure is not cash received, accounting profit, or discretionary investment funds. Discounts, eligible subscription categories, cancellations, and expansion can affect interpretation. Translate the dashboard measure into the decision’s actual cash and contribution boundary before comparing proposals.
Compare three hypothetical commitments
Imagine three proposals within the hypothetical $4,000 ceiling. App A is a maintained invoice-checking service with an onboarding problem. A proposed improvement costs $900 plus eighteen owner hours and might add $300 monthly maintained contribution. App B is a new catalog-cleanup concept requiring $2,000 plus forty owner hours before a limited pilot. App C is a compatibility test costing $250 plus five owner hours that could determine whether a narrow reconciliation offer is technically feasible.
At an illustrative owner-time value of $50 per hour, A’s combined resource commitment is $1,800: $900 cash plus $900 of owner capacity. B’s is $4,000: $2,000 cash plus $2,000 of capacity. C’s is $500: $250 cash plus $250 of capacity. This accounting convention makes scarce attention visible. It does not turn unpaid time into a cash payment or establish a market wage.
If A’s $300 increment is achieved and sustained, its simple resource-value recovery would be six months. Its cash-only recovery on $900 would be three months if that incremental contribution becomes available cash under the model. The difference matters. The owner cannot spend the capacity value as though it arrived in the bank. Both measures also ignore timing variation, taxes, and costs outside the stated boundary.
B has no justified recurring benefit estimate yet. A confident return forecast would conceal unresolved demand, acquisition, and support assumptions. C’s immediate benefit is information, not revenue. It can deserve funding if the result changes a consequential decision and the test is cheaper than committing blindly. A, B, and C therefore cannot be ranked responsibly by one invented percentage return.
Identify the bottleneck before selecting the winner
If owner attention is the limiting resource, A’s eighteen hours and B’s forty hours compete with service and with C’s five-hour test. If cash is the constraint, the ordering may differ. If a domain reviewer is unavailable, neither implementation can proceed reliably. The scarce resource can change the choice even when the cash forecasts remain identical.
Under the six-hour weekly discretionary model, A takes at least three weeks of owner work, B six and two-thirds weeks, and C five-sixths of a week of that planned capacity. These are simplified scheduling consequences, not delivery promises. Tasks may require waiting on buyers, vendors, or review. Some hours may have to occur during business days the owner cannot cover. Include those conditions before publishing a launch date.
Ask whether the proposal removes the bottleneck or adds to it. An onboarding change may reduce recurring support, freeing capacity for later work. A new app may create more exceptions for the same reviewer. A shared component may reduce repeated maintenance while creating a correlated failure. An allocation should assess the ongoing workload, not just the work required to reach the first release.
The software portfolio discipline guide models maintenance floors, queues, and reserves. Its implication for allocation is that a project can be financially attractive and operationally infeasible. Do not solve that contradiction by assuming the owner will work longer indefinitely. Narrow the commitment, verify transferred responsibility, or choose another proposal.
Separate favorable, plausible, and adverse scenarios
For App A, imagine monthly incremental contribution of $450 in a favorable scenario, $300 in a planning scenario, and $100 in an adverse scenario. The $1,800 resource commitment has simple recoveries of four, six, and eighteen months respectively if the increments persist. Those calculations do not establish scenario probabilities. They show which assumptions control the decision.
Explain the mechanism behind each amount. The favorable case might assume more qualified customers complete onboarding and support remains stable. The adverse case might assume only a small eligible segment benefits and review cost rises. A scenario is more useful when its conditions can be investigated. Three arbitrary numbers labeled optimistic, base, and pessimistic can create a false appearance of rigor.
Add a failure case where the improvement produces no meaningful benefit or harms existing users. Ask what detects that condition and what stops further exposure. If rollback only changes the interface while customer actions have already occurred, recovery is more complicated. The investment proposal should include those consequences rather than assume a failed feature costs only its development budget.
Use probabilities only when their basis is defensible. A small pilot, personal intuition, or a model’s confident language does not establish an eighty-percent chance of success. It can be reasonable to use subjective scenarios for internal discussion if they are labeled honestly. Do not present their weighted average as measured expected profit or a guaranteed business outcome.
Evaluate time to useful evidence
Cash recovery matters, but so does the time until the next decision becomes better informed. A cheap test that produces useful evidence next week may be preferable to a large build that remains ambiguous for months. The advantage depends on what the result can change. If the test cannot alter a meaningful commitment, fast completion supplies little decision value.
App C could test whether required identifiers exist in eligible customer exports. A negative result might prevent the later reconciliation build or force a narrower offer. A positive result would support technical compatibility, while leaving demand and economics unresolved. Define both interpretations beforehand. A successful compatibility test should not automatically authorize a commercial launch.
Consider the counterfactual. Without C, would the business commit to a later reconciliation build before discovering the missing identifiers? If so, the bounded test may reduce avoidable exposure in that reconciliation proposal. This counterfactual is separate from App B’s catalog-cleanup build; no shared data dependency is established between them. If the reconciliation developer already knows the answer from verified documentation, repeating the test might add little. Information value depends on the uncertainty currently affecting the decision, not on a generic preference for experiments.
Set the test’s stopping conditions and evidence requirements. For example, establish eligible export families, independent criteria for identifier sufficiency, protected cases with incomplete data, review ownership, and the $250 plus five-hour limit. This is a proposed experiment. No such test or local result is established here. Keep the distinction between a well-specified design and evidence produced by execution.
Price the option to continue without pretending it is guaranteed
A bounded test can preserve the choice to invest later without committing to the entire product now. That is the practical option value of a staged approach. The founder pays a limited amount to reduce uncertainty and retains the ability to stop. The concept does not require assigning a precise financial option price to an early software idea.
The option has conditions. The opportunity may change while the team tests it. A vendor may alter access, a rival may introduce an adequate substitute, or the customer may lose interest. A test also uses attention that could improve an existing service. Staging is valuable when the reduced exposure and learning outweigh those costs, not simply because smaller commitments feel safer.
Write a continuation gate. After C, the business might proceed only if compatibility is demonstrated under defined conditions and independent buyer evidence supports the job. Otherwise it narrows or stops. Funding one stage should not imply a moral obligation to fund the next. A test that rejects the idea can be a successful use of the learning budget.
Avoid keeping every option open forever. Dormant prototypes still create confusion, security exposure, and occasional maintenance. Give each option a review date, owner, and retention state. If it no longer affects a plausible decision, archive or retire it appropriately. The business should retain useful evidence rather than carry unlimited half-active projects because someday they might matter.
Inspect concentration beneath the app names
Three apps can appear diversified while depending on the same marketplace, API, reviewer, cloud service, or audience. A platform policy change can then affect all three at once. Count different failure mechanisms rather than different product names. Diversification is an operational property that needs evidence about dependencies, not a label earned by owning several domains.
For the hypothetical portfolio, A and C might both require the same payment export, while B and C rely on one agency partner for acquisition. Investing in C could therefore increase existing concentration even though it adds another buyer problem. The right response could be to bound the exposure, secure another eligible route, or choose an improvement that reduces dependence.
Concentration has multiple dimensions. Customer concentration affects receipts and bargaining power. Technical concentration affects service continuity. Knowledge concentration affects review and recovery. Channel concentration affects acquisition. A simple dependency table can reveal these risks more clearly than a single portfolio score, especially when one person is the common recovery mechanism.
Reducing concentration also costs money and attention. A second cloud provider, new channel, or additional reviewer is not automatically worthwhile. Estimate the relevant failure consequence and the cost of a credible alternative. A backup that cannot be used under the actual data, configuration, or staffing conditions creates reassurance without useful resilience.
Account for obligations when reducing an allocation
Funding less development does not end a service promise. A maintained app may continue requiring support, security review, and billing administration. An app selected for retirement needs transition work. Include those costs before claiming its budget has been released. The resources become available when the obligations are resolved, not when a spreadsheet changes its status.
A prepaid customer period creates a delivery commitment that belongs in the cash plan. A pending refund or dispute may require money after new sales stop. A customer export can need technical support and verification. Those are not reasons to continue every weak product forever; they are reasons to retire deliberately and budget the exit.
For a hypothetical retirement, assume $500 of customer resolution expense plus eight owner hours at the illustrative $50 resource value. The combined planning cost is $900, with $500 of cash exposure. If continuing the app consumes $200 cash and four owner hours monthly, its combined monthly burden is $400. The simple resource comparison reaches $900 in two and a quarter months ($900 divided by $400 monthly), but the decision still depends on receipts, obligations, and actual transition timing omitted from this isolated example.
Do not use that arithmetic as a universal retirement rule. An app may have positive contribution, contractual restrictions, or customers who require a longer transition. The purpose is to include both continuing and exit costs in the comparison. Sunk development cost remains separate from future obligation cost: the former cannot be recovered by wishing, while the latter still has to be handled.
Compare software with the best external alternative
The next dollar might belong outside software. It could fund a proven service, reduce an expensive obligation, improve an existing commerce workflow, or remain available while uncertainty is resolved. A portfolio meeting that compares only app ideas can miss the best business decision. Define the scope of authority and include appropriate alternatives within it.
The existing ecommerce capital allocation guide examines store cash, inventory, time, concentration, and learning exposure. Software differs in fulfillment and maintenance, but the resource discipline transfers: apparent asset value is not spendable cash, timing matters, and a learning sample needs a defined question. A comparison should use consistent boundaries rather than declare one business model superior in the abstract.
The resale records and cash-flow guide also distinguishes settlements, inventory, commitments, and actual cash movements. That distinction illuminates software prepayments and pending receipts. A subscription dashboard and a shelf of unsold stock can both look valuable while leaving little available for the next commitment. The founder needs traceable resources rather than an impressive total.
Keep the comparison proportionate. This article concerns operating allocation, not personalized securities, tax, or debt advice. A real decision involving financing, entity changes, or material legal obligations needs appropriate qualified review. The useful general question remains concrete: what does this commitment displace, and what evidence shows that displacement is justified under the business’s actual constraints?
Test whether the cash timeline survives disappointment
A positive total can hide a temporary shortage. Suppose A requires its $900 cash commitment now, while the forecast $300 monthly increment begins only after three weeks of implementation and another customer decision cycle. The business cannot use that increment to pay a bill due tomorrow. Put receipts and payments on a timeline using supported dates, and label uncertain dates rather than forcing them into the preferred sequence.
In a separate hypothetical timing exercise, imagine $1,000 of discretionary cash available today, a $600 payment due next week, and a hoped-for $700 customer receipt in three weeks. A $500 experiment would leave only $500 before the known payment, creating a $100 gap even though the later total looks sufficient. Deferring or reducing the experiment can preserve the current commitment. The anticipated receipt is not available merely because the customer is expected to pay eventually.
Stress the timing conditions that matter to this business. A delayed customer settlement, a refund, a required migration, or a reviewer absence might create the practical downside. There is no universal percentage reduction that makes every forecast adequately conservative. Identify the event, its consequence, and the response the operator can actually perform. A plan that requires emergency borrowing or unpaid overnight work under ordinary disappointment needs revision.
Keep a separate record of cash already committed by approved proposals. Several individually affordable experiments can compete for the same remaining balance. A central commitment record prevents two teams from each allocating the same $1,000. Cancellation of a proposal releases funds only when the related payment or obligation is genuinely avoidable. A vendor deposit may remain exposed even after the development task stops.
Compare marginal increments rather than average success
A product’s historical contribution can justify maintaining it while saying little about the next feature. Suppose an illustrative app produces $2,000 monthly maintained contribution, but a proposed expansion adds $400 receipts and $350 attributable cost. Its increment is $50 under that boundary. Dividing the new spending by the app’s entire $2,000 would make recovery appear much faster than the improvement itself supports.
The opposite can also happen. A modest improvement might reduce an expensive recurring exception across existing customers without adding new subscriptions. If the avoided work is measured and can become useful capacity, it belongs in the incremental comparison. Count the saving once: do not include the same freed hour as both a support-cost reduction and additional development capacity valued again in the benefit total.
Ask whether the increment changes another part of the portfolio. An expansion can attract customers who need more specialist review than the current cohort. A shared parser update can reduce maintenance in several apps, but it may require verification across all of them. A cheaper billing arrangement might save cash while increasing reconciliation work. The proposal should include material spillovers rather than treating each app as an isolated financial box.
This discipline makes an allocation review less dependent on product popularity. A familiar winner can receive maintenance funding and lose the contest for expansion funding. An unproven candidate can receive a small learning allocation without being declared the next winner. The resource decision follows the next increment and its evidence, while the lifecycle decision preserves obligations already accepted.
Use an allocation meeting that ends in decisions
Bring current obligations, cash boundary, attention capacity, proposal sheets, scoped evidence, and relevant dependency changes. Each proposal should receive a next action, owner, budget, and review date. A meeting that only ranks ideas leaves authority ambiguous. A meeting that automatically funds the top score can ignore the constraint that makes the proposal infeasible.
For the hypothetical portfolio, a reasonable proposed decision could protect maintenance first, fund C’s bounded test, and prepare A’s onboarding improvement for review while deferring B’s build. That is one possible choice under the stated assumptions, not an optimal result proved by the numbers. A different observation about A’s buyers or the owner’s availability could change the ordering.
Record rejected or deferred alternatives with their reasons. If B is deferred because acquisition evidence is missing, identify the evidence needed to reconsider it. If A is deferred because support is overloaded, identify the capacity condition. A clear reason prevents the team from interpreting deferral as permanent rejection or restarting the same debate without new information.
Review the result at the promised date. Compare actual cash, time, delivery, and learning with the proposal. If the experiment was not executed as designed, record that limitation. If the product improved but the benefit did not become cash or usable capacity, examine the conversion mechanism. A positive technical result can coexist with a weak allocation decision.
Stop forecasts from becoming standing truth
An estimate is a dated statement about conditions. Keep its source, boundary, and uncertainty visible. A forecast created before the first independent customer should not become the default revenue assumption for the next year. Revalidate it when acquisition, support, pricing, external access, or customer use changes materially.
Separate proposed, observed, and inferred information. Proposed means the team plans to test or deliver something. Observed means records support an event or measurement. Inferred means the team interprets the observation under assumptions. This distinction is especially useful when an AI assistant summarizes a large portfolio. A polished recommendation can blur the categories unless the underlying evidence remains accessible.
Do not let a model supply missing prices, probabilities, customer counts, or return rates to complete a table. Unknown values should remain unknown and change the decision. The assistant can identify the gap, calculate conditional scenarios, and propose a bounded investigation. Authority to commit funds should follow the appropriate human or established business approval process, with the concrete evidence visible.
Retain findings with scope and revalidation triggers. A local improvement on one export family does not establish universal performance. A small paid pilot does not prove broad demand. A quiet support month does not prove permanent low maintenance. These limits do not make the evidence useless; they determine the next increment it can responsibly support.
What Would We Do at Salars?
We would propose a dated allocation ledger connecting each candidate to cash, owner attention, maintenance obligations, evidence, and a next decision. No Salars portfolio returns, current app receipts, or staffing capacity is established here. The hypothetical A, B, and C comparison illustrates the method only. Supplier Margin Guard and Merchant Revenue Guard remain proposals that would need their own buyer and delivery evidence.
We would protect existing commitments before assigning a learning budget. A proposed Forge control plane would prepare comparisons and expose missing information, while the responsible owner would authorize the actual commitment. Forge itself remains a proposed design. Its job would be to make authority and evidence legible, not convert an opportunity score into automatic spending.
For a first candidate, we would prefer the smallest test that can change the decision: a compatibility check, a paid concierge job, or a bounded onboarding experiment, depending on the unresolved mechanism. We would establish a baseline, independent criteria, protected counterexamples, budget, and stop date before execution. A rejected hypothesis would release the remaining commitment instead of triggering an unlimited rescue build.
At review, we would compare actual contribution, time, and learning with the proposal and inspect shared dependencies. We would fund the next stage only when the evidence and remaining capacity justify it. We would also consider improving an existing business workflow or retaining cash when no candidate meets the decision boundary. The purpose would be maintained economic usefulness, rather than maximizing the number of apps bearing the Salars name.
Sources
- SBA Manage your business: financial records, cash-flow planning, and business management; no universal software allocation threshold.
- Stripe subscription analytics: provider-specific recurring-revenue definitions and reporting settings, distinct from cash and profit.
Sources checked October 7, 2026. All budgets, app comparisons, time values, recovery calculations, and Salars allocation gates are hypothetical or proposed. No executed investment, measured return, probability of success, or optimal portfolio is claimed.
Loading comments…