What Is Unit Economics? LTV, CAC, and Payback Examples
Victor
Posted on 23 October 2026
Unit economics measures whether one repeatable unit of business, such as one customer, subscription, or staffed engagement, generates more contribution than it costs to acquire and serve, before fixed overhead is counted. For a medical practice, the unit might be a remote staffing engagement; for a software team, it might be one developer engagement or one customer account.
You may be weighing a remote administrative hire against a contractor, or deciding whether to add engineering capacity without committing to a full-time hire. Revenue alone won't tell you which option makes financial sense. You need to know what remains after the costs that rise with each customer, staff member, or project are paid.
Unit economics offers a way to make that comparison with clear inputs rather than a single company-wide profit figure. The central measures are contribution margin, customer acquisition cost (CAC), lifetime value (LTV), and CAC payback. They can help you assess customer segments, staffing choices, and outsourced development capacity, while also showing where a tidy-looking calculation depends on uncertain assumptions.
Table of Contents
A practice is choosing between adding an in-house developer, hiring a contractor, or sourcing engineering capacity through a platform. Each option may deliver similar work, yet the amount the practice keeps after direct costs can differ. Unit economics makes that comparison possible by following one defined unit from the value it produces to the costs that come with delivering it.
Start with a simple example: a lemonade stand sells a cup for a set price. Subtract the ingredients and cup, along with any other cost that rises with each sale. What remains is the cup's contribution toward costs that do not change with each cup, such as stand rent. Rent affects the stand's overall profit, but it is not the cost of making one more cup.
A business unit could be one customer, subscription, transaction, project, or staffed engagement. The question is whether that repeatable unit produces more contribution than it consumes in acquisition and delivery costs, before fixed expenses such as headquarters, core product development, or executive salaries. A general explanation of SaaS unit economics also describes the unit as something a business can measure repeatedly.
Consider a practice paying for a remote administrative engagement. Its value might come from supported appointment workflows or less need for other paid labor. To see what the engagement contributes, subtract its direct delivery costs, such as compensation, payroll or contractor fees, role-specific software, training, supervision, and rework. The remaining amount is the contribution. Billed charges, or the gap between a client payment and headline wages, can make the engagement look more profitable than it is.
The same logic applies to engineering capacity. Compare the value of the work delivered with the costs attached to the specific arrangement: for example, compensation and supervision for an employee, or contractor fees and project-specific onboarding. A platform-sourced engagement may have a different mix of direct costs. The comparison is useful only when each option includes the costs that rise with that choice.
Contribution does not equal company-level profit. A business can earn positive contribution from every customer or engagement and still lose money if fixed overhead is too high. It can also show strong revenue or growth while individual units consume more in acquisition and delivery costs than they contribute.
Choose a unit that fits the decision at hand. A practice comparing staffing options could examine one role over its contract duration. A product team could model a specific engineering project or engagement. A company comparing acquisition channels could define the unit as one new paying customer, then separate results by channel and customer type.
Averages can hide important differences. High-touch work, unusual onboarding, pauses, or support needs can make one engagement costly even when the overall business appears healthy. Begin with a simple unit, then separate the model when customer types, roles, or delivery arrangements behave differently.
Practical rule: If adding another unit increases a cost, assess whether that cost belongs in the unit's contribution calculation. If the cost remains without the unit, it may be fixed overhead instead.
The formulas are simple. The judgment comes in deciding which costs belong in them, what counts as a customer, and how much confidence to place in churn-based estimates. Use the same time period when matching acquisition spending to newly acquired customers, and calculate value from gross-margin contribution rather than revenue alone.
CAC is attributable sales and marketing expenditure divided by the number of new customers acquired in the same period:
CAC = attributable sales and marketing expenditure ÷ new customers acquired
Pull the spending from accounting records and the customer count from your billing or customer records. Include costs that are directly tied to winning customers, such as paid campaigns or sales labor, where your accounting method can identify them. Shared overhead, such as general executive costs, shouldn't be assigned to acquisition without a consistent allocation method. Teams that need a more detailed walkthrough can consult this CAC formula for SaaS teams.
For a staffing or services model, acquisition isn't the only early cost to inspect. The work needed to scope, recruit, vet, and onboard an engagement can affect its economics. Decide whether those costs are part of customer acquisition or delivery, document the choice, and apply it consistently. Otherwise, comparisons between channels or engagement types may reflect accounting choices rather than real differences.
A simplified customer-based estimate is:
LTV ? average revenue per account × gross-margin percentage ÷ periodic customer-churn rate
Gross margin adjusts revenue for the direct costs of serving the customer. Without that adjustment, LTV treats money needed for delivery as though it were available to recover acquisition costs or support overhead. That can make an expensive-to-serve customer look better than the underlying economics justify.
The simplified formula also has limits. It doesn't account for expansion, discounting, or unusual retention behavior. Churn may be unstable for a small or changing customer base, so treat LTV as an estimate to test rather than a guaranteed amount.
Payback turns acquisition economics into a cash-timing question:
CAC payback = CAC ÷ monthly gross-margin contribution
Monthly gross-margin contribution is the amount the customer contributes after direct service costs. Gather revenue from billing records and direct costs from payroll, contractor payments, and other delivery expenses. For a medical-practice staffing unit, that may include compensation, payroll or compliance costs, payment fees, recruiting operations, and support. For an engineering engagement, consider compensation or contractor fees, recruiting, supervision, and other delivery costs tied to the work.
A SaaS account brings in $1,000 a month, carries a 75% gross margin, costs $4,500 to acquire, and has 2% monthly churn. These are illustrative inputs for working through the math, not a claim about a typical customer. The model turns them into an estimate, then lets us test how much that estimate depends on its assumptions.
Multiply monthly revenue by gross margin: $1,000 × 75% = $750. The account contributes $750 per month before fixed overhead. That is the portion available to recover acquisition cost and help cover fixed expenses, rather than the full $1,000 billed.
Now divide CAC by monthly contribution: $4,500 ÷ $750 = six months. If the account continues generating the same contribution, it takes six months for its contribution to equal what it cost to acquire. In a spreadsheet, enter revenue, gross margin, and CAC, calculate contribution as revenue multiplied by margin, then divide CAC by contribution. Keep the time units aligned: monthly contribution produces a payback period in months.
The simplified LTV calculation divides monthly contribution by monthly churn: $750 ÷ 2% = $37,500. At that churn rate, the model implies an approximate expected lifetime of 50 months. This is a projection based on steady churn, not a promise. It leaves out expansion revenue, discounting, and unusual retention patterns.
The modeled LTV may look strong beside six-month payback, but the answer shifts when churn changes. A short spell of low churn does not establish that customers will keep renewing at that rate over the modeled lifetime. Check the assumption against customer cohorts and allow for uncertainty, especially when the customer base is small or changing.
At a 3:1 LTV:CAC ratio, $4,500 of acquisition cost would need $13,500 in lifetime contribution. Compare that reference point with the modeled $37,500 LTV, while remembering that arithmetic cannot repair a weak churn estimate or missing delivery costs. Either can make the ratio look healthier than the underlying business.
A self-serve account may cost less to acquire and support than a high-touch account. It may also have a different contribution and retention pattern. Calculate each segment separately before blending them. Otherwise, a strong segment can conceal weak payback or LTV elsewhere.
The same logic applies when buying engineering capacity. Compare an in-house developer, a contractor, and engineers sourced through a platform by the contribution each option leaves after direct delivery costs. For example, include compensation or fees, recruiting, supervision, and costs tied to delivering the work. A lower headline rate does not automatically mean better unit economics if added oversight or delivery costs reduce the contribution. Apply the same monthly-versus-lifetime discipline, and avoid treating a short engagement as though it were a stable customer subscription.
Watch for common modeling errors. Revenue in place of gross profit overstates contribution; omitted onboarding or support understates delivery costs. CAC also becomes misleading when the count includes trial sign-ups but the revenue calculation covers paying accounts. For another way to examine how revenue covers a fixed investment, see Zaro's guide to export break-even analysis.
Benchmarks can help you ask better questions, but they don't decide whether your business is healthy. SaaS reference points describe software-heavy models; a practice buying remote staffing or a company purchasing engineering capacity has different delivery costs and operating assumptions. Use external comparisons to flag an issue for investigation, then decide with your own cohorts and unit definitions.
Common SaaS reference points include gross margins of about 70% or higher, an LTV:CAC ratio near 3:1, and CAC payback under about 12 months as a strong result. Ratios below 2:1 generally suggest weak acquisition economics that may need correction before aggressive scaling. These are directional signals, not universal thresholds. SaaS benchmark context also emphasizes that service-heavy and staffing models can have lower margins because delivery labor is a variable cost.
A high LTV:CAC ratio doesn't automatically mean the company has found an ideal balance. It may reflect underinvestment in acquisition or an overly optimistic lifetime estimate. Payback adds a cash-flow perspective: even a promising lifetime ratio may not help a company that must finance a long period before recovering its acquisition spending. For the same reason, a benchmark should be interpreted alongside churn, pauses, and the costs required to keep the customer served.
| Metric | Commonly cited reference | Check before applying |
|---|---|---|
| Gross margin | Around 70% or higher for software-heavy models | Does the calculation include the direct labor, support, infrastructure, and other costs needed to deliver this unit? |
| LTV:CAC | Near 3:1 as a common target; below 2:1 generally signals weak acquisition economics | Is LTV based on contribution and credible retention assumptions, and is CAC fully loaded and consistently defined? |
| CAC payback | Under 12 months is often considered strong | Can your organization finance the recovery period, given the unit's churn, pauses, and working-capital needs? |
| Payback by contract size | Median payback is 11 months for contracts below $5,000 annually and 22 months for contracts between $50,000 and $100,000; surveyed B2B SaaS companies show a 16-month median, with top-quartile companies at six months or less | Are you comparing contracts of similar size, sales process, onboarding burden, and service requirements? |
These contract-size comparisons are reported in a SaaS financial-model discussion. They show why one blended payback target can be misleading. A larger contract may carry more sales and onboarding work, while a smaller account can follow a different acquisition path.
For a medical practice, calculate the contribution of a particular staffing arrangement after compensation, payroll or contractor costs, software, supervision, and rework. For a development team, include costs tied to delivery and onboarding rather than assuming that a lower hourly rate automatically means better economics. The appropriate threshold depends on the work and the organization's capacity to absorb the costs.
Use cost-benefit analysis for hiring and outsourcing decisions to complement the unit calculation when comparing alternatives. If you're also assessing a technical partner, compare cloud modernization partners as a separate sourcing decision. Neither comparison replaces a contribution model built around your own costs, customer cohorts, or engagement type.
A developer engagement can be treated as a repeatable unit just like a customer. Define the unit around the work you're buying, then estimate its value and the costs required to deliver it. For a project, that may mean evaluating the contribution associated with a completed scope. For ongoing capacity, it may mean comparing the value of productive engineering time with the costs of obtaining and supporting that capacity.
Start with the cost side. Include compensation or contractor fees, recruiting, payroll or compliance costs where applicable, role-specific software, onboarding, and the management time needed to keep work moving. Supervision and rework aren't bookkeeping details. If they rise with the engagement, excluding them can make the apparent cost per productive hour too low.
| Model | Costs to examine | Operational tradeoffs |
|---|---|---|
| In-house hire | Recruiting, compensation, onboarding, software, supervision, and ongoing employment costs | You can build continuity and direct team knowledge, but hiring and ramp-up take management attention. |
| Freelance contractor | Contract fees, sourcing, onboarding, coordination, and any rework or transition costs | A contractor can suit defined work, but availability, handoffs, and continuity require planning. |
| Platform-sourced engineer | Engagement fees or compensation, onboarding, coordination, and the platform's applicable terms | A sourcing platform may reduce some candidate-search work, but you still need to assess fit, manage delivery, and include the full engagement cost. |
Compare cost per productive hour, not just a stated rate. A lower rate may be offset by longer ramp time, extra coordination, or rework. Conversely, higher sourcing or employment costs may make sense if the person can start the needed work sooner or reduce management burden. The right answer depends on what the engagement delivers and which costs the organization incurs.
Fixed overhead needs a separate treatment. Office space or an engineering director's salary may remain whether or not the team adds a developer. Don't assign those costs to every sprint when the question is the incremental economics of adding capacity. If you're instead assessing fully allocated profitability, apply an explicit and consistent allocation method. For a broader comparison of software development outsourcing costs, consider how the estimate defines scope and includes operational effort.
A developer's paid time isn't automatically productive capacity. Access, onboarding, requirements, code review, coordination, and rework affect how much useful work the engagement produces. Remote and nearshore arrangements also require the team to plan communication and handoffs; time-zone overlap can help with collaboration, but it doesn't replace clear ownership, documentation, or technical direction.
The same logic applies in medical practices evaluating remote administrative staff. A role may support scheduling, patient coordination, insurance verification, billing administration, or other defined workflows, but the practice should account for training, supervision, systems access, and quality review. The unit is economically attractive only when the value of the supported work exceeds its full variable delivery cost. Clinical judgment and licensed work must remain with appropriately qualified personnel under applicable requirements.
The cheapest quoted rate isn't necessarily the lowest-cost unit. Compare what it takes to get reliable, usable output, not just what you pay for someone's time.
In-house hiring may remain the stronger choice when the work depends on deep institutional knowledge, continuous collaboration with a core team, long-term ownership, or responsibilities that require direct organizational control. A contractor or platform-sourced engagement may fit defined capacity needs, but it shouldn't be treated as a substitute for leadership, technical direction, or a clear scope of work.
Once the model reveals where contribution is weak, choose a lever that addresses the cause rather than optimizing a headline ratio. Higher prices may improve contribution per customer, but they can affect conversion. Lowering onboarding effort may help, but only if it doesn't reduce quality or shift the work into support and rework. The same caution applies to staffing: faster access to capacity may be useful, while rushed onboarding can increase the cost of getting a person productive.
Review CAC by channel, payback by segment, LTV by cohort, and gross margin by engagement type. For staffing and delivery models, also monitor utilization, time to a productive start, pauses, and the supervision or rework required. These measures help explain why a unit changed, not just whether the blended result moved.
Segment by customer size, geography, role type, engagement duration, and acquisition channel when those differences affect the cost or value of delivery. A single average can conceal a costly customer cohort or an engagement that requires unusually high support. Keep the definitions stable from month to month so changes in the result reflect the business, not a shifting spreadsheet.
A simple calculator can use three tabs. The Inputs tab records revenue, direct costs, acquisition spending, new customers, and churn assumptions. The Cohort tab separates units by channel or engagement type. The Scenario tab tests what happens when price falls, onboarding costs rise, or another material assumption changes. Software-development KPIs can provide additional measures for evaluating delivery performance alongside the financial model.
Unit economics answers a practical question: does one repeatable unit create enough contribution after its real acquisition and delivery costs are paid? Define the unit first, then use contribution margin, CAC, LTV, and payback to test the result. Keep estimates honest about what they exclude, especially retention assumptions, onboarding, supervision, and rework.
To put the model to work, pull revenue and direct-cost inputs from billing, payroll, and accounting records; build a cohort view; and compare staffing or outsourcing choices on contribution rather than headline price. You can model your own engagement with the inputs, cohort, and scenario structure described above, or book a consultation with HireDevelopers.com to scope developer capacity. Direct accounting, tax, and compliance questions to qualified finance or legal advisors.
Most hiring advice starts with the wrong premise: every programmer is equally difficult to find. That isn't how the current U.S. market behaves. Entry-level applicants can be plentiful while experienced engineers with architectural judgment, cloud, security, or AI-related experience remain difficult to attract. A job post that treats those groups as interchangeable creates a crowded...
Sure, the hourly rate for skilled offshore developers in places like Latin America or Eastern Europe hovers between $25 and $55. That looks fantastic next to the $80 to $150+ per hour you’d shell out for a similar mid-level engineer in the US. But if you think that hourly rate is the whole picture, you're...
Let's be honest. Trying to hire Python coders right now feels like a street fight for the last slice of pizza. The demand is out of control, fueled by every company wanting a piece of the AI and data science boom. Every funded startup is chasing the same handful of senior engineers. This leaves you...
