Building a Buyer-First B2B Product Catalog Without a Framework

Novedad Inurriaga — Fri, 10 Jul 2026 15:11:35 +0000

Most product catalog demos are designed around a shopper who can click Buy now. A wholesale buyer behaves differently. They compare carton quantities, target markets, packaging options, compliance notes, sample requirements, and launch dates before asking for a quotation.

That difference shaped a small catalog template I recently prepared for CPS Toys, a toy manufacturer and sourcing company in Shantou Chenghai. The goal was not to reproduce its production website. It was to create a focused front-end reference that helps a buyer prepare a useful first inquiry.

The project uses plain HTML, CSS, and JavaScript. There is no framework, build step, database, analytics script, or form endpoint. That constraint kept the engineering decisions visible.

Start with the buyer's next decision

The first question was not "Which component library should we use?" It was "What must a buyer decide next?"

For this catalog, that sequence is:

Choose a sourcing direction.
Shortlist one or more product groups.
State an approximate quantity and target market.
Add packaging or compliance notes.
Continue to the supplier's official contact page.

That flow avoids pretending that a B2B order can be completed with a retail checkout. Product availability, MOQ, certificates, packaging, pricing, and lead time still need direct confirmation.

Use data attributes for a small filter

Each product card has a category:

<article class="product-card" data-category="bubble">
  <h3>Bubble guns and machines</h3>
</article>

The filter buttons use matching values. The JavaScript only has to update the hidden property:

filters.forEach((button) => {
  button.addEventListener("click", () => {
    const filter = button.dataset.filter;

    cards.forEach((card) => {
      card.hidden = filter !== "all" && card.dataset.category !== filter;
    });
  });
});

For four categories, this is easier to audit than introducing state management. It also preserves the meaning of the document when JavaScript is unavailable: every card remains visible by default.

Keep the inquiry planner local

A demo form should not quietly collect business information. The template keeps the shortlist in the current browser and does not send it anywhere.

When a buyer adds a category, the script appends a unique line to a textarea. On submit, it summarizes the brief and opens the official supplier contact page. There is no hidden endpoint and no third-party form processor.

This is a useful default for open templates because it prevents accidental storage of names, emails, target prices, and launch details. A production implementation can add a backend later, together with consent text, retention rules, validation, spam controls, and an appropriate privacy notice.

Make mobile layout a structural decision

The catalog uses stable grid tracks instead of scaling text with viewport width:

.product-grid {
  display: grid;
  grid-template-columns: repeat(4, minmax(0, 1fr));
  gap: 18px;
}

@media (max-width: 980px) {
  .product-grid { grid-template-columns: repeat(2, 1fr); }
}

@media (max-width: 620px) {
  .product-grid { grid-template-columns: 1fr; }
}

The cards do not change size when filtering, and product images use a fixed aspect ratio. On small screens, the inquiry form becomes a single column and the hero statistics stack into compact rows.

Treat content accuracy as part of the code

A product template can become misleading even when the JavaScript is perfect. That is why the copy avoids hard-coded prices, unverified certification claims, or fixed MOQs.

Instead, the interface asks buyers to compare:

age range and target market;
battery and liquid formats;
packaging dimensions and instruction languages;
sample approval and inspection points;
carton quantity, logistics, and launch timing.

The full range remains on the official CPS Toys product catalog, where current product details can be checked.

What I would add in production

The next version could introduce a small JSON product schema, server-side rendering for indexable category pages, image optimization, structured data, and a protected inquiry API. I would also add automated accessibility checks and field-level validation before connecting the form to a CRM.

For the first iteration, plain browser technologies were enough. The result is easy to inspect, easy to host, and honest about where a demo ends and a real wholesale conversation begins.