We built a Blog Filter that works with more than only tags
The problem we kept running into
Our merchant publishes paper craft tutorials for a journaling and card making audience. As the blog grew, we noticed the same pattern in almost every post: a tutorial would call for specific materials, a certain paper weight, a particular adhesive, a tool or two, and readers had no way to know if they could actually make the project without first reading the whole thing, or worse, starting it and hitting a wall halfway through.
There was no structured way to say "here's what this needs," and definitely no way for someone to browse projects based on what they already owned rather than what they'd have to go buy first.
What we built
We used Shopify's metaobject system to turn supply lists into structured, reusable data instead of loose text buried in blog content. Every project now has a linked supply list: what's required, what's optional, how much, and for paper and cardstock specifically, what GSM range actually works.
That last part turned out to matter more than we expected. Paper weight isn't a nice-to-have detail, it's often the difference between a project working and not working. A card base needs enough structure to stand up. A folded box needs cardstock heavy enough to hold a crease without flimsy paper losing its shape. So instead of a single "supply" filter, we built one that understands ranges: a project might need exactly 160 GSM, or anything from 110 to 140, or "at least 140, no upper limit" for projects where going lighter simply won't hold together.
On the Projects page, a visitor enters what paper and cardstock they actually have, GSM and quantity, for as many types as they own. The page then shows which projects they can make right now, which ones they're close on (short by a sheet or two, worth trying anyway), and quietly hides the ones that genuinely won't work with what they have. No guessing, no disappointment halfway through a tutorial.
Why this isn't just a paper craft idea
Strip away the word "GSM" and what we actually built is a general pattern: match content to a person's existing inventory, not just their category preference. That pattern applies anywhere a piece of content depends on specific inputs the reader may or may not already have.
Food blogs are the most obvious example. Recipes already have structured ingredient lists in most cases, the missing piece is almost always the same one we solved: letting a reader filter by what's actually in their fridge rather than by cuisine or meal type alone. "I have chicken thighs, half a bag of spinach, and some parmesan, what can I make tonight" is a genuinely different (and more useful) question than "show me Italian recipes." A pantry-aware filter, with the same "you have this / you're close / this won't work" logic we built for GSM, would solve a real problem for a recipe blog the same way it solved one for us. Quantity matters there too, a recipe needing 500g of mince isn't makeable with 200g on hand, exactly the kind of shortfall logic we already had to build.
It extends further than food, too. A woodworking blog could filter by lumber dimensions and quantity on hand. A sewing or quilting site could filter by fabric yardage and weight, not unlike our GSM bands. A home fitness content site could filter workouts by which equipment a reader actually owns rather than listing everything as "optional dumbbells." Any content site organized around tutorials, recipes, or projects that require specific physical inputs is sitting on the same opportunity we were: the content already lists what's needed, it's just never been structured or made filterable.
What made it work
A few decisions mattered more than the others, and would carry over to any version of this:
- Separate "what's needed" from "how strict is it." Not every shortfall is the same. Some are truly workable, others aren't, we don't want to treat them identically.
- Store the real range, not just a number. A single fixed number is too rigid for how physical materials actually behave, most real world tolerances are ranges, not exact matches.
- Show the acceptance range on the content itself, not just in the filter logic. Transparency about what "close enough" means builds trust rather than confusion.
- Keep the truly optional stuff out of the filter entirely. Not everything listed on a project needs to gate whether someone can attempt it.
None of this required a custom app or a third party platform. It's native to Shopify's own metaobject and metafield system, plain Liquid, and a small amount of JavaScript doing the actual matching. If your content already lists what a reader needs to get started, the harder problem, structuring that data and building trustworthy matching logic around it, is more approachable than it looks.