I Just Wanted a Storage Bin. I Built a Search Engine Instead.

The Problem

It started with a shelf. Specifically, a 14" × 11" × 8" gap in my closet that I needed to fill with a storage bin. Simple enough, right? I'll just search Amazon, Target, the Container Store.

But the problem wasn't selection. These sites carry thousands of storage products.

The problem was that none of them let you search by size.

It seemed obvious. You can filter by color, material, price, brand. But "show me everything that fits in a 14 × 11 × 8 inch space"?

Amazon doesn't.

Target doesn't.

Walmart doesn't.

The Container Store kinda does.

But I didn't want to specify range values. I just wanted a bin closest to my 14" x 11" x 8" gap.

Oh well, let's give it a try.

Welp. That's... surprising. How can a store made for organizing and finding containers not have anything close to this size?

They probably did have bins that would work for me, but the search was too strict. It would've been fine if the bin had a width of 12" instead of 14", or a depth of 11.5" instead of 11". But I wasn't keen on fiddling with the range filters and slow UX.

So I decided to build my own search tool.

Aggregating Storage Bins

The first challenge was data. None of these retailers expose a clean dimensions API (of course). And while the Amazon PA-API looked convenient, it was a chicken and egg problem when building a utility site.

To get access, you need to make 3 affiliate sales within 180 days and pass a manual site review. But to make those sales, you need the utility site you're trying to build. Which means if you want to build a tool that uses the PA-API, you first have to build it without the PA-API, so then you can later qualify for the PA-API.

So scraping it was.

I started with Amazon, as it had a huge catalog and seems preferred for convenience by most online shoppers anyways.

The scraping details are boring and nothing new.

I used Cloudflare Workflows to orchestrate things, which made it super convenient to handle cron triggers and hosting. After all, this was supposed to be a weekend project.

Parsing Dimensions

The next challenge was parsing out dimensions from product data. Dimensions appear in product data in a staggering variety of formats:

• 14.5"L x 10"W x 8"H
• 14.5 x 10 x 8 inches
• Dimensions: 14½ × 10 × 8

Dimensions are also sometimes listed as shipping dimensions rather than product dimensions. Or dimensions of the entire bundle (if multiple bins are sold together)!

I started with rule-based heuristics: regex patterns that matched the most common formats. But the edge cases were endless. I ended up layering in an lightweight LLM pass for the listings that defeated the heuristics, which handled the long-tail of weird formatting surprisingly well.

To not run up my LLM bill, I pre-filtered and sliced the product descriptions to best-guess regions and stored results based on the unique ASIN/UPC to prevent unnecessary re-parsing.

Small, cheap LLM models like Gemini 3.1 Flash-Lite were more than enough for this task.

The output of the pipeline is a normalized dataset: every product mapped to clean {width, depth, length} values.

Then came the search problem.

Building the Search Engine

Once I had clean data, I assumed search would be trivial. Filter for products where L ≤ max_L, W ≤ max_W, H ≤ max_H. Sort by distance. Done.

Except real-world use doesn't work that way, and three problems immediately surfaced.

Problem 1: Orientation Doesn't Exist in the Real World

When I'm shoving a bin onto a shelf, I don't care what the manufacturer calls "depth" versus "width." I'm going to rotate it until it fits. A bin listed as 14" × 8" × 10" is the same bin as 8" × 14" × 10" once I turn it sideways.

The top sometimes matter, sure, because that often defines the opening to a bin.

So in short:

• Most of the time, 2 dimensions are interchangeable (width x depth) = 2 permutations
• Some of the time, 3 dimensions are interchangeable (width x depth x height) = 6 permutations

I also found that manufacturers themselves would list width/depth interchangeably, since the storage bins I was aggregating often didn't have front faces (e.g. sliding drawers).

This means a naive dimension filter fails constantly.

A bin that's a perfect fit gets excluded because its labeled orientation doesn't match your search orientation. (Hence my failure with the Container Store's search)

The fix: permutation-based search. For any query {A, B, C}, I generate all six permutations of the product's dimensions.

// Perm 1 - Width-Width, Height-Height, Depth-Depth
knex.raw(
`CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END +
CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END +
CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END
AS perm1`,
[...widthWidth, ...heightHeight, ...depthDepth],
),
// Perm 2 - Width-Depth, Height-Height, Depth-Width
knex.raw(
`CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END +
CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END +
CASE WHEN (?? - ?) > 0 THEN (?? - ?) * ? ELSE ABS(?? - ?) END
AS perm2`,
[...widthDepth, ...heightHeight, ...depthWidth],
),
// Perm 3 ...

I first prioritize the 2-permutation case, as this is most common in real-world use cases: keep the "height" dimension the same, but swap width and depth to find a match.

Then I check the 4 other permutations within the search bounds, deprioritizing these but still keeping as candidates (there may be some cases where the "top" isn't important).

This alone dramatically improved recall and made results feel much more correct to a real user. There's also a nifty "Ignore box orientation" toggle in the UI (checked by default), so users can choose the orientation behavior they want.

Problem 2: Too Small Is Better Than Too Big

Sadly, this is not a double entendre. Just how storage bins work in practice.

A bin that's 0.5" too large doesn't fit. A bin that's 0.5" too small is probably fine. These are not symmetric outcomes, and a search algorithm that treats them symmetrically will surface frustrating results.

So I implemented a weighted penalty system: dimensions that exceed the search are penalized more heavily than dimensions that fall short. This keeps results sorted in a way that reflects real-world usability. Slightly undersized bins rank better than slightly oversized ones, and hard overages push products down the list rather than just excluding them at a hard cutoff.

In SQL, this looked like calculating the pairwise diffs (differences between search dimensions and actual dimensions) and adding a penalty multiplier for product dimensions exceeding the search dimensions:

CASE
    WHEN (product.width - search_width) > 0
    THEN (product.width - search_width) * penalty_multiplier
    ELSE ABS(product.width - search_width)
END

Experimenting with the penalty multiplier and layering this on top of the orientation-agnostic search made the search results even more useful.

But there was one last optimization to tackle: variance.

Problem 3: Minimizing Variance, Not Just Total Difference

Imagine you're searching for a 12" × 10" × 8" bin. Two results come back with equal total dimensional difference from your search:

• Bin A: 11.5 × 9.5 × 7.5 — uniformly close on all three dimensions
• Bin B: 10.5 × 10 × 8 — larger deviation on one dimension, close on two

Let's calculate the total distance (between search query and actual dimensions) for each bin. We get:

• Bin A: ABS(12 - 11.5) + ABS(10 - 9.5) + ABS(8 - 7.5) = 1.5"
• Bin B: ABS(12 - 10.5) + ABS(10 - 10) + ABS(8 - 8) = 1.5"

Total difference is the same. But Bin A is almost probably what you want, and Bin B might not work at all depending on your shelf geometry.

There are cases where you may be more flexible on one dimension (such as height) than another. Since this is highly context-dependent, the search engine shouldn't assume any flexibility. That's why the final search tool also has fine-grained range filters.

So once accounting for Problem 2 (overage/underage asymmetry) and Problem 1 (orientation), the next priority is minimizing variance.

I added a variance component to the ranking score, penalizing results where dimensional differences are unevenly distributed across axes. This surfaces bins that are consistently close to your target, rather than bins that happen to have a low aggregate score by accident.

Variance is calculated by averaging the squared differences between each data point (absolute value difference of search dimension and actual dimension) and the mean.

By minimizing variance by default, a storage bin is less likely to have outlier dimensions that would be awkward in the actual space.

Putting It Together

The final scoring function combines all three:

• Permutation check — try 2 orientations, then 6 orientations, and use the best fit
• Asymmetric penalty — overages hurt more than underages
• Variance penalty — reward consistent closeness across all three dimensions

Stuffing this all into one SQL query was tedious but doable with only 1-2 Common Table Expressions (CTEs).

What started as "just filter by size" became a custom spatial ranking algorithm. And it works remarkably well (I think). The results feel intuitive in a way that a naive filter never did.

Building the UI

With the search logic in place, building the UI was the last step. I decided to cater to both casual and power users.

For casual/everyday users, a big, obvious "Search" button would be most helpful. Like my ContainerStore experience, most people probably don't want to fiddle around with range sliders and min/max dimensions.

I also added a Three.js visualization of a box, helping visualize the proportions and faces.

It adjusts in real-time as the dimensions are changed. It's a fun (albeit maybe unnecessary) addition.

I also added an important clarifying note on the search dialog: "We'll match bins based on best fit, regardless of which side is labeled as width or depth"

After clicking "Search", you're brought back to the main product grid.

But now, each item shows exactly the distance for each dimension and an overall "best fit" product.

For power users, you have full control over the filtering and orientation behavior, as well as comprehensive tagging (again, thanks LLMs!).

I threw together some fancy histograms to display product frequency by dimensions. That was a fun addition that helps visualize the distribution of storage bin dimensions.

These filters allow for fine-grained searching for professional organizers or power users. The product grid updates in real-time too as you sort and filter, all while being blazingly fast (thanks to Cloudflare Workers).

My overall design philosophy for this project was utilitarian, blazingly fast, lightweight. It's designed to be highly maintainable, automated, and helpful to users.

No ads, no hard refreshes, no slow loading screens.

What I Learned

A few things surprised me building this:

Structured data is rarer than you think (or maybe not surprising). Even major retailers with enormous catalogs treat dimensions as an afterthought. They're inconsistently formatted, sometimes missing, sometimes wrong. This data surely exists with the manufacturer, but isn't readily exposed on the retail side. Probably not surprising, but shows one of the strongest use cases of LLMs.

Search is a UX problem as much as a technical one. The orientation-agnostic and variance features weren't in my original spec. They came from thinking about how a real person actually uses a bin (how I was actually looking to fill that gap in my closet) and then working backwards to what the algorithm needed to do. Ultimately, the best search relies on the context of the domain. There were many hidden assumptions underlying this seemingly trivial "find a storage bin" problem.

This started as a weekend project. The parsing pipeline, normalization, and search ranking each had more depth than expected. Combined, they became something genuinely interesting to build.

What Do You Think?

I'd love to hear any thoughts and feedback. Curious if others have run into this problem, or have thoughts on the ranking approach.

If you've ever tried to fit a bin to a specific shelf, BinSizes.com is built for exactly that problem. Enter your dimensions, get results that actually fit.

Free to use. No account or sign up. Just a humble affiliate link to fund the site :)