Run the storefront from Slack.
Bring storefront marketing and merchandising into Slack with a merchant agent for Salesforce commerce. Discuss the change, approve it and verify the result.
Field Notes
Things I learned
the hard way.
Architecture, commerce, AI, old web stories, and a few things I may be wrong about. I write when I have something worth working through.
Follow via RSS ↗
Published Field Notes
The purchase happened. The conversation kept going.
Stripe is integrated into Après Studio's Storefront Next checkout and Juniper AI concierge, keeping the purchase in the storefront and the shopper in control.
The website becomes the infrastructure
When shopping starts in search, social, or an AI assistant, commerce needs consistent product data, pricing, inventory, and policy across every channel.
Agents are microservices with a friendlier voice
AI agents still need service boundaries, authorization, idempotency, and recovery. A commerce demo shows where conversational orchestration breaks down.
Production is already becoming multi-model
Code written with different AI models can land in one production system. Govern context, changes, review, and deployment without confusing authorship with runtime.
No express pay is a choice to lose the sale
Apple Pay and express checkout expose the architecture behind a purchase. Fix basket totals, guest checkout, payment recovery, and order handoff together.
Bitpurity was always about the code
Why Bitpurity exists, from learning through View Source to AI-assisted development. Clean code still matters when the hard part is understanding what you ship.
I think Claude-first commerce is a thing.
Juniper integrates Claude into Salesforce Storefront Next for product discovery, comparisons, bag updates and a conversation that stays with the shopper.
AI can build the storefront. Production is the test.
I let AI build a real Salesforce storefront. The pages were the easy part. Production is where the experiment became useful.
Storefront Next won’t save a bad team
Storefront Next removes real drag. It also removes a few excuses. The team still has to understand the work.
Composable is not the same as simpler
Composable can remove a real constraint. It can also mean buying six products and pretending the integration diagram is a plan.
Architecture diagrams do not show the operating model
The boxes can all be right while the system is still a mess. The missing architecture is usually people, ownership, money, and change.
When keeping the platform is the right decision
“The platform is old” tells me almost nothing. Before funding the replacement, show me what is actually broken.
The bottleneck moves when AI writes the code
AI writes code fast. Then context, review, integration, and ownership become the queue nobody planned for.
Agentic systems need an operating model
Before we give an agent a clever name, I want to know what it can change, who owns the result, and how we stop it.
AI code review needs system context
AI can find a bad branch. I care whether it can see the locally correct change that is wrong for the whole system.
The hard part of AI delivery is recovery
AI makes change cheap. Recovery tells me whether the team owns what it shipped or just got lucky in the demo.
Enterprise AI needs boring controls
The model is new. Identity, permissions, logs, tests, limits, approvals, and a reliable stop button are not.
Technical strategy is a sequencing problem
A target architecture tells me where we want to go. Strategy tells me what moves Monday morning and which expensive decision can wait.
Roadmaps are capital allocation
A roadmap spends money, attention, and organizational patience whether leadership admits it or not. The feature boxes are the easy part.
The demo is the easy part
A vendor demo proves a prepared person can move prepared data through a prepared path. Cool. Now show me the ugly order.
Integration debt is operating debt
Integration debt is the manual reconciliation, synchronized release, and mystery ownership the business has learned to call normal.
Buy versus build is really “can you operate it?”
Buying still creates a system. Building still creates dependencies. I want to know which one the company can actually operate.
Modularity has a coordination cost
Modularity buys independent change by creating more boundaries to own. If the teams cannot own them, we bought more meetings.
Event-driven does not mean decoupled
A message broker can remove the direct call and leave every important dependency exactly where it was, just harder to see.
Every abstraction sends a bill
Every layer hides complexity and creates some of its own. I want to know who gets the bill before we add another one.
Headless commerce is an organizational decision
Headless is easy to draw. The value only appears when teams can own and change the separation without coordinating every release.
Your OMS is part of the customer experience
The storefront makes the promise. The OMS decides whether inventory, fulfillment, service, and returns can keep it.
Multi-brand commerce needs rules before platforms
Before picking one commerce platform or six, decide what the brands must share, what they may change, and who gets to say no.
SFCC technical debt or platform limit?
SFCC may be the problem. It may also be where fifteen years of custom code and operating decisions came to hide.
Technology diligence should test change
An application inventory tells me what the company owns. I want to know whether it can change any of it at the speed the deal assumes.
The first 90 days after a technology acquisition
The first 90 days are for finding out what was really bought, stabilizing what can hurt the business, and not starting six migrations at once.
Portfolio standardization can create new debt
Standardization can lower cost across a portfolio. Forced sameness can also create years of migration work nobody included in the thesis.