# How To Scale A Company Now you've had some early success, have a product, and have some customers. Now it's time to scale. Scaling starts with the loop you already proved: build, sell, learn, and improve. Your job now is to make that loop faster, cleaner, and more durable. You need to understand what users do, where they get stuck, why they leave, which customers are worth acquiring, and what to build next. This chapter covers the systems you need once your product has real users: product analytics, customer support, unit economics, and expansion. ## Start With the Scaling Loop A startup is not a static product. It is a loop. You build something. You sell it. Users try it. Some get value. Some get confused. Some leave. Some ask for features. You take that signal, decide what matters, and build again. That is the scaling loop: 1. **Build** — ship product changes that solve real user problems. 2. **Sell** — get the product in front of the right people. 3. **Observe** — watch what users actually do. 4. **Support** — help users when they get stuck. 5. **Learn** — find the patterns behind the behavior. 6. **Iterate** — improve the product, positioning, pricing, or onboarding. Early on, you can run this loop manually. You can talk to every user, watch onboarding sessions, and fix bugs in real time. You should do some of this — it gives you a feel for the customer that no dashboard can replace. But manual observation eventually breaks down. You need systems that capture signal as usage grows. Not just servers and databases, but the operating systems that help you understand, support, and improve the business. ## Add Product Analytics You cannot iterate well if you do not know what is broken. Product analytics tells you what users are doing inside your app: how many sign up, how many complete onboarding, which features they use, where they drop off, and whether they come back. Without analytics, you are guessing. Analytics does not replace user conversations, but it keeps you honest. We recommend **PostHog** for this. It gives you funnels, custom events, retention analysis, and session replay in one place. ### Set Up PostHog Setting up product analytics has two parts: installing the tool and deciding what to measure. The installation is straightforward — create a PostHog project, add the library to your app, include the project key and host in your environment variables, and identify users after they log in. The measurement part is where founders usually get it wrong. They either track almost nothing or track everything. Both are bad. Start with the few events that show whether a user is moving through your product successfully: - `signed_up` - `onboarding_completed` - `core_action_completed` - `trial_started` - `checkout_completed` - `subscription_upgraded` - `teammate_invited` - `support_ticket_opened` Use clear names, keep staging and production data separate, and do not track sensitive information like passwords, payment details, private documents, or API keys. ### Funnels, Events, Replay, and Retention - **A funnel** is a sequence of steps you expect users to complete. A funnel shows where people drop off. If 1,000 users sign up and only 150 create a first project, the problem is activation, not traffic. - **A custom event** is a meaningful action you decide to track. Track outcomes, not just page views: project created, report generated, file uploaded, teammate invited, invoice sent. - **A session replay** is a recording of how a user moves through your app. Analytics tells you where something broke. Session replay often shows you why. - **Retention** tells you whether users keep coming back. The question is not “do users come back every day?” The question is “do users come back at the natural frequency of the problem we solve?” A good analytics loop: 1. Find a drop-off or unusual pattern. 2. Watch replays for that segment. 3. Talk to a few affected users. 4. Form a hypothesis. 5. Ship a small change. 6. Measure whether the metric improves. ## Add Customer Support The users you fought to win have given you something valuable: trust. That trust has a limit. There are only so many times a product can confuse someone before they leave. Customer support exists to catch friction before it becomes churn. Early on, support should be founder-led. Watch your first customers use the product. Ask what they expected to happen. Fix bugs in real time. Listen to the words they use to describe the problem. This does not scale, but it teaches you what the product feels like from the customer's side. Eventually, you need a system. Users will show up while you are asleep. They will ask questions you have already answered. They will hit bugs you cannot personally triage in real time. We recommend **Fin by Intercom** for this — an AI support agent that answers inbound questions using your documentation, product context, and support procedures, then escalates issues it cannot resolve. ### How Fin Works A support agent is only as good as the knowledge and procedures behind it. Fin can handle common questions like password resets, billing updates, teammate invites, import failures, plan changes, and basic troubleshooting. It should not blindly handle refund disputes, security concerns, data loss, angry enterprise customers, or bugs affecting many users — those should escalate to a human or become product work. ### Build a Knowledge Base A knowledge base is the set of help articles, troubleshooting steps, and policies your support system uses to answer questions. Write docs in the language customers use, not the language your codebase uses. If users repeatedly ask the same question, either the product is unclear or the documentation is missing. Usually it is both. Start with the basics: - Getting started - Core workflows - Billing and plans - Troubleshooting - Account management - Known limitations ### Use Decision Trees A support decision tree is a structured path for handling a category of issue. Decision trees make support consistent and make escalation cleaner — the person receiving the issue can see what has already been tried. Start with the most common and painful categories: - Login problems - Billing questions - Import failures - Permission issues - Core workflow errors - Cancellations - Bugs that block users from getting value ## Understand Unit Economics Revenue tells you how much money is coming in. Profit tells you how much you keep. Both matter, but they describe the business from far away. To understand whether the business can scale, you need to look at the economics of a single customer: how much they pay, how long they stay, and how much they cost to acquire. This is called **unit economics**. Growth can hide a broken business. You can increase revenue by spending aggressively on acquisition, but if every new customer costs more to acquire than they are worth, you are not scaling — you are buying revenue at a loss. Here are the core metrics: ### Churn The rate at which customers leave. Logo churn measures the percentage of customers who leave. Revenue churn measures the percentage of revenue that leaves. Be precise about the time period — a 5% monthly churn rate is very different from a 5% annual churn rate. `Revenue churn rate = lost recurring revenue during period / recurring revenue at start of period` ### Average customer lifetime How long a customer stays before churning. The time period must match the churn rate — if monthly churn is 20%, average customer lifetime is about 5 months. `Average customer lifetime = 1 / churn rate` ### ARPU Average revenue per user or customer. `ARPU = total revenue / number of customers` ### LTV Lifetime value — how much revenue or gross profit you expect to earn from a customer over their lifetime. `LTV = ARPU × average customer lifetime``Gross margin LTV = ARPU × gross margin × average customer lifetime` ### CAC Customer acquisition cost. Early CAC is easy to understate because founder time often looks free. It is fine to do founder-led sales early, but do not assume that motion will scale without cost. `CAC = sales and marketing cost during period / new customers acquired during period` ### LTV/CAC Compares how much a customer is worth to how much it costs to acquire them. If LTV is lower than CAC, something is broken — you need to increase retention, raise pricing, improve margins, lower acquisition cost, or revisit your ICP. `LTV/CAC = lifetime value / customer acquisition cost` A useful related metric is **payback period**: how long it takes to earn back the money you spent acquiring a customer. If CAC is $600 and the customer generates $100 in gross profit per month, payback is about 6 months. Do not obsess over precision too early. With small datasets, these numbers will be noisy. The point is direction. Are customers staying longer? Paying more? Costing less to acquire? If yes, the machine is getting healthier. ## Expand the Business Once the core product works, support is manageable, and your economics are improving, the next question is how to expand the ceiling of the business. There are two broad paths. Vertical expansion Serve your existing customers more deeply. Add products, services, workflows, or infrastructure that make your product more central to the customer. Works best when customers already trust you, the adjacent pain is obvious, and the new product increases retention or ARPU. Horizontal expansion Serve a broader set of customers. Take what you built and adapt it to adjacent segments, use cases, or markets. Works best when the core technology applies to multiple customer types and the new segment has similar pain with a larger market. The danger in both cases is distraction. Do not expand because you are bored. Expand because the evidence says the current ceiling is too low or the adjacent opportunity is too strong to ignore. Before expanding, ask: ### Where is demand already showing up? Look at inbound requests, support tickets, and sales conversations. If customers keep asking for the same adjacent thing, that is a signal worth taking seriously. ### Does this improve retention, ARPU, CAC, or payback? Expansion should improve the unit economics, not just grow revenue. If it does not make customers more valuable or cheaper to acquire, it is probably a distraction. ### Will it strengthen the core product or distract from it? The best expansions make the core product better. The worst ones split engineering focus and slow down the thing that is already working. ### Can we test demand before building the full thing? Sell the expansion before you build it. Talk to customers. Get a verbal commit or a letter of intent. If nobody is willing to say yes before you build, the demand may not be there. ### Does it meaningfully increase the total addressable market? Investors call this TAM — the total revenue opportunity if you captured every customer in the market you are targeting. A small, healthy niche can be a good business. A large, expanding market can become venture-scale. Fundraising may become relevant at this stage, especially if the expansion opportunity is clear but requires more capital than the business can fund on its own. Fundraising is not the goal of scaling. It is a tool. The goal is to build a durable business that creates value for customers and captures enough of that value to keep growing. ## What Comes Next Scaling is not a single milestone. It is a discipline. Add analytics so you can see what users do. Add support so you can hear where they struggle. Understand unit economics so you know whether growth makes the business stronger or weaker. Then use that signal to build better product, sell to better customers, and expand with intention. The company gets better when the loop gets better. Keep the loop moving.