LESSON 13 / 14 · FREE BUSINESS COURSE
Growth adds responsibility as well as revenue. Before increasing traffic, features or team size, understand which part of the business currently limits dependable delivery. Improve that constraint and measure the result.
By the end: identify your current bottleneck, calculate a small set of useful metrics, and choose one evidence-based growth experiment.
Use numbers with clear definitions
Monthly recurring revenue, or MRR, expresses active recurring subscription revenue on a monthly basis. Separate one-time setup charges and services from that measure. Normalize annual subscriptions consistently, and document how you treat discounts, refunds and unpaid accounts.
Average recurring revenue per account is MRR divided by the active paying account count used for that period. It is not profit per customer. Customer churn tracks customers lost from the starting group; revenue churn tracks recurring revenue lost and can tell a different story when plan sizes vary.
Customer acquisition cost should state which sales and marketing costs you include and which new customers you count. Comparing a cash-only estimate with another channel’s fully loaded cost gives a misleading result. Record assumptions about founder time, contractors and referral commissions.
Work the FitSite example carefully
Take the source’s illustrative mix: 30 Starter accounts at $49, 15 Growth accounts at $99 and five Pro accounts at $199 per month. Their base monthly subscription revenue is $1,470 + $1,485 + $995 = $3,950. These prices are teaching assumptions, not recommended market prices.
If those same customers also pay $500 in recurring monthly add-ons, total MRR is $4,450 and average recurring revenue per account is $89. If the $500 instead comes from one-time setup work, MRR remains $3,950 and the recurring average is $79. The classification changes the metric.
Neither total is take-home income. Subtract payment fees, hosting, email delivery, support, software, acquisition, administration and other applicable costs when assessing profitability. Include the work you perform yourself so the business is not viable only because your labor is treated as free.
If two of the starting 50 customers cancel in a month, customer churn is 4%. The shortcut of dividing one by that rate suggests 25 months, but assumes stable churn and a simplified customer population. It is not a reliable forecast from one small month of observations.
Prefer observed cohorts: group customers by start period, then follow retention, recurring revenue and delivery costs over time. If you do use a lifetime-value model, show its assumptions and distinguish revenue value from contribution after service costs. Do not use a precise-looking number to justify spending cash you cannot recover.
Scale the actual infrastructure constraint
Look at customer experience and system behavior together. Slow pages might come from a particular query, a third-party API, large images, background jobs or insufficient resources. A larger server may help one problem while leaving another unchanged.
There is no universal rule that one hundred sites or seventy percent CPU means it is time to upgrade. Workload varies with traffic, plugins, data and concurrency. Measure representative response times, failed requests, memory, storage and background queues, then investigate the bottleneck.
For the optional WordPress track, consider appropriate page and object caching, static-asset delivery, database work and media storage only after examining the workload. Check that caching does not expose account-specific pages or interfere with checkout. Test changes against representative customer tasks.
If a migration is necessary, plan data synchronization, backup, verification, a rollback route and customer communication. Rehearse the move before scheduling it. New signups, uploads and payments can continue changing data during a move; decide how those changes will be handled.
Automate a stable process
Write down a manual process before automating it. A reliable automation needs a trigger, required information, expected outcome, an owner for failures and a way to avoid duplicate actions. Start with low-risk internal notifications before automating changes to billing or access.
A useful first example is notifying support when a newly paying customer has not completed the initial task. The message should include only the information the support team needs. Decide how often it can fire and how to stop reminders once the task is complete.
Webhooks and integration tools can connect Ultimate Multisite or another SaaS application to operational systems. Verify the supported events and authentication for your installation. Test retries and duplicate deliveries; receiving the same event twice should not create two customer accounts or two rewards.
Keep a human path for exceptions. An acknowledgement email can reassure a customer that a ticket arrived, but it should not falsely imply someone has resolved it. Review automated messages when the product or support coverage changes.
Grow value per customer responsibly
Offer a higher tier when its benefits match the customer’s work. Add-on services such as setup, training or design can create revenue, but they also consume capacity. Price and schedule them as real delivery commitments rather than treating them as costless upgrades.
Annual billing can change cash timing, but an annual payment is not all earned profit on day one. You still owe the promised service over the subscription period. Model discounts, renewal behavior and delivery costs before encouraging customers to switch.
When changing prices, decide how existing agreements are handled and communicate clearly before a change takes effect. Keeping existing prices forever is one possible policy, not a universal rule. Avoid promising permanent terms you have not evaluated.
Add people where the work justifies it
Track the work that delays customers or prevents you from improving the product. A support specialist, writer or designer may be the first useful addition, depending on the bottleneck. Define the outcome, access boundaries and handoff before hiring or contracting.
Document common tasks and make room for training and review. Outsourcing a confused process does not automatically make it dependable. Check the total cost and coverage required, and ensure someone remains accountable when a contractor is unavailable.
Replace fixed customer-count milestones with evidence-based decisions. A complex service may need help at ten customers; a simpler one may serve many more with a small team. Capacity, customer outcomes, margin and cash determine the next step.
Your exercise: choose one constraint to improve
Build a monthly sheet showing recurring revenue, one-time revenue, active accounts, customers lost from the starting group, acquisition spending and delivery costs. Add a short definition beside each measure.
Recalculate the FitSite example twice: once with recurring add-ons and once with one-time setup work. Explain why cash collected and MRR can differ even when the bank deposit is the same.
Choose one observed bottleneck. Describe the evidence, a small intervention, its budget and the result you expect to observe. Examples include reducing failed provisioning jobs or helping more new customers complete setup.
Set a review date and a stop condition. Do not simultaneously buy a larger server, hire support and launch new advertising unless independent evidence justifies each expense. A focused experiment makes the result easier to interpret.
Before you move on
Scale from observed constraints and clearly defined economics. MRR is recurring gross revenue, not profit; acquisition and lifetime-value estimates depend on their assumptions. More customers are useful only when you can deliver the promise sustainably.
Sources and further reading
Adapted from the original Lesson 13: Scaling Up. FitSite is an illustrative business used for learning, not a customer success story. The worked figures are illustrative arithmetic from the original guide, with recurring and one-time revenue separated. Infrastructure choices must be verified against your own workload and provider documentation.