Commerce Ordering System

01 — CONTEXT

Across the California State Assembly, offices and committees order what they need through one commerce platform, reaching all 80 districts, their satellite offices, and 80+ committees. They order across distinct domains: Furniture, Supplies, Equipment, Telecom, Print, Ergonomic, and Special, each with its own catalog, its own approvals, and its own definition of a complete request. The earlier system it replaced had run for over a decade, carrying nearly 100,000 records of order history. I led the rebuild over about four months with a small team: another backend engineer and a front-end developer who also handled the design. The result is one modern commerce platform on Drupal Commerce, one system underneath, a storefront for every department on top, no two alike.

02 — ONE CORE, MANY STOREFRONTS

Every department runs its own store, with its own catalog and its own rules, but underneath they all share a single core I built. Seven ordering domains, from furniture to telecom, run through one order model and one fulfillment lifecycle. The hard part was letting every department differ that much without the code splitting into a pile of special cases, and the shared core is what kept that from happening. It also keeps the platform easy to grow: a new department, or a new kind of order, extends the core once instead of becoming its own separate build.

03 — CHECKOUT, BUILT PER STORE

Checkout had to vary by store, because ordering office supplies is nothing like arranging a furniture delivery. Most domains share one multi-step checkout I shaped with our front-end developer, who also handled the design, so each store speaks its own language in its labels, contact pane, and summary while running the same proven path. Physical goods need more than a request, though: furniture and equipment can involve a scheduled delivery, or a pickup to haul away the old or broken item, so those flows add a step for the dates and details the others never need.

04 — THE ADMIN SIDE

Most of the system's weight sits on the admin side, where each department works a queue scoped to only the orders it owns. Who can order is just as controlled: each person orders only for the offices and committees they are cleared for, and only from the stores they are permitted to use, which across 80 districts and 80+ committees is its own problem to get right. Every order moves through one fulfillment lifecycle, from request to review to fulfillment, identical across every domain, so a manager who learns one queue understands them all. I kept this coherent as it grew by running code reviews and pairing with engineers through the harder parts of the order model. Above the queue sits a reporting layer that turns order history into something departments plan against: cost by district and office, forecasting, and materials and inventory. The same history that drives the queues is what each department reads to plan ahead.

05 — MIGRATION & IMPACT

Nearly 100,000 records of order history had to come across from the legacy system. I led the migration as a staged pipeline: extract, map, validate before load, then verify against the source, so the new system started on data it could trust.

Two outcomes mattered to me as much as the engineering did. First, the Assembly wanted a modern, cohesive experience for staff, and advanced features the older system could not support. The new platform delivered both: storefronts that feel like one modern, polished product, and the foundation for features that were out of reach before. Second, the architecture is matched to the Assembly's business process, so as offices, committees, and their workflows change, the platform adapts with them instead of needing another rebuild. Understanding how the Assembly actually operates was as much the job as writing the code. Since launch, the Assembly has gained a range of new capabilities with little friction from the old system, and its full order history was preserved intact.