Rentech Global sells atmospheric water generators, solar systems, affordable housing units, and sustainable food products — four different product categories, one small US team, and none of it online. We shipped a catalog-driven WooCommerce store that covers the full breadth in two weeks. The interesting part isn't the timeline. It's the taxonomy decision that let four unrelated categories share one storefront without becoming four separate builds.
Most catalogs get harder to launch as the product range widens. Rentech's range was already wide on day one: a water generator and a bag of sustainable rice do not share a size chart, a shipping class, or a buyer. The brief was not "build a store." It was "build one store four different buyers can each land on and immediately believe it was built for them."
Why one store and not four microsites?
Because the team running it is small, and four microsites means four content systems, four sets of credentials, and four places a typo can live unnoticed. A single team maintaining a fragmented storefront is a worse outcome than a slightly more complex information architecture inside one system.
The fix was in the taxonomy, not the tooling. We built category-specific product templates — water systems get technical specs and installation notes, food products get sourcing and shelf-life fields, housing units get square footage and delivery logistics — inside one WooCommerce catalog. One admin, one login, one place the team edits copy. The buyer sees a category built for what they came for. The team never touches four different systems to run it.
Why WooCommerce and not a custom build?
Because the constraint was time and catalog breadth, not platform limits. Two weeks does not leave room for a custom stack, and WooCommerce's category and attribute system was already built for exactly this problem — products that differ wildly in spec but need to share checkout, inventory, and a single admin. Reaching for something more exotic would have spent the timeline solving a problem the platform already solves.
What was the hard part?
Getting four categories to read as one brand instead of four bolted-together sub-sites. A generic WooCommerce theme applied evenly across water systems, solar, housing, and food reads exactly like what it is — a template, not a company. We built one visual system (imagery treatment, copy structure, navigation) that flexes per category without fracturing into four different-feeling experiences. The taxonomy work solved the backend problem; this solved the one a buyer actually notices first.
What shipped?
A single WooCommerce storefront organized around four product categories with dedicated templates for each, launched in two weeks. Before, none of Rentech's four product lines had a way to sell online — every inquiry moved through calls and email. After, the foundation is built to absorb new categories without a rebuild, which was the actual point: this was never going to be a four-category company forever, and the store had to outlast the current catalog, not just fit it.
What would we do differently?
Scope the category-specific template system before the two-week clock started, not inside it. It worked, but a two-week build with four distinct product templates left less room than we'd want for testing how each category performs once real traffic hits it. For any multi-category catalog with this much category divergence, the template architecture deserves its own short discovery pass before the build sprint begins — the same lesson we've applied since to catalog builds with fewer than four categories but the same underlying instinct to template first, build second, which is the same discipline behind why we scope the compliance system in the first conversation, not after the storefront work starts.
What does this build confirm?
- A wide catalog is a taxonomy problem before it's a platform problem. Four unrelated product categories can share one storefront if the templates are built per-category from the start — the mistake is applying one generic template and hoping it holds.
- A small team should run one system, not several. Microsites per category multiply the places small teams have to maintain credentials, content, and consistency. One admin with the right taxonomy beats four simpler-looking systems.
- Build for the catalog you'll have, not just the one you're launching with. The template architecture that absorbs a new category without a rebuild is worth the extra scoping time up front.
Written 2026-08-08 by Naman Barkiya.