How To Customize Your SaaS Without Destroying It

For most of my career, the advice on customization was simple and it was correct. Don't do it.

Say yes to enough special requests and you end up maintaining a different version of your product for every customer. Upgrades turn into a nightmare. Your roadmap belongs to whoever shouted loudest.

That advice is now out of date, and most founders haven't caught up. So let me show you how to give customers real customization without forking your product, using a split that didn't exist as an option three years ago.

Why it was a death sentence

First, let me make sure the old warning actually lands, since the numbers are worse than most people realize.

Running separate instances per customer costs somewhere between fifty and two hundred dollars a month per customer in infrastructure. A well-built shared platform runs five to fifteen. That's roughly ten times the cost, before anyone writes a line of custom code.

Then it compounds. Enterprise software teams report upgrade projects eating six to nine months of a mid-sized team's capacity, almost entirely because of accumulated customer customizations. At high debt levels, technical debt diverts up to 40% of engineering capacity away from building anything new.

Here's the symptom you'll recognize if you're already in it. One feature change requires you to touch three or more unrelated parts of your code. That's the threshold where velocity loss starts outrunning anything you can fix by hiring.

The end state is customers stuck on old releases, not because they want to be, but because upgrading them costs you more than they're worth.

So yes, the old advice was right. Now let me show you what changed.

Code forks compound. Context doesn't.

Here's the thing that changed, and it's more specific than "AI got good."

Customization used to mean forking code. A branch, a flag, a special case buried in a function, a module only one customer uses. Every one of those is permanent, and every one has to be tested, maintained and migrated forever.

Customization can now mean configuring context. Instructions, rules, vocabulary, and examples that an agent reads at runtime to behave differently for that customer.

That difference is everything. Code forks compound. Context doesn't.

A hundred customers with a hundred custom code paths is an unmaintainable product. A hundred customers with a hundred context files is a hundred rows in a table. Your codebase is identical for all of them.

This isn't theoretical, by the way. Two of the biggest software companies on earth restructured around this pattern in the same year.

Adobe launched its CX Enterprise suite at Adobe Summit 2026, built on exactly this idea, combining customizable agents, agent skills, and MCP endpoints with a governance layer. Their framing, roughly: they want their applications not trapped inside their own interface, but available as composable services that any agent can call.

Salesforce did the same thing, and we can already see it working. Their agent layer passed 1.5 billion dollars in recurring revenue, up 240%, and customers ran 3.2 billion agent actions in a single quarter. Same split. Platform underneath, agent layer on top handling what's specific to each customer.

When two companies that size make the same architectural move in the same year, and one of them already has the revenue to show for it, that's not a trend piece. That's the pattern arriving.

The split: platform and agent

So here's my system, and it's two things you manage separately.

Your platform is the foundation that's true for every customer. The data model. The core workflow. The calculations. Security, permissions, billing, audit. One codebase, one version, deterministic, boring on purpose.

Your agent is the layer that handles everything specific to one customer. Their terminology. Their process quirks. Their edge cases. The weird exception that only applies at their company.

The platform gets hardened. The agent gets configured. You manage each independently, and you manage the line between them over time.

That last part is the bit people miss, so let me say it clearly. The split isn't permanent. Things move from the agent side to the platform side as they prove themselves. That's not a failure of the design, that is the design.

Which side does it go on?

When a customer asks for something, three questions tell you where it belongs.

One. Does the answer need to be identical every single time? Calculations, money, compliance, anything that gets audited. That's platform. Always. An agent should never be the thing computing a number somebody signs their name to.

Two. Is this true for every customer, or just this one? If the answer is "just this one," start it on the agent side. You can always promote it later. You can't easily un-fork code.

Three. Would getting it wrong be embarrassing or expensive? Embarrassing is survivable on the agent side. Expensive belongs on the platform behind real guardrails.

Pro Tip – when you're unsure, default to the agent side. Starting something as configuration and promoting it later costs you a small migration. Starting it as code and trying to remove it later costs you a rewrite and an angry customer.

The promotion rule

So how do you decide when something graduates from agent to platform? There's an old rule here that works perfectly for this, and it predates AI entirely.

When three customers ask for the same thing, build it once into the platform.

One customer is a special case. Two might be a coincidence. Three is a pattern, and a pattern means it was never really customization. It was a missing feature you hadn't found yet.

I love this rule because your customers end up doing your roadmap research for you. The agent layer is a live experiment running across your entire customer base, and the patterns that show up repeatedly are pre-validated features. Somebody already wanted it badly enough to configure it themselves.

The reverse matters too. Review your agent configurations quarterly and look for things nobody uses. Customers turn on options and forget them. Those are safe to retire, and retiring them keeps the surface area honest.

Where this goes wrong

I'd be doing you a disservice if I made this sound free, so here are the four ways I've seen it break.

One. Agent sprawl. Context files nobody owns, contradicting each other, with no version control. Treat agent configuration like code. Version it, review it, test it.

Two. Putting determinism on the wrong side. I've covered this in detail elsewhere, but the short version is that if the same input has to produce the same output, that's platform, full stop. No exceptions for a customer who really wants it.

Three. Cost. Every customer-specific agent call costs you inference. Set per-customer limits and watch the spend, since this is a variable cost that scales with usage, not a fixed one.

Four. Never promoting anything. If nothing ever graduates to the platform, you've built a consulting business with extra steps. The promotion rule is what keeps this a product.

I know that's a lot of warnings. The reason I'm giving them is that this approach genuinely works, and the failure modes are all avoidable if you know them going in.

Your playbook to follow

Write down what's true for every customer. That's your platform, and it should be smaller than you think.
Put everything customer-specific on the agent side as configuration, never as code.
Run the three questions on every request. Identical every time, true for everyone, expensive if wrong.
Apply the promotion rule. Three customers asking for the same thing means build it into the platform.
Version and review your agent configurations like code, since that's what they are now.
Watch your inference spend per customer and set limits before you need them.

Sources

Where to go next

The promotion rule only works if you can tell a real pattern from a loud customer. That's what the free Problem Finder is built for, so start there: tools.bootstrappersparadise.com/problem-finder

If you want to map out your own platform and agent split with me directly, I take a small number of founders for private 1:1 coaching: bootstrappersparadise.com/#coaching

The old advice was to say no to customization, and for twenty years that was the right call.

Now you can say yes, as long as you say it on the right side of the line. Platform for what everyone needs, agent for what one customer needs, and a rule for moving things between them.