Core systems
Catalogue & search
When you have hundreds of things to sell, findability is the product.
What it is
A catalogue built for deciding, not just listing: filters that match how customers actually narrow down, search that tolerates how they actually type, and per-item detail that answers the question before it is asked. Scales from a few dozen products to thousands of scheduled sessions.
What it looks like in our builds
How we build it
What makes ours work
The data gets structured before the interface gets designed
A catalogue is a database wearing a nice interface, and most catalogue problems are data problems. We start by getting the inventory into a proper structure — categories, variants, per-location pricing, whatever the domain demands — even when the source is a spreadsheet or an ageing site. For PITC Training we extracted 252 courses from an old WordPress site, joined them with a scheduling spreadsheet, and only then designed the catalogue on top. That order of operations is why the filters work instead of merely existing.
Filters mirror how buyers actually narrow down
Filter design starts from watching how someone chooses in this domain, not from listing every field in the database. A course buyer narrows by venue, month and format; a marketplace shopper by category, price band and rating; a parts buyer by compatibility. We build the four or five facets that match real decisions and make them respond instantly, with counts, so a buyer always knows how much inventory is behind each choice. Facets that would return zero results are disabled before they can dead-end anyone.
Search forgives how people actually type
Real search queries are abbreviated, misspelt and half-remembered. Our catalogue search matches across titles, keywords and internal codes — course codes, SKUs, part numbers — because returning customers often know the code better than the name. Where variants carry different prices, the card price follows the buyer’s selected context, like the venue they chose, rather than showing a misleading “from” price they can never actually get.
Proof
Where we've built this
Every build below contains this system. Open any one and click through it — the fastest way to judge whether we can do what you need.
PITC Training
Course platform + CRM pipeline
See how it works →
Aruva Marketplace
Multi-vendor commerce platform
See how it works →
Dwellfound
Property marketplace platform
See how it works →
Voyaera
Accommodation marketplace platform
See how it works →
Hire Creative
Services marketplace
See how it works →
Orialis Group
Corporate group website
See how it works →Questions
Asked about catalogue & search
The questions that come up when we scope this system. Anything else, ask us directly.
How large a catalogue can this handle?
The pattern is the same from fifty products to tens of thousands of rows — what changes is the indexing and pagination strategy underneath. The largest catalogue we currently run in production is PITC Training: 252 courses expanded into more than 12,000 scheduled sessions across 8 venues, each with independent pricing, filterable and searchable with windowed pagination so the page stays fast.
Can you import our existing products from another platform or a spreadsheet?
Yes, and it is usually the first task. We have migrated catalogues out of WordPress, spreadsheets and legacy systems — extracting the content, normalising it into a structured database and reconciling it against whatever secondary sources exist, like a pricing sheet that never matched the website. You review the imported data before launch, so day one starts clean rather than carrying old inconsistencies across.
Can prices differ by location, customer type or option?
Yes — variant pricing is a core part of the data model rather than an add-on. A course priced differently in Kuala Lumpur, London and Dubai; a product with size-dependent prices; trade prices behind a dealer login. The catalogue shows the price for the buyer’s selected context, and the same variant logic carries through to cart and checkout, so the price shown is always the price charged.
Does the catalogue connect to checkout and booking?
That is the point of building them as one system. Catalogue items flow into the cart with their variant and price intact, or into a booking flow where the “product” is a session or time slot. The admin side manages inventory, pricing and availability in one place, and every public surface — catalogue, search, checkout, booking — reads from that single source.
Need this in your project?
Tell us what you are building and we will show you the closest thing we have already made — then quote the real version.
Tell us what you need built
We'll put together a free working prototype of your project so you can click through it before paying anything.