How I Review SFCC Cartridges (and Why It Matters)

One of the most fascinating parts of my career has always been fixing what is broken.

Not because I enjoy production issues.

Because I enjoy understanding why they happened and making sure they never happen again.

For me, debugging has never been about finding the line of code that caused an error.

It's about understanding every possible way a system can fail.

That mindset has shaped how I write code, review code, and mentor developers every day.

The Pattern I Keep Seeing

I've worked with Java applications, PHP frameworks, and now Salesforce Commerce Cloud.

Across all of them, I've noticed one common pattern.

Every project starts with coding standards, architecture guidelines, and documentation.

As the project grows, those standards slowly fade away.

Every developer has a different way of solving problems. Deadlines become tighter. Shortcuts are introduced. Documentation becomes outdated.

The first casualty isn't performance.

It's maintainability.

Once maintainability is lost, every production issue becomes harder to investigate, every new feature takes longer to build, and every upgrade becomes riskier than it should be.

That's when teams start saying things like:

"Don't touch it. It works."

or

"Let's not optimize it. We might break something."

Those statements usually aren't signs of stability.

They're signs of accumulated technical debt.

Small Problems Rarely Stay Small

One thing I've learned over the years is that the biggest production incidents often begin with tiny implementation decisions.

Consider this example.

javascript
Transaction.begin();

// Business logic

Transaction.commit();

At first glance, nothing looks wrong.

But what happens if an exception occurs before Transaction.commit()?

If the transaction isn't wrapped properly with error handling and rollback logic, you've introduced a problem that may only appear under specific production scenarios.

Another common example is performance.

Placing an expensive operation inside a loop might seem harmless during development.

When that same code processes thousands of records in production, it suddenly becomes the bottleneck everyone is trying to explain.

These aren't difficult bugs.

They're the kinds of issues you begin to notice only after spending years debugging real production systems.

AI Makes This Even More Important

AI has dramatically improved developer productivity.

I use it every day.

But I've also noticed something.

AI generally solves the problem you describe.

It doesn't automatically solve the problems you forgot to describe.

If you ask it to fix one scenario, it'll usually fix that scenario well.

It won't necessarily think about the ten other edge cases unless you explicitly ask for them.

That's why reviewing AI-generated code is becoming even more important.

Experience still matters.

Years spent debugging production issues teach you to ask questions that AI simply cannot ask by itself.

Why I Keep Asking My Team to Rework Code

Anyone who's worked with me knows I frequently ask for changes even when the implementation already works.

Sometimes the feature is complete.

Sometimes it even handles multiple edge cases.

Yet I still ask for another revision.

Not because the implementation is bad.

Because small implementation details have a habit of becoming expensive production problems months later.

I'd rather spend another hour reviewing code than another weekend investigating an outage.

Third-Party Cartridges Deserve the Same Review

This mindset doesn't apply only to custom code.

It applies equally to every third-party cartridge integrated into an SFCC project.

Recently I reviewed a headless cartridge that exposed Site Custom Preferences through a public endpoint.

A simplified version looked like this:

javascript
var prefs =
    "c_prefs" in request.getHttpParameterMap()
        ? request.getHttpParameterMap().get("c_prefs").getStringValue().split(",")
        : "";

var systemPrefs = dw.system.Site.current.preferences.custom;

var data = {};

prefs.forEach(function (prefKey) {
    if (prefKey in systemPrefs) {
        data[prefKey] = systemPrefs[prefKey];
    }
});

return data;

Technically, the implementation is correct.

But is it secure?

The only validation performed is checking whether the request parameter exists.

There is no allow-list.

No access control.

No validation of which preferences should actually be exposed.

That means anyone who knows a preference name can potentially retrieve its value.

The endpoint doesn't expose only the cartridge's configuration.

It can expose any Site Custom Preference.

Many SFCC implementations store API credentials, integration secrets, feature flags, and other sensitive configuration inside Site Preferences.

While sensitive values should ideally be stored elsewhere, the reality is that many projects still keep them there.

That's why reviewing third-party cartridges is just as important as reviewing your own code.

Just because a cartridge is published doesn't automatically mean it's production-ready.

What I Review

When reviewing an SFCC cartridge, I look beyond whether the code executes successfully.

Some of the areas I evaluate include:

• Overall architecture and project structure
• Readability and maintainability
• Coding standards and consistency
• Security risks
• Performance bottlenecks
• Upgrade readiness
• Backward compatibility
• Technical debt
• Long-term maintainability

The goal isn't to criticize code.

It's to identify risks before they become production incidents.

What's Next?

Next week, I'll be publishing the first public SFCC Cartridge Audit Registry on SFCC Tales.

The idea is simple.

Create a transparent collection of SFCC cartridge reviews that helps developers and engineering teams better understand the quality, maintainability, security, and engineering health of the SFCC ecosystem.

I hope it becomes a useful resource for anyone evaluating cartridges before integrating them into production.

I'm excited to share the first results.