Filtering built around the store

An online store specialising in professional audio equipment can quickly become complex. A single category may contain products from many brands, across different price ranges and with several types of availability, while customers expect to be able to narrow down the selection quickly.

Cyber Farm’s existing filtering was based on general WooCommerce functionality. It could do the job, but as the store and catalogue grew, it became increasingly clear that the solution wasn’t built specifically around the way Cyber Farm works.

At the same time, performance had become an important part of the problem. A filter isn’t much use if it makes the rest of the store slower.

Instead of starting with the question of which existing plugin could replace the old one, the starting point became: What do customers actually need?

That made it possible to strip away a large amount of generic functionality and concentrate the solution around the filters that actually make sense for Cyber Farm’s store.

The initial focus was therefore on the essentials: brand, price and availability. At the same time, the architecture was designed so that more product-specific filters can be added later, when there’s a genuine need for them.

Filtering may sound like a small feature. On a large WooCommerce store, it can be quite the opposite.

Every selection can involve product data, categories, brands, prices and stock information. If that isn’t handled properly, something as simple as a filter panel can end up affecting the performance of the entire store.

That’s why speed was treated as part of the functionality itself, rather than something to optimise afterwards.

Availability is a good example of why a custom solution can be useful.

For the customer, the question is relatively simple: Can I buy this product?

For the store, the answer can be more nuanced. A product might be physically in stock, available from a remote warehouse or available through another valid fulfilment route. That doesn’t necessarily fit neatly into a simple in-stock / out-of-stock model.

The filter can therefore work with Cyber Farm’s own availability logic, rather than forcing the store to adapt to the filter’s.

The technical side is only half the job.

Filtering also needs to be easy to understand, take up as little space as possible and work naturally alongside categories, sorting and the product listing.

This is especially important on mobile, where traditional e-commerce filters can quickly take up more space than the products the customer actually came to see.

That’s why desktop and mobile are treated as two different user experiences rather than simply the same solution at different widths.

The solution is developed directly for WordPress and WooCommerce, using the product data Cyber Farm already works with.

This means less reliance on a generic filtering layer and greater control over how products, brands, categories, prices and availability are interpreted.

At the same time, the system can evolve alongside the store instead of having to be replaced every time a new requirement appears.

The result isn’t a filter with as many options as possible. It’s a filtering system where the functionality that matters can be precise, fast and tailored to the store it serves.

For Cyber Farm, that means greater control over both the user experience and the technical solution behind it.

And just like the custom search solution, the point is ultimately bigger than the feature itself: when an online store has specific needs, the answer doesn’t always have to be another off-the-shelf plugin.

The filter is built as a solution that can evolve gradually. New filter types and new ways of navigating the catalogue can be added when they create genuine value.

That’s also how I prefer to approach development: start with the actual problem, build what’s needed and let the solution grow from there.