Protect margin during rapid growth with outside CTO help

Why growth can cut margin

Fast growth feels like a win until profit starts slipping. That usually happens when each new sale brings extra work that never made it into the price.

It starts small. One customer asks for a special contract term. Another wants a custom report. A sales call ends with a promise of faster replies or extra onboarding. None of these choices looks dangerous on its own, so the business keeps moving.

The cost shows up later. Engineers spend less time on the core product and more time on one customer's request. Support handles edge cases that were never part of the plan. Product work slows, releases slip, and the team still feels busy all day.

Discounts do the same thing more quietly. A 10% cut to close a deal can feel harmless. Then another customer wants the same price, and a third asks for free setup because someone else got it. Margin drops little by little, and nobody notices until a strong sales month turns into a weak profit month.

Custom work almost always costs more than the first estimate. Building the feature is only the start. The team also has to test it, explain it, fix bugs, and keep it working as the main product changes. What looked like one paid request can become a long tail of unpaid work.

Support promises pile up the same way. If sales offers weekend help, faster response times, or hands-on troubleshooting without clear limits, someone has to do that work every week. As the customer count grows, those promises become a standing labor cost.

A fractional CTO often spots this early because they look past topline growth. The real question is simple: are new customers buying the product, or are they buying custom effort from the team? That difference decides whether growth pays off or starts eating margin.

Where the money starts leaking

Margin rarely disappears in one big decision. It leaks through small promises that seem harmless while deals keep coming in.

The first leak is discounting. A sales team gives 15% off to close a deal, then adds free onboarding or a longer trial. Revenue still looks fine, but that customer may never cover the time they consume. If discounts are common, check who approves them, how often they stack, and whether anyone tracks margin by account.

Custom requests create the next leak. One extra report, one private integration, one "small" workflow tweak - each request sounds manageable. A few months later, the team is supporting several customer-specific versions of the same product. That costs money every time you test, deploy, or fix a bug. A fractional CTO will usually count the one-off features tied to each account and ask whether the price ever rose enough to cover the support burden that followed.

Hosting spend hides another leak because the bill looks technical instead of commercial. Split the total into fixed costs and variable costs. Fixed costs stay in place even in a slow month, such as base servers, monitoring, and software licenses. Variable costs rise with traffic, storage, API usage, and background jobs. That split shows whether growth is making the business healthier or just making the invoice larger.

The last leak sits in contracts. Support terms often sound polite until the team has to live with them. "Priority support," "same-day response," or "minor changes included" can turn one customer into a steady interruption. Read every contract and write down the exact promises your team owes.

A short review usually finds the same pattern: discounts nobody revisits after the deal closes, customers with several special requests, infrastructure bills nobody broke into fixed and usage-based parts, and support promises that sales agreed to but operations now carries.

Most teams do not lose margin because growth is bad. They lose it because small exceptions pile up faster than anyone notices.

Review custom work before it spreads

Custom requests look harmless when sales pick up. One customer asks for a report, another wants a workflow tweak, and soon your team is maintaining a pile of one-off features that nobody else uses. That is how margin slips even while revenue climbs.

Start with the last 90 days. Pull every custom feature, integration, special report, and exception your team sold or promised. Then sort each item into one of three buckets:

• Product: more than one customer wants it, and it fits the main roadmap.
• Project: one customer paid for it, and you should treat it as paid custom work.
• Stop: it adds support load, code complexity, or edge cases that do not pay back.

That sort forces honest decisions. A request is not worth doing just because a customer asked for it. It needs to earn enough, fit the product, and avoid turning into a permanent drain.

Then compare build time with contract revenue. Count the real hours, not the optimistic estimate. Include meetings, design, testing, release work, rework, and the fixes that showed up after delivery. Most teams price the first build and ignore the cost that keeps coming later.

Say you charged $6,000 for a custom dashboard. If the team spent 90 hours building it and still spends a few hours each month on fixes, the deal probably hurt you. The first invoice looked fine. The total cost did not.

This is where a fractional CTO helps. An outside reviewer can look at the work without sales pressure and say, "make this part of the product," "keep this custom and charge more," or "stop selling this altogether." That matters when one customer starts steering the roadmap for everyone else.

A simple rule works well: if a custom request creates ongoing maintenance, price the ongoing maintenance too. If the customer will not pay for that future burden, saying no is often the better move.

This is the kind of review Oleg Sotnikov often does with growing teams. The goal is simple: protect margin before custom work turns a clean product into a patchwork that gets more expensive to carry every month.

Check hosting spend before it hardens

Cloud costs get sticky fast. A team adds one bigger server for a launch, another database replica for safety, and one more logging tool after an outage. Six months later, nobody remembers why any of it still runs, but the bill stays.

Start by splitting every bill into plain buckets: compute, storage, bandwidth, and logs and monitoring. That simple breakdown tells you much more than one monthly total. A rising bill means very different things if compute jumped 40%, storage doubled, or logs grew because the team kept every event for a year.

Waste usually hides in quiet places. Idle staging servers, forgotten background workers, old test environments, duplicate alerting tools, and backup jobs for systems nobody uses can sit there for months. Each line item looks small. Together they can eat the margin from new customers.

Databases and logs deserve extra scrutiny. Teams often oversize databases early because they fear downtime, then never scale them back after traffic settles. Log retention causes the same problem. Keeping detailed logs forever feels safe, but most teams only need full detail for a short window and summaries after that.

A good review ties every cost jump to one of two things: real usage or a bad setup. If bandwidth rises because customers upload more files, that may be fine. If costs rise because images are uncompressed, environments never shut down, or three tools do the same job, the team should fix the setup instead of accepting the bill.

A small SaaS team might see hosting climb from $2,000 to $6,500 a month and assume growth caused it. After a closer look, they find a large database with low utilization, logs kept for 180 days, two observability products, and a staging cluster that runs all weekend. Traffic explains part of the increase. The rest comes from neglect.

This is often where fractional CTO advice pays off. Oleg Sotnikov does this kind of architecture review for clients by right-sizing infrastructure, cutting redundant services, and keeping operations lean without hurting uptime.

One person should own this review every month. Not every quarter, and not only when finance complains. That owner should compare the bill against usage, explain unusual jumps, and push small fixes before they turn into permanent costs.

Put support promises on paper

Support gets expensive when it lives in sales calls, chat threads, and vague memory. A rep says "we'll take care of it," a founder says "message us anytime," and soon the team treats every request like an emergency.

Write the promise down in plain language. Name the support channels you offer, the hours you monitor them, and the response time customers can expect. If email gets a reply within one business day but weekend chat does not exist, say that clearly.

Every new deal should spell out the basics: which channels the customer can use, response times for normal and urgent issues, who covers nights or weekends, what counts as a bug fix versus training or setup help, and what you charge for account-specific requests.

After-hours coverage is where many teams fool themselves. If nobody owns the phone after 6 p.m., you do not offer after-hours support. If one engineer keeps jumping in "just this once," that engineer becomes the plan, and burnout follows.

Scope matters just as much. A bug fix means your product failed to work as promised. Training means the product works, but the customer needs help using it. Those are different jobs, and they should not share the same price tag.

Account-specific work needs its own line in the contract. Custom reports, one-off imports, special dashboards, and manual data cleanup can eat half a day before anyone notices. If a request only helps one customer, charge for it or package it as paid service time.

A fractional CTO can spot this quickly by reading proposals, support logs, and renewal notes side by side. The usual fix is simple: remove fuzzy promises like "full support" or "we'll handle anything you need" and replace them with terms your team can actually deliver.

A good rule is blunt but useful: if sales wants to promise white-glove help, finance needs a price and operations needs a named owner before the deal goes out.

Run a monthly margin review

A monthly margin review should take about an hour. If it takes half a day, your tracking is too loose.

Review the same inputs every month: invoices, support tickets, refunds, change requests, and any hours spent on one-off work. Put those numbers in one simple sheet, then group them by product line or customer segment. A split like "self-serve," "mid-market," and "custom enterprise" often tells you more than one total profit number. You will spot patterns quickly when one segment creates most of the cloud bill or most of the support load.

A fractional CTO often helps here because they look at hosting, product work, and support together. Founders usually see them as separate issues. In practice, they often come from the same source: a customer promise that grew without a price change.

Custom work needs a clear flag in your review. If one account keeps asking for special exports, custom integrations, or unusual approval flows, mark it even if the monthly invoice looks fine. Those accounts often drain margin through quiet labor. Do the same for support-heavy accounts. If a customer opens 20 tickets a month on a standard plan, you have a pricing problem, a scope problem, or an onboarding problem.

Each issue needs one fix for the next month. Keep it concrete. Raise the fee for change requests. Limit support hours. Move a noisy account to a higher tier. Cut a feature that keeps creating tickets. Small fixes work better than a long list of ideas nobody owns.

One SaaS team had steady revenue and weaker profit every month. Their review showed the problem quickly: two customers generated most of the custom requests, and an old hosting setup still ran at a size they no longer needed. They changed pricing for custom work and cleaned up the infrastructure. The next month, margin moved in the right direction.

Use the same categories next month. That is how you see whether the fix worked or whether the cost simply moved somewhere else.

A simple example from a growing SaaS team

A SaaS team with about a dozen people closed three large accounts in one quarter. On paper, it looked great. Monthly revenue jumped, and the founders felt like they had finally broken through.

Then the extra work started to pile up. Each new customer wanted a custom export for finance or compliance reports. Sales said yes because the deals were large, but nobody stopped to price the work or ask whether the same export could fit all three.

Engineers spent days on one-off formats, field mapping, and edge cases. Support changed too. Instead of normal ticket volume, the team now joined weekly customer calls, answered urgent requests after hours, and handled hand-holding that was never written into the contract.

At the same time, hosting costs crept up. More customer data meant larger databases, heavier backups, and more log storage. The team added workers for imports and reporting, but never went back to trim them. Their cloud bill rose from roughly $3,200 to $6,100 in a few months, and a few extra software subscriptions pushed it higher.

A fractional CTO reviewed the numbers and saw the pattern right away: revenue had grown, but scope and operating cost had grown faster.

The fix was not complicated. The team turned three custom exports into one configurable export with a small set of options. They moved white-glove support into a paid tier with clear response times. They cut log retention, archived older data, and shut down servers that ran all day for no good reason. They also stopped accepting custom work unless it fit the product plan or came with a setup fee.

The result showed up fast. By the next billing cycle, support hours dropped, the hosting bill came down, and new requests stopped slipping in for free. Revenue stayed strong, but margin stopped falling.

That is usually how teams protect margin during growth. The problem is rarely growth itself. It is the extra work and recurring cost that sneak in while everyone is busy closing deals.

Quick checks before you say yes

Before you approve new code, extra hosting, or a special support deal, stop for a minute and ask a few plain questions:

• Does the standard product already solve most of the problem?
• Who pays for the ongoing support?
• What happens if usage doubles next month?
• Can a simpler workflow replace new code?
• What will you stop doing to make room?

That last question matters more than most founders expect. Teams often treat custom work as extra progress, when it is really a trade. You either delay product work, or you stretch the team thin and pay for it later in bugs, slow support, and rushed releases.

A simple SaaS example shows the difference. A customer asks for a custom reporting screen. The team starts planning new UI, new filters, and a support guide. A fractional CTO reviews the request and finds that the customer only needs a scheduled CSV export and one extra filter in an existing report. The customer gets the result they want, and the company avoids a feature branch that needs care forever.

This is where outside CTO help earns its keep. The useful question is not just, "Can we build it?" It is whether the team should build it, who will carry it, and what the true monthly cost will look like after launch.

Mistakes that make the leak worse

Some margin leaks start small, then turn into monthly habits. The worst part is that teams often call them "good service" or "temporary exceptions" while they quietly eat profit.

One common mistake is treating every large customer like a separate business. One buyer wants a custom export. Another asks for a separate hosting setup. A third wants a support promise outside your normal plan. Each request may sound reasonable on its own. Put them together, and you are running three versions of the same product.

Fast support causes the same problem when nobody staffs it properly. A founder promises replies in 15 minutes to close a deal, but the team still works like a normal weekday support desk. Then engineers jump into chat, stop planned work, and lose half a day to interruptions. The customer feels supported, but the company pays for that promise in lost output.

Old tools also stick around far too long. Teams keep the extra monitoring tool, the old ticketing system, the unused cloud instance, and the backup vendor "just in case." After six months, nobody remembers why they still pay for them. The bill remains. So does the complexity.

Letting senior engineers handle routine tickets is another expensive habit. If a senior developer spends two hours a day on password resets, billing questions, or simple setup issues, that cost is real. You do not see it as a line item, but it still hits margin.

One growing SaaS team learned this the hard way. They added custom work for two enterprise customers, kept legacy hosting online after a migration, and routed urgent support straight to senior staff. Revenue went up. Profit did not. Finance noticed only after margins had already slipped for a full quarter.

A fractional CTO usually checks for the same patterns early: custom promises that never made it into pricing, support response times with no staffing plan, duplicate tools left over from a migration, senior people doing repeat work that others can own, and customer exceptions that slowly changed the roadmap.

Waiting for finance to raise the alarm is too late. Finance shows the result. Someone on the technical side needs to catch the cause while the team can still fix it.

What to do next

Start with one clean month of evidence. Pull every new deal, every cloud bill, and every support ticket into one place. You need real numbers first, not guesses from memory.

Then find the biggest leak and fix that one before touching anything else. If custom requests eat 30 hours a month and bring in little extra revenue, start there. If support stays manageable but hosting spikes every week, begin with the infrastructure bill instead. Teams waste time when they try to redesign everything at once.

A good first pass is simple. Review the last month of sold work and mark anything outside the standard product. Check hosting and software bills for tools, services, or servers nobody really needs. Read support tickets and group them into bug fixes, training questions, and custom requests. Then compare the time and cost behind each group against the revenue it supports.

After that, write a few plain rules. Keep them short enough that sales, product, and support can use them without a meeting. For example, custom work needs separate pricing, hosting needs a monthly owner and a budget cap, and support needs a written scope with response times and limits.

These rules do not need to look polished. A one-page internal document is enough if people actually follow it.

If you want a second set of eyes, oleg.is is where Oleg Sotnikov outlines his Fractional CTO work around product architecture, infrastructure spend, and practical AI-first operations. That kind of outside review helps when the team knows margin is leaking but cannot see the source clearly from inside the business.

The next move should be small and specific: pick one leak, assign one owner, and check the result after 30 days.