The operating portal uses PHP and MySQL, with Google Sheets as a controlled migration source and CSV for reviewed imports and exports. Product identity is shared with the inventory and planning workflows rather than recreated in each screen.
Product data is easy to underestimate because a spreadsheet can hold it. The complexity appears when sales, inventory, purchasing, merchandising, and reporting all need the same product to mean the same thing.
Start with the real hierarchy.
For this operation, a flat SKU list was insufficient. Product identity followed a style, then a colorway, then a sellable size-level SKU. Some attributes belonged to the style, while lifecycle decisions could differ by colorway.
We modeled those ownership rules explicitly instead of copying every attribute onto every SKU. Existing SKU identifiers remained intact so historical sales and reporting relationships did not break.
A product model should reflect where the business makes decisions, not merely how the ecommerce platform displays variants.
Migration sources are not always operating sources.
The original sheets remained valuable for controlled import and reference, but automatic replacement would have left the business with two competing masters. After migration, maintenance moved into an authenticated portal with roles, audit history, and explicit imports.
This distinction is important: a source can help create the system without remaining the permanent authority.
The operating model included
- Hierarchical browsing from styles to colorways to SKUs.
- Bulk creation with validation and atomic commit.
- Search, filters, lifecycle changes, and controlled CSV exports.
- Role-based maintenance and an audit trail.
- Compatibility fields for downstream systems during transition.
Governance makes the catalog reusable.
Once product identity was controlled, inventory screens could enrich quantities with consistent style, color, size, and lifecycle information. Sales reporting could use current master data without relying on inconsistent titles captured at the time of sale.
The catalog became infrastructure for future warehouse, planning, and commerce work, not because it held more fields, but because ownership and change were explicit.
Decide who owns a field before building another screen
A product catalog often becomes inconsistent because several tools can edit the same idea in different ways. A spreadsheet may describe a style, a portal may display a colorway, and an operational screen may work at SKU level. Without clear ownership, a convenient edit in one place can create ambiguity elsewhere.
The model separates those levels while keeping their relationships intact. Stable identifiers let another screen refer to the same product without reconstructing its identity from a display name. That supports reuse without making every interface a competing master record.
Controlled imports are part of the same design decision. Reviewing a proposed change and applying a bulk update atomically helps prevent a partially updated catalog from becoming the new baseline. Role boundaries and an audit trail make responsibility easier to follow.
The point is not to eliminate every spreadsheet. It is to define where a change belongs and how it reaches the shared record. That makes catalog maintenance a controlled operating workflow rather than a series of disconnected corrections.
Reusable pattern: model the decision hierarchy, preserve stable identities, migrate deliberately, and give recurring maintenance one governed home.