Configuration instead of code forks for large accounts

Why private branches become a problem

The first custom deal rarely looks dangerous. A large customer asks for an extra approval step, a different report, or a small workflow change, and the team says yes by copying the product into a private branch.

The problem shows up later. The request grows, and the branch stops being temporary.

A private branch turns one product into two. Every bug fix, security patch, and feature now raises the same question: should this go into the main product, the custom branch, or both?

Picture a SaaS team with one big account that wants a custom billing rule and two extra user roles. That might help close the deal. Three months later, the main product has moved on, the custom branch has drifted, and every release needs extra testing just to make sure nothing broke for that one account.

The cost does not stay contained. Releases slow down for everyone. Engineers spend time merging changes instead of building the roadmap. Product managers start avoiding changes because each update can break custom logic. Support loses time because even simple questions depend on which customer, which branch, and which version is in use.

Hidden custom code also creates a support trap. Bugs appear only for one account, so they are harder to reproduce. Documentation goes stale because real behavior differs by branch. New engineers take longer to onboard because the product has secret exceptions. Emergency fixes get riskier because nobody feels fully sure what depends on what.

The tradeoff is plain. A private branch can help win one contract, but it quietly raises the cost of every future release, support ticket, and product decision. The revenue from the deal is easy to see. The maintenance bill usually is not.

That is why configuration usually beats code forks. When customer-specific behavior lives in controlled settings, the team keeps one product, one release flow, and one shared understanding of how it works.

What belongs in configuration

Good candidates have one thing in common: they change options around the product without changing the product's structure.

Access rules are a common fit. A plan can unlock extra reports. An admin can manage billing. A specific account can allow outside contractors to view only certain records. The product still works the same way. You are only deciding who can see or do what.

Limits and approval thresholds also fit well when they vary by customer policy. One account may allow 10 projects, another 200. A finance team may require one approval for purchases over $1,000, while a larger company wants two approvals over $10,000. Those are account rules, not a different product.

Branding is another safe area. Customers often want their own logo, colors, email sender name, and labels that match their business. One company may call a record a "case," another may call it a "ticket." Default templates fit here too, including onboarding messages, invoice text, and report layouts.

Regional differences should almost always live in configuration. Tax handling, invoice fields, language, date formats, and consent text often vary by country or industry. If you hardcode those differences for one customer, you will probably do it again for the next one.

Notification behavior is a strong fit as well. Some teams want instant alerts. Others want a daily digest at 8 a.m. local time. One account may allow email only, while another wants in-app alerts and no SMS. These choices change delivery, not purpose.

A simple test helps: put it in configuration if support or operations can describe the option clearly, set it safely, and expect the same code path to run underneath. That is how you keep large accounts happy without letting settings turn into hidden branches.

What should stay out of configuration

Configuration has limits. Some requests look like simple settings at first, then slowly turn into custom software hidden behind a toggle.

A different data model for one customer is the clearest warning sign. If one account needs extra entities, different relationships, or rules that change how the rest of the product stores data, you are no longer changing behavior at the edges. You are changing the product itself.

That kind of request spreads fast. It touches imports, exports, reports, permissions, billing, and support tools. A setting will not keep it clean for long.

A one-off workflow is another trap. If one client wants five approval steps while everyone else uses one, or needs a special handoff that exists only in their company, that usually is not a product setting. It is a private process.

Small workflow differences can still fit configuration. Turning a single approval step on or off is often fine. But when the path itself changes for only one account, the product gets harder to understand. The team starts asking, "Which version are we talking about?"

Separate release timing for one account should stay out of normal configuration too. It sounds harmless to let one customer stay on old behavior for months. In practice, that creates two products: the current one and the frozen one. QA slows down, bug fixes split, and support loses track of what each account sees.

Custom reports often slip through because they seem contained. Usually they are not. A report that only one customer wants tends to grow. First it is one calculation. Then it needs special filters, exports, and exceptions. Soon you own a private analytics product for one account.

Manual exceptions are the worst fit. If a request needs an engineer every week to patch data, rerun jobs, or override a rule by hand, do not hide that inside a setting. That is ongoing operations work, not a product feature.

Use a blunt filter before you say yes. If the request changes the data model, stop. If only one customer will ever use it, pause. If engineers must babysit it, reject it or price it as custom work. If it delays releases, it does not belong in the shared product.

Teams that stay lean learn this early. Oleg Sotnikov often works with small teams and AI-first operations, and that approach depends on keeping the product coherent. Once every large account gets its own private logic through settings, the team slows down and the cost savings disappear.

If a request needs its own schema, release schedule, reporting logic, or weekly manual care, call it what it is: custom development. You can still sell it, but it should not live inside the main product as "just one more setting."

A simple rule before you say yes

Say yes only when a request can become a product option instead of a private promise.

Four questions catch most bad decisions:

• Would at least two more customers likely want the same choice within a year?
• Can support explain the setting in one sentence?
• How many screens, rules, migrations, and tests does it add?
• Who owns this option after release?

The first question matters because big customers often ask for something that sounds small, like a different approval flow or a custom export. It rarely stays small once it touches onboarding, permissions, reports, mobile, and billing.

The second question matters more than most teams expect. If support cannot explain the setting clearly, users will not understand it either. Confusing options create tickets, workarounds, and quiet bugs.

Then count the real cost. One checkbox can turn into three states, five new tests, and edge cases on every screen that reads the same data. A request might still be worth doing, but the count keeps the decision honest.

Every option also needs an owner. One person should decide the name, default value, docs, cleanup plan, and when to remove it. Without ownership, old settings pile up and become hidden forks.

Some requests need a clean no. If the change bends your pricing model, replaces your main workflow, or puts one customer inside a different product shape, do not hide it behind a setting. That is still a private branch, even if the label sounds nicer.

How to add account-specific behavior step by step

Start with the customer's words, not internal jargon. "Our legal team needs every exported invoice to show the buyer's purchase order number" is clear. "Need custom billing logic" is vague, and vague requests are how teams drift toward private branches.

Then shrink the request until it becomes one setting, not a mini product. In the invoice example, the smallest useful option might be "Show purchase order number on invoice exports" for one account. That is far safer than building a separate export service, a custom template engine, or special code that only one customer uses.

Write down what the setting changes, where users will see it, and what should happen when it is off. If you cannot explain the behavior in two or three plain sentences, the request is still too big.

Name the setting so non-engineers can use it

Sales and support should understand the option without asking engineering to translate it. Use labels like "Require second approval before sending invoices" or "Show purchase order number in exports." Avoid internal names that only developers can decode.

Set the guardrails at the same time. Decide the default value for new accounts, the limits on what can change, and who can turn the option on or edit it. Those rules matter as much as the setting itself. A simple permission model saves time later. If only account admins can change billing options, support does not have to guess or patch around mistakes.

Test with one account before wider use

Turn the option on for the customer who asked for it first. Watch real usage for a short period. Did it solve the original problem, or did it only move the custom request one step sideways?

This trial usually reveals rough edges fast. Maybe the name is confusing. Maybe the default should be off. Maybe the setting needs one limit so customers cannot create broken exports or strange approval chains.

Oleg uses this narrow rollout style in product and infrastructure work because it keeps complexity under control while still moving quickly. Good configuration starts with a plain request, one small setting, clear ownership, and proof that it works for a real account.

A realistic example with one large customer

A large retailer asks for one change: refunds above a certain amount need manager approval before the money goes out. They do not need a separate product. They need the same product with one extra rule on their account.

A private branch looks tempting because it feels fast. One engineer can patch the refund flow and move on. The cost appears later. Every fix, test cycle, and release now has a second path to maintain, and that second path usually gets messier over time.

A better move is configuration. The team adds an account setting for refund approval, plus a threshold and the roles allowed to approve. The refund flow checks those settings while it runs. If the option is off, refunds work as usual. If it is on, the system pauses the refund and asks for approval.

That matters for operations too. Support can turn the option on for the retailer from an admin screen or internal tool. No engineer has to edit code in production. No one has to delay the next release just to satisfy one account.

A few months later, two more customers ask for the same control. At that point, the original request stops looking custom and starts looking reusable. The team already has the behavior in the product, so adoption is easy.

Then product should review real usage instead of guessing. How many accounts enabled the rule? How often do refunds enter approval? Does approval slow staff down too much? Does support get more questions after rollout? Those answers tell you whether the option belongs in the product long term or should stay narrow.

That is how large customers stay happy without splitting the product. One codebase stays intact, one release schedule stays intact, and account-level settings handle the difference.

Common mistakes that create hidden forks

Most hidden forks start with one small exception that feels harmless. A team wants to keep a big customer happy, so it adds a setting and tells itself the product is still shared. Six months later, that switch behaves like private code with a polite label on top.

The first mistake is simple: the setting name lies. A flag called "advanced mode" or "enterprise flow" sounds harmless, but inside it may run custom rules for one account only. When the name hides the real behavior, nobody knows what they can safely change.

Sales can make this worse quickly. A prospect asks for a special approval path, a custom invoice rule, or a different onboarding step. If sales says yes before product and engineering define the shape of the change, the team often ships a one-off patch and wraps it in configuration later. That is how private logic sneaks in.

Defaults matter more than teams expect. If a new setting has no clear default, every new account becomes a guessing game. One developer assumes "off," another assumes "inherit," and support has to ask engineering what the system will do. Shared products need boring, obvious defaults.

Discoverability is another common problem. Teams scatter settings across admin panels, database columns, and internal docs. Soon nobody can answer basic questions like who can change a setting, what it affects, or why it exists. If a support lead cannot describe a setting in one sentence, it is already too messy.

A quick smell test works well. The setting name is vague. Only one customer uses it. Nobody wrote a default. Support cannot describe it. The team still calls it temporary after many months. When several of those are true, you are looking at a hidden fork.

That last point causes real damage. Temporary exceptions almost never leave on their own. Teams keep them because removing them feels risky, especially when the customer still pays. Put an owner and a review date on every exception. If nobody can defend it later, delete it.

Good configuration stays visible, named clearly, documented, and reversible. If it depends on secrecy, custom code paths, and tribal knowledge, it is already a fork.

Quick checks before you ship

Ship the option only if the same codebase still runs for every account. Special behavior should come from settings, not a private branch that only one engineer understands six months later.

A good account option is boring in the best way. It has a clear default, a name people understand, and one person who owns it. If nobody owns it, nobody cleans it up, and temporary logic turns into permanent product debt.

Before release, check five things:

• The default behavior is obvious, documented, and safe for every account that does not use the option.
• One product or engineering owner decides when the option should exist, change, or be removed.
• Support can turn it on and off without asking a developer to patch production.
• Billing and contract terms match what the customer actually gets.
• The team can see which accounts use it and what breaks when they do.

Support matters more than teams expect. A switch that only developers can manage is not really configuration. It is hand-operated code. Support should know when the option is allowed, what it changes, and what to do if a customer asks for it at the wrong plan level.

Money matters too. If sales promises custom behavior but billing treats it like a standard plan, confusion starts fast. The customer expects one thing, finance sees another, and engineering gets stuck in the middle. Put the option into the contract language, the plan rules, and internal notes before it reaches production.

Tracking usage is the last check, and teams skip it too often. You need to know which accounts have the option, where they use it, and where it fails. Good logs and simple dashboards save hours when one large account reports a problem that smaller customers never hit.

If the option has a default, an owner, support steps, billing rules, and usage tracking, you can ship it with confidence. If even one of those is missing, you are probably building a hidden fork.

What to do next

If you want this approach to work, start by cleaning up the requests you already accepted. Most teams wait until the product feels messy. By then, the cleanup costs more.

Pull every special request from your top accounts into one place. Include old promises from sales, hidden support workarounds, custom exports, one-off billing rules, and UI exceptions that only one customer sees.

Then sort each item into one of three buckets: a reusable setting that fits the product, roadmap work that should become standard for everyone, or paid custom work that does not belong in the core product.

That step alone clears up a lot. Teams often discover that half of their "special" work is really normal product improvement, while another chunk never should have gone into the app at all.

After that, delete what nobody uses. Be strict. If an exception has no active customer, no clear owner, or no recent usage, remove it. Old settings create quiet risk because people forget why they exist, but engineers still have to carry them.

Write a short policy that sales, product, and engineering all use. Keep it plain. A request can become a setting only if more than one customer is likely to need it, support can explain it in one sentence, and engineering can test it without special manual steps.

A short checklist helps: who asked for it, who else might need it, can support turn it on without developer help, can QA test both states, and does it belong in the product at all? Review that list every month or quarter. If it keeps growing, the problem is not only technical. Your product boundaries are fuzzy, and your team is saying yes too often.

That is often where outside review helps. A Fractional CTO can look at the exceptions, product rules, and delivery flow, then tell you what should become configuration, what should stay out, and where the team is creating hidden forks by habit. If you need that kind of review, Oleg Sotnikov shares this kind of practical product and architecture advice through oleg.is.