Adrian Synowiecki

Posted on May 15

Inside AMPER B2C: how we built an e-commerce platform on Django

#opensource #django #showdev #python

Repository: github.com/AMPLIFIER-sp-z-o-o/amper-b2c
Product page: ampliapps.com/amper-b2c

What is interesting about AMPER B2C is not a single storefront screen. It is the way the storefront, admin panel, catalog, inventory, checkout, orders, and media are tied together by one data model.

This is a practical walk through the project: what customers see, what administrators can change, and which parts of the code matter when the store is running on data that keeps changing. The article is based on the public repository and the QA environment.

1. The homepage is not hardcoded into a template

The homepage is built from database records: hero banners, product sections, banner groups, HTML blocks, storefront categories, and sliders. That means a campaign or section order can be changed from the admin panel without touching templates.

The repository also includes draft preview logic. Admin forms can save draft changes into the session, and the storefront can render those changes before they are published. It is a small detail, but it makes day-to-day content work much less fragile.

The same idea appears in dynamic pages. The DynamicPage model stores the slug, CKEditor content, basic SEO settings, visibility, noindex, and sitemap exclusion. In practice, informational pages can be linked from the navigation or footer without adding a separate view for each page.

Screen: homepage with navigation, categories, campaign banners, and product sections.

Screen: homepage sections in the admin panel, with ordering and active status.

Screen: banner configuration, images, and campaign settings.

2. The catalog is data-driven

A product in AMPER B2C is not just a name, price, and image. It has a category, status, images, price, stock, warehouses, and attributes. Attributes are modeled as separate definitions and options, so they can be reused in filters, product cards, and category pages.

Screen: catalog view with product cards, prices, attributes, cart actions, and shopping lists.

Screen: category page narrowed to a specific catalog context.

Screen: search with filtering, sorting, and pagination.

Screen: product list in the admin panel, with statuses, prices, images, stock, sales, and revenue.

One useful implementation detail is prefetching product images and tile attributes. It is not a flashy screenshot feature, but with a larger catalog it keeps product listing views away from the classic N+1 query problem.

3. The product page uses the same model

The product page renders catalog data: image, description, price, availability, category breadcrumb, and attributes. Product status distinguishes values such as active, hidden, and disabled, so a product can be hidden or left visible without allowing purchase.

Screen: product page with image, description, price, quantity, cart action, shopping list, and attributes.

4. Cart and checkout refresh data before purchase

The cart stores order lines, quantities, prices, discounts, coupons, delivery method, payment method, and totals. Before checkout, the data is synchronized with the current database state again. If someone changes a price or coupon rule in the admin panel, the customer sees the updated order before submitting it.

Screen: cart with quantity control, promo code, shopping lists, and recalculated total.

Screen: checkout with server-side data storage and expiry time.

Screen: coupon configuration with discount type, active state, date range, usage limits, and minimum cart value.

Screen: delivery methods configured from the admin panel.

Screen: product stock maintained separately per warehouse.

The most important part happens during order placement. Products and stock records are locked with select_for_update(), stock is checked again, quantities are decreased in the warehouse, the coupon is verified one more time, and only then is the order created.

5. Orders keep their own history

An order stores a copy of the customer details, delivery address, delivery method, payment details, product value, discount, delivery cost, currency, and final total. Order lines keep their own unit price and line total, so history does not change when the catalog is edited later.

Screen: orders panel with durable business records.

Stock allocation between warehouses is modeled separately as well. An order line can store which warehouse supplied the product. That is a good starting point for later ERP or WMS integrations.

6. Favorites are closer to shopping lists

In this project, favorites do not stop at a simple heart icon on a product card. A user can have multiple lists, anonymous users are tracked by session key, items remember the price from the moment they were added, and a list can be shared through a non-guessable identifier.

Screen: shopping list view in the storefront.

The login moment is interesting. Default anonymous lists can merge into the account without duplicates, while custom anonymous lists are moved to the user with automatic conflict handling for names.

7. Media can run locally or through S3

Product images, category images, banners, and media library records use DynamicMediaStorage. The same storage model can run locally or through S3 with an optional CDN, so different environments can use different media setups.

Screen: media library in the admin panel, with file metadata and source references.

What stands out in the code

The parts of the repository worth looking at are the ones that usually matter only when a real store is being used: stock locking during order placement, coupon revalidation, cart total refreshes, server-side checkout data, order data copies, merging anonymous shopping lists into user accounts, and media storage that can run locally or through S3/CDN.

These are not the most visually impressive parts of the interface, but they decide whether the store behaves predictably when data changes in the admin panel while a customer is already in the middle of a purchase.