B2C portal development: where the customer journey breaks
A catalog that confidently handled a dozen concurrent visitors breaks on the first day of a sale. Under peak load on the catalog, a category page is assembled from a dozen requests, the cache stops hitting, response time grows — and the customer leaves before seeing the price.
Filters add a second problem: the search index (for example, Elasticsearch) updates less often than availability changes, so some products cannot be found, while others are found where they no longer exist.
At the same time, stock desynchronization accumulates between the warehouse, catalog, and checkout: the portal promises shipment, but the item is no longer in stock.
The cart is a separate bottleneck: if it lives only in the session, then after an application restart or switching to another device the customer returns to an empty list.
This is exactly how an abandoned cart appears that cannot be recovered by email: the order contents are not saved anywhere.
The most expensive bottleneck is in checkout. While the accounting system responds, the order is created; as soon as it slows down or goes into an update, payment goes through but the order is not recorded, and it has to be sorted out manually.
B2C portal development in this form does not scale — every part of the customer journey requires a separate solution, and we will look at how this is addressed.
What a managed portal provides: speed, stability, reach
Speed of releasing sections and campaigns
A new catalog section or seasonal campaign is not a rewrite of the storefront but a configuration change: page structure, card templates, and product display rules are described declaratively.
That is why the time to release a new section is measured in days, not weeks — the team adds a schema in the admin panel, links it to the catalog, and rolls it out to production using the same process as a regular release.
Promo selections and homepage blocks are assembled from existing entities, so marketing launches a campaign without waiting for developers, and rolling back an edit remains an operation rather than a separate release.
Storefront behavior under peak traffic
A peak comes from a newsletter, a sale, or a mention by a blogger — the storefront holds up not through a “more powerful server” but through separation of environments.
Heavy catalog queries and filters are served from cache; the cart and checkout live separately and do not compete for resources with the listing.
Under load, secondary features degrade first — recommendations, “viewed also” blocks — while the path to payment remains available, so the share of successful orders does not drop along with the peak.
Recovery time after a failure is determined not by heroics but by preparation: collecting metrics for key scenarios, anomaly alerts, on-call duty, and fast rollback to the previous build. A release error is removed in minutes instead of turning into an overnight root-cause analysis.
Storefront stability directly affects repeat purchases: a customer who did not lose the cart and reached payment comes back. “Order did not go through” requests move from regular to isolated — and this is visible in the share of repeat purchases in total revenue.
Storefront on a ready-made solution, custom build, or hybrid
A B2C portal storefront is built in three ways: on a ready-made platform, with a custom build, or with a hybrid scheme where the storefront is separated from the core.
The choice is determined not by appearance but by the amount of logic — catalog, cart, personalization — that you will have to define yourself and then maintain.
Ready-made platform: fast start and boundaries
The catalog, cart, checkout, and admin panel already exist — the team launches the storefront and connects payment and delivery.
The limitations of ready-made solutions appear later: non-standard personalization, custom discount rules, and exchange with the accounting system run into the platform's extension boundaries rather than the code. Every core update has to be checked for compatibility with customizations.
Custom build: freedom and the cost of support
Here the storefront and core are written for the task: any product selection, personalization, and delivery calculation scenarios are implemented directly.
The flip side is the cost of storefront support: security updates, behavior under load on sale days, integrations, and monitoring remain with the team on an ongoing basis.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made platform | Fast launch with a typical assortment and purchase scenarios | Personalization and calculation rules — within platform extensions |
| Custom build | Non-standard catalog, cart, and pricing logic | Longer to launch, support entirely with the team |
| Hybrid scheme | The core and accounting system remain, the storefront is updated separately | Stable exchange interfaces and version control are required |
Next, we look at how the catalog, cart, and personalization are structured for each option.
Workflow: from scenario audit to handover to the team
The workflow is structured so that the catalog, cart, and personalization do not diverge at integration points.
Each stage ends with a verifiable artifact that goes into the next step — so inconsistencies in the data schema are visible before the storefront is built, not during the pre-launch run.
Scenario and data schema audit
We start by analyzing real customer journeys and current data: which product attributes are involved in filters, what personalization relies on, where the cart loses items. Then we lock down the schema and proceed step by step.
- Audit of user scenarios and data schema — journey map, list of catalog, order, and profile entities, bottlenecks in search and filtering.
- Catalog and order model design — category and attribute structure, relationship rules, price and stock versioning.
- Storefront and cart build — client and server parts, cart state, personalization and recommendation scenarios.
- Payment and delivery setup — payment scenarios with refunds and partial captures, delivery calculation, provider failure handling.
- Storefront load testing — running peak sale scenarios, cache behavior, degradation under order queues.
- Documentation handover and training — data schemas, publishing procedures, review of typical incidents with the customer's team.
After handover, the customer's team publishes catalog changes itself, while we remain on support under an agreed procedure.
Catalog, cart, account: what remains after delivery
Project delivery is not “code on a server.” After launch, you are left with a working environment that another team can spin up, update, and support without reading through chat history.
That is why we assemble documentation as work progresses rather than reconstructing it in the final week.
What the documentation package includes
- Environment configurations. Sets of variables and secrets for the development, acceptance, and production environments, with differences described. A new environment is spun up by following instructions in one pass, not by trial and error.
- Integration diagram. Direction of requests, exchange formats, and behavior when an external system is unavailable: the accounting system with products, stock, and prices, payments, delivery, notifications. The diagram shows where a response is cached and what happens on failure — this is the first thing reviewed during incident analysis.
- Access policies and roles. A “role → section → action” matrix for the administrator, catalog operator, content manager, and support service, plus a log of significant actions. You can see who changed a price or order status.
- Release procedure for updates. Branching, mandatory review, automated checks for every change set, rollout order, and rollback to the previous release. Release stops depending on one person.
- Content manager instructions. How to create a product, update prices and stock, assemble a homepage selection, prepare images, and what to do with duplicates. Catalog edits are made without contacting development.
- On-call procedure and failure analysis. Which signals are considered critical, what to check first, where to look at logs, and how to roll back a change.
- Data documentation. Storage schema, migration procedure, backup schedule, and a tested recovery scenario — not “there is a backup,” but “recovery has been rehearsed.”
The package lives in the same repository as the product and is updated along with the code. Describe the task — we will come back with an estimate and plan, including the documentation package for your environment.
Case study: how storefront failures were reduced during peak sales
The client is a retail B2C portal: a catalog with several tens of thousands of items, a cart, personal selections, and one-step payment.
On ordinary days the storefront responded steadily, but at the start of a sale traffic grew sevenfold and the system began to fall apart in a chain: the catalog served a page in 2.4 seconds or longer, some requests failed, the cart lost items when switching between devices, and the payment step dropped more often than the rest.
We identified bottlenecks based on measurements, not impressions.
Heavy faceted filters were moved to precomputation, catalog pages began to be cached with warm-up before the campaign, and the cart and sessions moved to shared storage — state no longer depended on a specific server.
The payment step was made idempotent: a repeated request does not create a second order, and failed attempts go into a retry queue. The load profile before each campaign is now reproduced in the staging environment.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Catalog response time, 95th percentile | 2.4 s | 0.4 s |
| Storefront failure rate at peak | 8% | 0.3% |
| Failure rate at the payment step | 12% | 1.8% |
| Carts that reached checkout | 61% | 78% |
| Orders per day at peak | baseline | +34% |
The cache and retry queue handle the peak without manual intervention from the on-call engineer: the sale runs on the standard infrastructure capacity, and there were no “storefront unavailable” incidents during the season.
A separate effect is rollback: if a release before a campaign behaves abnormally, returning to the previous build takes minutes and does not require data recovery.
How does a personalized storefront differ from a typical store?
A typical online store shows the same storefront to everyone: the order of homepage blocks and product selections are defined in the template and are identical for any visitor.
Storefront personalization begins where the composition and order of products are calculated by a system based on behavioral data rather than by a manager manually.
The difference is not in the design but in who decides what is shown: code with rigid rules or a model working with segments.
Customer segmentation relies on observable signals — first visit, repeat orders, abandoned cart, interest in a specific category, purchase history in the connected accounting system. Product recommendations are built on co-purchases and views, not only on manual “similar” lists.
The same catalog serves a different first screen to a newcomer, a returning customer, and someone choosing a gift.
Homepage block management is taken into a separate interface: a marketer assembles a page variant from ready-made blocks, assigns a segment, display period, and priority, and publishes without developer involvement.
Technically, this is versioned configuration — an unsuccessful variant is rolled back in minutes, not through a release cycle.
The limitation is the quality of source data. If properties, categories, and compatibility in product cards are filled in arbitrarily, neither manual selections nor an external recommendation service such as Algolia will produce relevant results.
That is why a personalized storefront begins with catalog tagging and end-to-end linking of behavior to orders, and only then with selection logic.
Concerns about the catalog, payments, and exchange with the accounting system
Before starting, what is discussed is not timelines but how the system behaves in inconvenient scenarios: what happens with a catalog of tens of thousands of items, what the customer will see when the accounting system is unavailable, and who is responsible for the integration point when it fails.
Below are answers to what we most often raise before signing the plan. The format is the same: first we analyze the risk, then we agree on how to address it.
How are the catalog and order history migrated?
We export the catalog to an intermediate storage, match items by SKU and category links, and run reconciliation by number of products, prices, and stock. First, we spin up the storefront in shadow mode alongside the current one to compare query results manually.
Order history is migrated with links to customer profiles — after switching, we reconcile the number of orders and statuses, and resolve discrepancies before opening traffic.
What will the storefront show if the accounting system is unavailable?
The storefront reads the catalog from its own storage, so product cards and search continue to work when the accounting system is not responding. Placed orders go into a queue and are passed on as soon as the connection returns.
On the confirmation screen, the customer sees an honest status — “order accepted for processing,” not “paid and shipped.” This way we do not lose orders and do not promise what the system has not confirmed.
Will search handle a catalog of tens of thousands of items?
Search works not against the catalog database but against a separate search index that is updated by product change events. We configure morphology, synonyms, typo correction, and field weights: name, category, characteristics.
Typeahead suggestions return results in fractions of a second even on a catalog of hundreds of thousands of items, and filters are calculated without a full scan.
Can personalization be added later?
Yes, we design the storefront and recommendation layer separately. Personalization first works on rules — similar products, “frequently bought with this,” recently viewed — and then a model based on view and order history is connected.
Enabling it does not require rewriting the catalog and cart, so the block can be launched in a second wave.
Who is responsible for the integration point with the accounting system?
We are responsible for the integration if it is on our side: we describe the exchange format, log errors, and set up retries and failure alerts.
If the accounting system is managed by another contractor, we fix the protocol and the boundary point — what their side provides and what we accept. Disputed cases are analyzed using the exchange log, not based on words.
Let’s discuss the task: what to send for an estimate and plan
To come back with a storefront project estimate and a stage-by-stage work plan, we do not need a ready-made hundred-page document — a description of how your business is structured and what already works is enough.
The more specific the inputs, the fewer assumptions in the estimate and the shorter the path to launch. Below is what helps assemble it fastest.
- Customer scenarios: how a person reaches the portal, how they search for a product, what they add to the cart and in what order, and at which step they most often abandon the order.
- Current setup: where the catalog currently resides and how it is updated, what existing parts we will reuse, and what we will replace.
- List of integrations: accounting system, payments, delivery, customer service, newsletters, analytics — and which of them provide data via an interface and which only via exports.
- Expected load: how many items are in the catalog, how many visitors there are on a normal day and at peak sale times, and whether there are seasonal spikes.
- Constraints: launch date tied to a campaign or season, domain and design requirements, personal data storage rules.
- Handover to support: whether you plan your own operations team or expect support from us — this determines the documentation package and the environment deployment scheme.
- Owner on your side: who makes decisions on disputed points and confirms stage acceptance.
Describe the task at this level of detail — we will come back with a storefront project estimate and a stage-by-stage work plan, with owners and acceptance points at each step.
