Customer concentration risk and hidden engineering costs

Why this risk shows up after the round

Customer concentration risk is easy to spot in a spreadsheet. If one account makes up 25% or 40% of revenue, everyone sees it. The technical side is harder to catch because it hides in delivery work, support habits, and small engineering decisions that looked harmless at the time.

It usually starts before the round closes. A startup wants a big customer, so the team agrees to a custom integration, a private deployment, a special support window, or a promise to keep an older workflow alive. None of those choices looks dramatic on its own. Most of them sit in tickets, Slack threads, and side agreements instead of the financial model.

After the round, those exceptions stop looking temporary. The company hires for growth, but engineers spend time keeping one customer's setup alive. Product plans move around that customer's deadlines. Code fills up with special cases. Hosting gets more expensive because one customer wants separate infrastructure, stricter backups, or unusual data handling.

That is when customer concentration risk turns into margin pressure. One customer can shape the roadmap, the codebase, and the hosting bill at the same time. Finance still sees strong recurring revenue. Engineering sees slower releases, extra testing, more on-call work, and less time for features that help everyone else.

Picture a common deal. A customer asks for a custom SSO flow, a nightly export into their internal system, and a dedicated hosted environment. Right after a fundraise, the contract can look great. Six months later, every release needs extra checks, the infrastructure bill is higher, and one engineer has become the unofficial owner of that account.

SaaS margin rarely drops in one big hit. It slips away in small chunks: a few hours here, a few servers there, a few delayed releases each month. That is why the risk often shows up after the round, even when the revenue story still looks strong.

Where the hidden cost starts

The leak usually begins the day a team says yes to a request that does not fit the product. On paper, the deal looks attractive. In the codebase, it creates a second product for one customer.

Sales often sees the contract first. A large account asks for a custom integration, a separate deployment window, or a promise that no other customer needs. The request feels small because it helps close revenue now. The cost appears later, when engineers have to keep that promise every week.

A healthy product change improves the product for everyone. The hidden cost starts when engineering builds a private path for one account instead. That might be a feature flag with custom logic, a forked API flow, or a branch that only one customer can use. Each exception looks manageable on its own. Together they slow testing, make releases riskier, and pull senior engineers into edge cases.

Support feels the drag next. One account has different rules, different response times, and a different set of "normal" bugs. The team writes separate runbooks, remembers special steps, and answers the same internal questions over and over. That work almost never appears in the original deal model.

Finance usually sees the revenue before it sees the drag. The monthly payment lands in the dashboard right away. The extra cloud bill, after-hours support, and release delays land in other budgets. If nobody assigns those costs back to the account, the deal looks healthier than it really is.

This is where the technical side matters. The risk is not only that one customer pays a lot. It is that one customer quietly changes how the product gets built, tested, hosted, and supported. Once that happens, SaaS margin starts shrinking long before the board deck shows it.

Custom integrations keep growing

A custom integration rarely stays small. Sales may promise, "just connect to their system," but engineering inherits a moving target.

Every new API brings more than a data pipe. The team has to map fields, handle missing values, retry failed calls, watch rate limits, and decide what to do when two systems disagree. One connector can turn into dozens of rules, and every rule needs tests.

Then the other vendor changes something. They ship a new auth flow, rename fields, change webhooks, or tighten limits. Your team has to recheck the integration, update docs, fix broken jobs, and answer customer messages. None of that feels like product progress, but it still burns real hours.

Support load often rises before finance notices the cost. When records stop matching, customers open tickets fast. They do not care whether the problem came from your app, their CRM, or a third party. Your team still has to trace logs, compare payloads, rerun syncs, and explain what happened.

Security adds another layer. If the integration touches customer data, someone has to review scopes, storage, encryption, retention rules, and access logs. If the customer asks for a special approval flow or audit trail, the connector gets even more expensive to keep alive.

The pattern is familiar. One large customer asks for a connector. Sales treats it as a closing cost. Engineering builds it. Support absorbs the weekly issues. Smaller accounts quietly subsidize the whole thing.

That last part hurts margin most. If only one or two accounts use the integration, but the whole team keeps it running, the math gets ugly fast. A simple test helps: if losing one customer would let you delete the connector, the monitoring, and most of the support work, it is not a normal feature. It is a private service dressed up as product work.

One-off branches slow every release

When one large customer gets its own branch, the team stops shipping one product. It ships a main product and a second version with its own rules, tests, and deadlines. That split looks manageable at first. A few months later, it starts eating margin.

The first hit is release speed. Every change needs extra testing because the team has to check the standard product and the customer branch. A small bug fix is no longer small. Someone has to port it twice, compare behavior, and make sure one patch does not break a workflow that only one account uses.

The drag gets worse when the customer branch blocks upgrades. Teams often postpone framework, database, or infrastructure changes because they do not want to disturb a setup promised to that customer. The result is stale code, slower releases, and a product that gets harder to maintain every quarter. Revenue may still look strong, but engineering time starts following one account instead of the broader roadmap.

The effect spreads beyond code. Documentation splits into the normal product and a growing pile of exceptions. Support needs separate playbooks. Product managers keep asking, "Is this for everyone or just that customer?" New hires feel the pain right away. Instead of learning one system, they learn the public version and the hidden version.

A familiar example looks like this: a company lands a large enterprise client and keeps a separate branch to support an old SSO flow and custom billing logic. Six months later, every release needs another test pass, bug fixes need manual backports, and the team delays a security upgrade because the client has not approved it. The contract can still look profitable on paper. The real SaaS margin is lower because the branch keeps pulling engineers into work that does not help other customers.

If a branch exists, treat it like debt with a monthly bill. Count the extra QA time, the delayed upgrades, the support exceptions, and the slower ramp for new engineers. The number is usually higher than teams expect.

Special hosting terms cut margin

Special hosting terms look harmless in a contract. Then finance sees the bill, and engineering feels the drag every week.

A large customer may ask for a dedicated environment, a fixed cloud region, a stricter uptime promise, or release approval before every deploy. Each request can make sense on its own. Together, they can turn a healthy account into a thin one.

A dedicated environment is the clearest cost. You pay for separate databases, extra compute, backups, logging, and security controls even when usage is low. If the customer grows slowly, that baseline spend stays high while revenue stays flat.

Data residency terms can hurt in quieter ways. If a customer requires one country or one region, you may lose cheaper or simpler infrastructure options. Your team may also need a second setup for storage, monitoring, and disaster recovery. That means more systems to maintain.

Custom uptime promises often cost more than the SLA line suggests. A 99.99% promise can mean more alerts, more dashboards, more incident drills, and more people on call at odd hours. The cloud bill rises, but payroll and support load rise too.

Manual deploy rules are another margin leak. Some enterprise contracts require change windows, named approvers, or freeze periods before and after releases. That slows every fix. A bug that should take 20 minutes to ship can sit for two days while someone waits for approval.

The worst part is how long these terms stick around. Customers churn, shrink, or renegotiate. The extra hosting setup, monitoring, and process overhead often stay in place because nobody wants to risk turning them off.

Ask four plain questions for every special term:

1. What does this add to monthly cloud spend?
2. How many engineer hours does it create each month?
3. Can the same term work for more than one customer?
4. Who removes it if the contract ends?

This is where customer concentration risk gets technical. One account can shape your architecture, release process, and support model far beyond its current revenue.

How to audit the technical side

Start with a spreadsheet, not a guess. Customer concentration risk often hides in small technical exceptions that nobody priced correctly. One large account can look healthy on paper while the team spends extra hours keeping its custom setup alive.

First, map every place where the product behaves differently for one customer. Look for feature flags, account checks in code, custom API fields, private deployment scripts, and manual work during onboarding. If engineers say, "only this account uses it," write it down.

Next, list every integration tied to that account and put one owner next to each one. If nobody owns it, the work will bounce between people and cost more than expected. Include outside services, internal scripts, webhooks, and reporting jobs.

Then check hosting and contract terms against your standard setup. Separate cloud region demands, single-tenant hosting, custom backup rules, uptime promises, security reviews, and extra data retention often look small in a contract and turn into monthly spend.

After that, estimate the time the account adds each month. Count support hours, release delays, QA time, incident work, cloud cost, and the extra steps needed before each deployment. If one branch must be tested by hand before every release, put a real number on that drag.

Only then compare that cost with the customer's gross margin. Revenue alone can fool you. A $300,000 account that eats $120,000 in engineering time and infrastructure is very different from a standard account at the same contract size.

Run this review account by account, starting with your top five revenue sources. The pattern usually shows up fast. You will see which revenue has normal SaaS margin and which revenue is really part product, part consulting, and part custom operations.

A realistic example after a fundraise

A B2B SaaS company closes a $150,000 annual deal soon after a seed round. The customer is large, well known, and suddenly important in every board update. Sales moves fast and signs the contract before product, engineering, and ops review the full scope.

The requests sound manageable at first: SSO, a custom export for an old internal system, and isolated hosting because the customer wants its own environment. None of that is fatal on its own. The problem starts when the team says yes to all three at once, without pricing the extra work.

Engineering ships the login work, then builds the export as a one-off job. A few weeks later, the team creates a separate branch because the customer also wants a different approval flow. Ops adds a manual deploy routine for the isolated environment because the main pipeline does not fit the exceptions.

On paper, the account looks great. In practice, the team keeps paying for it every month. Engineers patch the main product and the customer branch separately. Ops runs extra checks before each deploy because one mistake hits only that customer, but the stakes are high. Support spends time on export failures that no other customer can reproduce. Finance sees healthy revenue, but the team burns hours that never show up in gross margin.

Six months later, renewal talks begin. The customer now treats those exceptions as part of the base product. They want the same branch, the same hosting terms, and faster turnaround on change requests. The company cannot easily say no, because that one logo now makes up a large share of recurring revenue.

This is how customer concentration risk gets a technical shape. Revenue goes up, but the account earns less than it looks. The company did not just land a premium customer. It also bought a second product, a second release path, and a small pile of manual work that never stops.

Mistakes teams make when a big customer pushes

The most common mistake is calling a one-off change "temporary" and moving on. Teams say yes to close the deal, then leave the code in place because nobody owns the cleanup. A year later, that small exception shows up in every release, every test plan, and every bug triage call.

This gets worse with custom integrations. Many teams price the initial build once, put the revenue on a slide, and never count the upkeep. The real cost appears later: API changes, failed syncs, support tickets, security reviews, and late-night fixes when the customer's system breaks.

Hosting promises create a similar mess when sales makes the call without ops input. A big customer asks for a dedicated setup, unusual backup rules, a private network path, or a release window outside normal hours. None of that sounds dramatic in a contract. It becomes expensive once the team has to run it.

Another common mistake is tracking revenue by account but not engineering time by account. If one customer brings 15% of revenue but eats 35% of senior developer time, the picture changes fast. Customer concentration risk is not only about who pays you. It is also about who quietly takes over your roadmap.

Teams also let exceptions skip normal product review because the customer feels too important to challenge. That is often where one-off branches appear. Once a branch exists for one account, every release gets slower. QA has more paths to test, merges get tense, and the team starts delaying upgrades because one customer might break.

A better approach is simple. Treat every exception like a product decision with a full price tag. If you cannot name the owner, the support plan, and the removal date, it is not temporary.

Checks before you sign or renew

A large contract can look profitable on paper and still shave margin off the business every month. That happens when the commercial deal hides engineering work that never really ends.

Start with the product itself. If the request fits the roadmap and other customers may want it later, the work can pay back. If it only exists for one buyer, treat it like a custom project and price it that way.

Before signing or renewing, check a few plain things:

• Can the main product absorb the request without awkward exceptions or customer-specific logic?
• Will engineering keep one code path, or are you creating a second version that needs separate testing and release work?
• Who owns the integration when it breaks at 2 a.m.?
• What do the hosting terms add to monthly spend and support load?
• If the customer leaves in 12 months, would you keep this code, infrastructure, and support promise?

Small wording changes in the contract matter too. A promise like "minor changes included" often turns into a queue of one-off requests. The same goes for vague language around security reviews, data export formats, or dedicated environments. Sales may hear flexibility. Engineering hears open-ended work.

If the answer to removal is "we probably can't," you are adding permanent weight to the product. Call it custom scope, price it up front, set limits, and give it an end date.

What to do next

If one customer can bend your roadmap, the risk is already in your engineering budget. You do not fix that by saying no to every custom request. You fix it by setting limits early, pricing exceptions correctly, and cleaning up old promises before they eat margin.

Sales and engineering need one shared rule set. When a prospect asks for a custom integration, a separate branch, or unusual hosting terms, someone technical should review the full cost before anyone says yes. Build time is only the first bill. The larger cost often appears later in testing, support, security fixes, and slower releases for everyone else.

A simple policy works well:

• Set clear limits for custom work during sales and solution review.
• Price custom requests for both the initial build and the ongoing upkeep.
• Move repeated requests into the core product only when they fit the roadmap and more than one customer needs them.
• Retire old branches and migrate customers to standard hosting on a clear timeline.

That last step matters more than most teams expect. A branch that looked harmless during a deal can add hours to every release for months. Special hosting terms can create manual support work, odd monitoring needs, or extra compliance steps that nobody included in the original price.

Review old deals with a cold eye. Ask which custom integrations still matter, which one-off branches still ship changes, and which hosting setups still make sense. If a customer depends on an exception, give them a migration plan instead of carrying that cost forever.

Repeated requests deserve a different answer. If the same need shows up across several customers, fold it into the main product and support it properly. If it stays unique to one account, keep it separate and charge for the real cost. That line protects both your product and your margin.

If this review is hard to do internally, Oleg Sotnikov at oleg.is works with startups as a fractional CTO and advisor. He helps teams review architecture, infrastructure, and custom engineering work before it turns into a permanent cost.