Two apps each produce $1,000 of monthly contribution under the same operating definition. One requires four hours of owner work. The other requires forty hours, including evening support and repeated custom fixes. A revenue comparison calls them similar. The founder’s calendar does not.
Measure what the app leaves after its stated delivery costs, then divide by the owner time required to sustain that relationship. The numerator must be named accurately. Contribution per owner hour is not full profit per hour if fixed expenses and other obligations remain outside it.
This chapter of The AI Software Factory gives scarce human time its own denominator. Contribution margin defines the monetary boundary. The broader time as capital argument explains why opportunity cost matters; here the task is measuring the app’s actual human workload.
Choose the question before the ratio
A ratio can compare ongoing products, evaluate a proposed automation or decide where the founder should spend the next week. These questions need different periods and time boundaries.
For an ongoing-product comparison, include the work needed to sustain the app: maintenance, sales, support, administration and exceptions under the chosen scope. For a narrow automation test, measure the affected task separately while preserving the product-level view.
State what is excluded. Initial development may be treated as a separate investment, while recurring maintenance belongs in the ongoing workload. A product launch month and a stable operating month are not directly comparable without context.
The ratio should help a decision rather than become a universal ranking. A low current return may be acceptable during a bounded learning phase. A high current return may conceal deferred maintenance or an unreliable customer obligation.
Record hours by task and product
Memory tends to compress routine interruptions and exaggerate memorable emergencies. A practical time record should capture the task, product, date and duration with enough detail to distinguish mechanisms.
Use a small number of useful categories: customer acquisition, onboarding, product maintenance, support, manual delivery exceptions and administration. Avoid a taxonomy so detailed that recording consumes more time than it explains.
Shared work needs a stated allocation or a separate pool. Reviewing a common billing integration may support several apps. Assigning all of it to whichever product was open on the screen would distort the comparison.
The record should include unpaid owner work. The absence of a wage payment does not mean the task is effortless. Keep hours visible even if the monetary contribution view excludes an imputed value for them.
Include acquisition and onboarding effort
An app can appear efficient after the customer is active while requiring substantial founder effort to win and set up every account. That work belongs in a lifecycle evaluation, even if it is separate from recurring delivery.
Record sales conversations, sample preparation, integration help and custom setup. Distinguish research interviews from sales work when the purpose differs. Both use time, but they answer different questions about the business.
A concierge MVP intentionally uses human work to learn. Its hours should be labeled as assisted discovery or delivery rather than evidence of a fully automated product.
Compare acquisition cohorts over an appropriate observation period. Early onboarding hours may be recovered through later contribution, but that future relationship remains uncertain until retention and delivery are observed. A favorable lifetime estimate should not erase the initial workload.
Count recurring maintenance before it becomes an emergency
Dependency updates, integration changes, tests, backups and access reviews can consume regular owner time. Ignoring them makes an app look profitable until a failure forces a large correction.
Record maintenance actually performed and identify deferred obligations separately. A quiet month may reflect a healthy system, or it may reflect neglected work. The ratio alone cannot tell which.
A product using shared infrastructure may require less incremental maintenance, but the common system still needs an owner. Preserve the shared time pool and show the allocation used for portfolio comparison.
Supply-chain security explains why updates need review rather than automatic optimism. A maintenance reduction is valuable only if the product’s acceptance and security boundaries remain sound.
Capture interruptions as work
A five-minute support message can create more disruption than its duration suggests. The founder may need to stop another task, recover context and follow up later. Record the direct time and, if relevant, interruption patterns rather than inventing a precise universal switching-cost multiplier.
Tag urgent or after-hours requests. Two products with similar total hours can place very different demands on the owner’s schedule. A predictable weekly review may fit available capacity better than unpredictable incidents.
Do not inflate the ratio with subjective exhaustion converted into arbitrary hours. Keep measured duration and qualitative burden distinct. Both can inform the decision, but they are different evidence.
A proposed support boundary can improve predictability without reducing helpfulness. Clear service hours, useful failure states and an appropriate urgent route can make the obligation manageable. The terms must match the actual consequences of the app.
Calculate the ratio with a clear numerator
Suppose a hypothetical app retains $2,000 in monthly revenue and creates $600 in attributable cash delivery cost. Contribution under that boundary is $1,400. If the owner spends twenty hours on the stated ongoing tasks, contribution per owner hour is $70.
This is not a claim of $70 wages or full profit. Fixed expenses, taxes, acquisition and other obligations may remain outside the numerator. The calculation is a planning comparison under an explicit boundary.
If the owner spends forty hours instead, the same contribution yields $35 per owner hour. If contribution falls to $1,000 while hours rise to forty, the ratio becomes $25. The two moving parts should remain visible.
Do not round away meaningful uncertainty. If time records are incomplete, report a range or label the estimate. A precise ratio built from guessed hours creates more confidence than the evidence supports.
Avoid counting owner time twice
An operating contribution model may already include an imputed value for owner support time. Dividing that reduced contribution by the same hours can answer a specific question, but it differs from contribution before owner-time valuation per hour.
Present the definition consistently. One useful view shows cash contribution and measured owner hours separately. Another shows a planning residual after valuing owner time at a stated rate. The second helps assess an opportunity-cost assumption; it is not an invoice expense unless the business actually pays it.
For the hypothetical $1,400 contribution and twenty hours, a $30-per-hour planning valuation would subtract $600 and leave $800 before other excluded obligations. Both the $70-per-hour view and the $800 residual can be useful if their meanings are clear.
Do not choose the denominator or valuation differently for each product merely to favor one. Consistency and visible sensitivity make the comparison more credible.
Compare products with their operating phase
An early app may need discovery and setup work that a mature app no longer needs. Comparing one month without phase context can discourage a useful experiment or overvalue an old product whose maintenance has not yet arrived.
Show launch, learning and steady-operation periods separately where the evidence supports them. Preserve development investment as a separate record if excluded from the recurring ratio.
A product that is supposedly mature but repeatedly needs custom delivery may not have reached the intended operating model. The time record can expose that gap without requiring a philosophical argument about whether it is “really SaaS.”
Portfolio discipline examines broader allocation. This chapter supplies a measured human-work view that can inform the portfolio without pretending a single ratio settles every strategic question.
Investigate the expensive category before automating
If support consumes most time, inspect the causes. Unsupported input, unclear onboarding, misleading output and a broad custom-service promise call for different responses. Automating replies may not resolve any of them.
If manual delivery exceptions dominate, determine whether they are repeatable and safely bounded. A deterministic validation improvement might reduce work more effectively than an agent attempting every unusual file.
If sales consumes most time, a product change may not be the relevant lever. The offer, customer segment or channel could be mismatched. The time category identifies the next question; it does not establish its answer.
Choose a bounded hypothesis and independent success criteria. The proposed improvement should reduce defined work while preserving accepted results, customer understanding and safety. Record the baseline and protected cases before changing the workflow.
Model delegation as a changed obligation
Hiring someone or delegating to an agent can reduce owner time while creating other costs and oversight. The comparison should include the new expense and the remaining human responsibility.
Suppose a hypothetical task takes ten owner hours monthly. A proposed service costs $200 and reduces owner work to two hours. The decision concerns an eight-hour reduction, the $200 cost, quality and oversight under the actual service boundary.
Do not call all eight hours freed capacity until the owner can actually use them. Fragmented time, new review work or recurring provider issues may reduce the practical benefit. Observe the changed workflow rather than assume the proposal works as modeled.
Agent delegation also needs authority limits. Agent security explains contractor-style scope. A favorable time estimate does not authorize giving a tool broader access than the task requires.
Preserve quality in a time-saving test
A faster workflow can create more errors, customer confusion or deferred cleanup. Include those consequences in the evaluation rather than measuring only the first completion.
For a proposed report parser improvement, record owner time per accepted job, correction rate and unresolved failures. Include difficult supported files and unsupported inputs that should be rejected. A shortcut that accepts everything can reduce immediate effort while moving the problem to customers.
Observe a full relevant cycle. A change that saves ten minutes today but creates an hour of support next week may be worse. The appropriate window depends on the task and customer cadence.
State the result narrowly. A local test can support a finding about the examined files and workflow. It does not establish that the same saving applies to every account or future product version.
Account for capacity and predictability
A founder’s available hours are finite, and their timing matters. A product needing twenty scheduled hours can be manageable while one needing twenty unpredictable emergency hours disrupts the rest of the business.
Record deadlines, urgent events and dependencies alongside total time when they affect the decision. Avoid inventing a universal score for burden. A simple note can preserve a material constraint.
Capacity also changes with growth. A manual task that seems small at ten accounts may become the dominant obligation at one hundred. Model the workload relationship and test it during bounded expansion.
Do not assume every category scales linearly. Shared maintenance may grow slowly, while customer-specific setup grows with each account. The time ledger should support separate mechanisms instead of one extrapolated average.
Use the ratio to choose the next commitment
Contribution per owner hour can guide where to improve, limit or expand, but it should sit beside customer evidence, risk and strategic fit. A favorable ratio with unresolved security exposure does not justify growth.
Set a proposed threshold or budget appropriate to the founder’s goals, then preserve its scope. A learning experiment may accept a lower short-term return for a defined period. The stopping condition prevents it from becoming a permanent unpaid obligation by inertia.
A product with weak ongoing economics may deserve a scope change, a higher-priced service boundary or retirement. Software portfolio capital allocation develops those choices across products.
Revalidate after material changes in price, workload, support or architecture. A historical ratio should retain its period and definition. It is evidence about that relationship, not a standing guarantee of future freedom.
Keep a time budget for the experiment itself
Measurement and improvement use owner time too. A founder can spend weeks optimizing a tiny category whose maximum saving would never justify the effort. Estimate the upper bound before beginning a large automation project.
If a hypothetical task consumes one hour monthly, removing half of it saves six hours over a year before accounting for maintenance. A proposed forty-hour implementation therefore needs another substantial benefit or a longer justified horizon. The arithmetic does not settle the decision, but it prevents the saving from being described vaguely as unlimited leverage.
Set a bounded research and implementation budget. Stop or revise when the likely benefit becomes too small, the task proves unsafe to delegate or the evaluation cannot establish accepted quality. Preserve the finding so the next review does not repeat the same unproductive experiment without a changed condition.
Examine the account mix behind the hours
Two cohorts can generate the same contribution while requiring different human work. An ordinary account may use the supported template independently; another may expect bespoke interpretation after every report. Aggregate hours alone can hide that distinction.
Group time by the mechanisms that create it when the evidence permits. A source format, support promise or acquisition channel can be more useful than a broad demographic label. Avoid assuming a causal relationship from a small association; inspect representative cases and test a focused change.
A proposed offer adjustment might make the supported scope clearer or create a separate reviewed service. The goal is to match obligations to value and capacity, not to make customers feel unwelcome for asking legitimate questions about the purchased product.
Relate the ratio to the whole business plan
The SBA planning resources cover market research, costs and break-even analysis. The owner-hour view complements those questions by making the founder’s capacity explicit. It does not replace a complete business plan or establish demand.
An app can contribute efficiently and still be too small to cover the business’s fixed obligations. Another can create substantial total contribution at a lower hourly ratio. The choice depends on available capacity, the desired income boundary and the other opportunities the founder can actually pursue.
Use the ratio to clarify those tradeoffs rather than as a badge. A decision record should state the goal it informed, the relevant period and the unresolved assumptions. That keeps a useful local measure from becoming an unsupported universal rule.
What Would We Do at Salars?
For a proposed merchant report app, we would record owner time by onboarding, support, maintenance, sales and manual exceptions. Cash contribution and time valuation would remain separate so the operating comparison stayed understandable.
We would review ordinary weeks and interruption-heavy weeks. A proposed automation test would target one recurring category, compare measured time and preserve accepted report quality, privacy and action boundaries. It would include later support work in the observation window.
If a custom format consumed most hours, we would decide whether to support it as a product, sell it as a separate service or decline it. We would not assume an agent could safely absorb every exception simply because generation was cheap.
The figures and experiments in this article are hypothetical. No existing Salars app’s owner return or observed time saving is claimed. The purpose is to make a future decision measurable before expanding the obligation.
The useful question is not how much software an AI can produce. It is which customer relationship leaves enough contribution and human capacity to sustain the work the owner chooses. The broader AI collection connects that choice to product scope and disciplined growth.
Sources
- SBA: Plan your business — planning, startup-cost and break-even resources; the owner-hour method and hypothetical calculations here are an explicit operating decision model, not an SBA-certified metric.
Loading comments…