OrbitCrates

OrbitCrates could not behave like a conventional online store. A customer’s relationship with a toy continued after checkout. Each physical item could be available, reserved for an upcoming crate, currently rented, scheduled for return, lost, damaged, or otherwise unavailable.

The original system did not model these relationships reliably. It also lacked a clear separation between the crate a customer currently had, changes they were still making, and a completed request waiting for staff to fulfill.

The product needed one consistent workflow connecting:

• The customer’s eight-item crate
• Catalog availability and reservations
• Subscription status
• Scheduled swaps
• Physical fulfillment
• Administrative review
• Customer and staff notifications
• Historical and operational records

I made the crate the center of the product. The storefront, customer account, APIs, and staff tools all needed to describe the same crate as it moved through the service.

The model separated crate activity into four stages:

• A live crate containing the toys currently rented by the customer
• A draft crate containing changes the customer was still making
• A submitted crate representing a swap awaiting staff review and fulfillment
• A crate history preserving completed changes

Each crate had eight slots. A slot could show its current toy alongside a toy leaving or arriving, allowing the system to represent both the crate in the customer’s home and the one being prepared next.

This shared lifecycle gave the customer experience, administrative tools, inventory system, and development work a common structure.

For customers, the main interface became a visual crate drawer connected to the product catalog.

Customers could see the toys they currently had, mark an item for return, reserve a replacement, reverse a pending change, review their updated crate, and submit it for fulfillment.

The interface adapted to the customer’s subscription and crate status. Someone preparing their first crate needed a different experience from someone editing a swap, waiting for a submitted delivery, or returning after their membership had become inactive.

Customers did not need to understand the underlying states. They needed recognizable actions:

• Browse available toys
• Schedule a first crate
• Prepare a swap
• Review pending changes
• Cancel a submitted delivery
• Renew an inactive membership

The experience also needed to account for the fact that every catalog entry represented a limited physical item. Selecting a toy temporarily reserved it, conflicting changes were detected, and each crate was verified before it could be submitted.

Customers received immediate feedback while the system continued to protect inventory availability behind the scenes.

The customer workflow depended on staff being able to review and complete the same lifecycle.

I designed and developed administrative experiences for managing products, customers, live crates, submitted swaps, inventory status, and crate history. Staff could review incoming and outgoing toys, approve or cancel submissions, complete fulfillment, add operational notes, and inspect the timeline of a crate.

I implemented the API and database work behind swap completion. Completing a swap updated the customer’s live crate, released returned toys, assigned incoming toys, closed the submitted request, and preserved the completed change as part of the crate’s history rather than overwriting it.

The inventory model also supported exceptions such as lost, broken, purchased, and unavailable items. Customers could report lost or damaged toys through their accounts, while staff could see those statuses when reviewing customer and inventory records.

An employee needed to answer four questions from one place: What does this family have? What is coming back? What has been reserved? What needs to go in the next box?

OrbitCrates used Shopify for commerce and product information, Recharge for subscriptions, and Firebase for customer identity and application data. I designed and implemented the API and data-layer connections between those services and the application workflows. Subscription changes, crate state, physical inventory, fulfillment, and historical records needed to stay aligned.

During my four months with OrbitCrates, I rebuilt the customer, staff, API, and data systems around a defined crate lifecycle.

Families had a clear way to manage their current toys and prepare their next crate. Staff could review submitted swaps, manage fulfillment, track physical inventory, handle exceptions, and preserve a reliable history of completed changes.

The storefront, subscriptions, customer account, staff tools, and physical fulfillment now shared one product model. I also documented the system, migration process, testing requirements, and remaining work so development could continue after handoff.

By handoff, OrbitCrates had a functioning, documented system for a complicated physical-inventory subscription. Families could use it, staff could operate it, and developers could continue the work.