When the platform doesn't speak your business, you write the modules that do.

A catalogue PrestaShop couldn't model.

A sleep-and-wellness music label runs a hybrid catalogue: digital audio — sleep soundscapes, meditation sessions, original compositions — alongside physical media and branded accessories. The customer experience lives or dies on one interaction: can I hear enough of this track to decide whether to buy it, then add it to a cart alongside the vinyl pressing, and check out in one flow?

Off-the-shelf PrestaShop 1.7 didn't model any of that. It knew products and prices. It didn't know audio tracks with configurable sample cutoffs. It didn't know composers and narrators as first-class content entities. It didn't know that the marketing team needed to rearrange the homepage on a Tuesday without opening a code editor.

The brief was direct: build the e-commerce surface that fits this business, not the business that fits the platform.

Five modules that made PrestaShop fluent in the domain.

We extended PrestaShop 1.7.4 — PHP 5.6, Symfony 3.4, Doctrine, MySQL, Smarty — with five bespoke modules, a custom theme, and brand-correct PDF invoice templates. None of the modules were lifted from the marketplace. All five were authored from scratch to fit the specific domain shape.

The music player module gave every digital product a playable identity: track metadata, full duration, a configurable sample cutoff time set per track by the artist, and a scrubbable in-page player. The artist decides how much plays before checkout. That decision is a business rule; it lives in the data model, not in JavaScript hacks against the default product template.

The author profile module made composers and narrators first-class entities with their own profile pages, biographies, and discographies. A track knows its author. An author page lists its tracks. The relationship is queryable and manageable from the admin panel.

The homepage builder module gave the marketing team a structured surface — header blocks, banners, CTAs — that they could edit without touching the theme. The product-block module handled curated homepage showcases by category. The conditions module gave legal a self-service surface for T&Cs management. Combined with SuperCheckout's one-page flow and CM-CIC regional payment integration, the checkout captured email at the point of sale and settled in the client's regional processor without a custom payment gateway.

Custom PDF invoice templates — 877 lines, brand-correct — handled receipts server-side. The customer gets a receipt that looks like the brand they just bought from.

F · 01Music player module

Track metadata, duration, configurable sample cutoff time, and a scrubbable in-page player. The artist sets how much plays before checkout; that rule lives in the data model.

F · 02Author profile module

Composers and narrators as first-class admin entities with profile pages, biographies, and discographies. Tracks link to authors; author pages list tracks.

F · 03Homepage builder module

Structured header blocks, banners, and CTAs the marketing team edits from the admin panel — no theme access, no engineer on call.

F · 04Product-block module

Curated homepage product showcases organised by category. The operator decides what appears on the front page without touching the template.

F · 05One-page checkout + regional payment

SuperCheckout's single-page flow with CM-CIC regional payment processing and Mailchimp email capture at the point of sale. Digital and physical in one cart, one checkout.

F · 06Brand-styled PDF invoices

Server-side invoice generation — 877 lines of custom templates. Receipts that look like the brand the customer just bought from.

Extend the platform; don't rewrite it.

The temptation on a project like this is to conclude that the platform is wrong and start over. PrestaShop doesn't know what a preview cutoff is — so switch to a custom Symfony application, reach for a headless stack, argue for a different platform entirely.

None of that was warranted. PrestaShop's module system exists precisely for this. The platform handles catalogue management, order processing, inventory, tax, multi-currency, and a decade of e-commerce edge cases that are not interesting to rewrite. The gap was domain modelling — audio metadata, author entities, an editable homepage — and that gap was exactly the right size for five modules.

“

Extend a platform only where its vocabulary is wrong. Everywhere it's right, let it do the work.

”

Four months, November 2018 to March 2019, 356 commits. The extension scope was calibrated against what the platform already handled well. The modules are isolated and well-bounded. The rest is PrestaShop. That constraint is a discipline as much as a decision: if you extend only where the fit is genuinely wrong, the system the next engineer inherits is still legible.

A platform that spoke the brand's language.

The storefront shipped with a catalogue the operator could manage, a checkout that handled digital and physical in one flow, and a homepage the marketing team could edit without a support ticket.

The platform knew what an audio track was. It knew what an author was. It knew that a sample played for a configurable window and then asked for a purchase decision. Those aren't features bolted onto the side of a generic storefront — they're the domain model, expressed in code and surfaced in the admin panel.

356 commits, 4 months, 5 custom modules. The operator launched on schedule and managed the catalogue from day one without engineering support.