All articles
Blog Daniel Yoon 5 min read

Why We Built a Personalization Layer, Not a Commerce Platform

Why We Built a Personalization Layer, Not a Commerce Platform

When we were deciding what Aislegleam would be, the most tempting path was to build a complete commerce platform. Competing with Shopify is a different business from layering on top of it. A platform captures more of the value chain and owns more of the customer relationship. Every SaaS founder has thought through this trade-off at some point.

We chose to build a layer. That decision was not obvious at the time, and it is worth explaining the reasoning, because it reflects a specific view about where the real problem is in DTC e-commerce and what it actually takes to solve it.

The Replatforming Reality

Replatforming is a 6 to 18 month project depending on catalog complexity, integration depth, and team capacity. For a mid-market DTC brand on Shopify Plus, a platform migration involves transferring product data, customer records, order history, integrations with 3PLs and payment processors, custom storefront code, email flows, analytics configurations, and the accumulated institutional knowledge of the team about how everything connects. The downside risk is substantial: site performance issues during migration, SEO disruption, customer experience degradation, and team attention consumed by the project rather than by growth.

This means that brands on existing platforms - which is the overwhelming majority of mid-market DTC - are not in the market for a platform replacement. They made a significant investment in their current stack, they have built operations around it, and the bar for replacement is extremely high. Even brands that have legitimate grievances with their current platform often decide the risk-cost calculation of migrating does not pencil out.

If we had built a platform, we would have been selling primarily to brands that are already in the process of migration, or to new brands making their initial platform selection. That is a much smaller addressable market than the population of brands that want to improve their personalization without changing their stack.

The Problem Is in the Intelligence Layer, Not the Platform Layer

Shopify is good at what it does. WooCommerce is a reasonable choice for a certain category of operator. BigCommerce handles catalog complexity well. The commerce platforms have gotten genuinely capable over the past decade, and for most DTC use cases, the limiting factor in conversion performance is not a deficiency in the platform - it is the absence of per-session personalization intelligence sitting above the platform.

A catalog on any major platform has the same structural problem: the surfacing logic is aggregate, not individual. The homepage shows the same products to every visitor. The search results reflect a fixed relevance model that does not account for the specific intent signals in the current session. The recommendation widgets show products based on static "frequently bought together" rules. These are platform-level defaults that are designed to be reasonable for the average visitor, not for any specific visitor.

The intelligence gap is not something that better platform features close, because the intelligence problem is fundamentally about reading individual session signals and acting on them in real time. That requires a continuous data pipeline, session modeling, and real-time scoring infrastructure - which is not what commerce platforms are built to be. They are transaction processing and content management systems. The personalization layer is a different kind of infrastructure sitting adjacent to the platform, not replacing it.

The Architectural Decision

Building as a layer means several concrete things. The product attaches to an existing storefront via API or JavaScript tag, not by replacing it. The session signals we process - views, clicks, search queries, add-to-cart events - are ingested from the existing store's event stream. The ranked product sets we compute are delivered back to the storefront's existing surfaces: the homepage slots, the recommendation widgets, the search results layer. The operator's existing theme and storefront code remains intact.

This means the integration timeline is days to weeks, not months. A brand that decides to work with Aislegleam can have personalization running on their homepage within a week of the decision without touching their underlying platform, their checkout flow, their logistics integrations, or their team's operational workflows. The personalization layer operates as an augmentation, not a replacement.

It also means the operator retains their existing vendor relationships and the sunk investment in their current stack. Their Shopify development expertise, their email platform integrations, their payment processor relationships, their storefront customizations - none of that needs to be rebuilt. The layer adds capability to what exists without requiring the operator to abandon it.

What This Means for the Operator's Team

A platform migration puts a brand's team in execution mode for an extended period. The engineers are on the migration, the operators are managing the transition, and everyone is managing risk rather than focusing on growth. When the migration is done, the team has to re-learn a new system and rebuild the institutional knowledge about how everything connects.

A layer approach keeps the team in growth mode. The merchandising team continues working in the tools they know. The engineering team handles an integration project measured in weeks, not months, and then operates an additional service rather than a replacement platform. The attention cost is bounded and predictable. The operation returns to normal before the personalization investment even starts showing up in the metrics.

The Trade-Off

The layer approach is not without limits. We do not control the full user experience. We cannot optimize the checkout flow. Our ability to access and act on signals is constrained by what the platform exposes through its event streams and APIs. If an operator wants to do something that requires deep platform modification, the layer approach cannot help with that.

For the specific problem we are solving - personalizing what products each shopper sees across the homepage, PDP, search, and cart - the layer approach provides sufficient control without requiring platform ownership. The signal we need is the session behavioral data. The surfaces we need to influence are the recommendation and surfacing slots. Both are accessible via standard integration patterns without owning the platform stack.

The decision to build a layer rather than a platform reflects a specific belief: that the personalization problem in mid-market DTC is an intelligence problem, not a platform problem, and that solving it does not require replacing infrastructure that already works.