The largest Magento project I had worked on up to that point was Xcite.com — Alghanim Electronics in the UAE, large catalog, heavy traffic, real production problems. Mapemall was a different kind of hard. The challenge was not volume. It was variation.
PT. Mitra Adiperkasa (MAP) is one of Indonesia’s largest fashion and lifestyle retailers. They operate hundreds of brands under one commercial umbrella: international fashion labels, local brands, sports goods, lifestyle goods. Mapemall.com was their e-commerce platform. Building it at BORN Group meant taking on a catalog that did not behave like one catalog at all. It behaved like fifty catalogs that happened to share a checkout.
Multi-brand is not just a bigger catalog
Single-brand stores have one merchandising language. Size, color, material — the same fields apply everywhere. Navigation makes sense because everything roughly belongs to the same kind of tree. Promotions, pricing, and availability all follow the same rules.
Multi-brand retail breaks most of those assumptions.
MAP’s catalog had fashion products that needed size, color, material, and fit. Sports equipment that needed compatibility, dimensions, and technical specs. Lifestyle goods with a completely different attribute set again. Each brand had its own identity, pricing logic, and in some cases, its own sense of what a “product” meant.
The first real decision was how to organize the category hierarchy: brand-first or product-type-first. That sounds abstract until you realize the category tree is not just navigation. It is what import pipelines, layered navigation, promotions, and merchandising workflows all depend on. Whatever you choose, everything else bends around that answer.
Brand-first gives you clean brand identity but fragments product discovery. If a customer wants running shoes, they should not have to know which of MAP’s brands sells the pair they want. Product-type-first preserves discovery but flattens the brand layer in ways the business cannot operate with.
What worked was designing the tree to serve both axes — brand as a meaningful browsing dimension, product type as the structural layer that governed attributes and catalog rules. Getting there took several rounds of rethinking. Planning diagrams looked sensible until import pipelines and merchandising teams started pulling on them in opposite directions.
The attribute set problem at real scale
I had used Magento’s attribute set system before, but MAP was the project that made me genuinely understand it.
Too few attribute sets and irrelevant fields show up everywhere — a sports equipment form cluttered with fashion-specific attributes, a category filter that only applies to a fraction of products. Too many attribute sets and the catalog fragments: similar products end up under different sets, reporting becomes inconsistent, import pipelines multiply because each set needs its own mapping.
The principle I kept returning to: standardize where the business could share meaning, specialize only where the difference was real and would stay real. Fashion sizing is structurally different from technical equipment specs. That deserves distinct sets. But brand-level differences in how “availability” or “material” was labeled? Probably not.
The harder problem was that the person deciding on attribute sets was not always the person who would maintain the catalog. Business stakeholders had opinions about what fields their products needed. Those opinions were reasonable in isolation and contradictory in aggregate. Every additional attribute set is a maintenance obligation. The people acquiring them rarely see that cost immediately.
EAV makes this worse by making it easy to keep adding. Magento will not stop you. But every attribute set is one more thing to map in the import pipeline, one more edge case in layered navigation, one more question about consistency when a new brand onboards. The flexibility is real. So is the cost of abusing it.
Import is architecture
Large catalog projects stop being mostly storefront work once data migration becomes the central problem. At MAP’s scale, import was not a supporting task. It was the thing we were actually building.
Source data came from many brands, many business owners, and wildly inconsistent standards of completeness. Some brands had clean, well-structured product data in consistent formats. Others had spreadsheets that accumulated over years under whatever conventions were in use at the time.
The problems that kept appearing: inconsistent attribute naming across source systems, missing required fields, brand-specific exceptions that did not fit the catalog model, category mapping that required editorial judgment rather than just technical transformation, and image and asset quality that varied significantly across brands.
Magento’s import pipeline can absorb a lot of inconsistency in the sense that it will not crash. But it will not make the catalog coherent. That required applying data rules before import, not after. Validating and transforming source data into catalog-ready shape was not pre-processing. It was product modeling. Every assumption encoded in the import script was an assertion about what the catalog would look like in production.
The lesson I kept running into: the shape of the import pipeline is the shape of the catalog. How it validates, what it rejects, what transformations it makes — those decisions directly determine catalog quality long after launch.
What a 500-brand project actually teaches
Xcite.com taught me about Magento under traffic. Mapemall taught me about Magento under complexity.
The platform could handle MAP’s catalog requirements. The attribute set system, product types, and catalog configurability are genuine tools for modeling that kind of variation. But none of that matters if the modeling is undisciplined. A flexible platform amplifies good decisions and bad decisions equally.
The part that took longest to internalize: catalog decisions are business decisions. When you decide how to organize categories, which attributes to share, which product types to treat as distinct — you are deciding how the business will search, filter, merchandise, and report on its catalog for years. That is not a Magento configuration question. It requires understanding the business well enough to model it accurately, and honestly telling stakeholders what their choices will cost to maintain.
Before Mapemall, I asked whether Magento could support a large catalog. After it, I started asking whether the team could govern the catalog well after we built it. That turned out to be the more important question.