Container One is moving its old Shopify custom pricing into a new Django hub. We matched the old prices on all 41 products first. The move is still under way, one endpoint at a time.
Autonomous is a Shopify systems agency. We build and repair the systems behind stores for the founders and staff who run them. Every figure on this page comes from our own project record for this build, checked in September 2026.
The quote depends on where the container starts
This is a Shopify custom pricing job. The price a buyer sees turns on which depot the container leaves from. A plain catalogue price cannot answer that.
Container One sells shipping containers and portable storage on Shopify Plus. The delivered price rests on three things. The product. The stock on hand. The trip from a suitable depot to the buyer.
The firm had bought a PHP app years back. It sat between those choices and the store. To replace it, we had to keep the behaviour that staff and buyers relied on. The store had to keep quoting and taking orders the whole time.
Container One came to us as a buyer of Memox, our own customer-engagement product. We were moving them onto a new CRM, the system that holds their customer records, and we saw more in the store worth fixing. A paid audit followed. That audit led to a run of small, scoped builds.
Stabilise the old system before moving its jobs
The audit mapped the app, the Shopify link, the CRM link and the deploy path. A second pass tested each finding against the server, the live API and the source code. We fixed the notes before they became a work plan.
The old app still needed care. We split the CRM switch from the price sync, so pausing one did not stop the other. We fixed sale prices. We fixed a bug that kept products from going live. We fixed a third bug that broke new variants, one size or version of a product, and threw the error away instead of reporting it.
That work gave the move a real start point. We knew the system, and we knew which jobs to lift out of it. A rewrite does not excuse you from fixing today’s bug in the app the business still runs.
Workflow: Legacy behaviour → Pricing parity → Staged endpoint moves → Django hub.
Build Shopify pricing parity into the new hub
In plain terms: the new system had to give the same answer as the old one before anyone could switch to it. Parity means the same inputs give the same output.
The new hub runs on Django, a Python web framework. It holds depot data, stock and price requests. It looks up ZIP codes, works out distance, and caches answers so it does not redo the same sum. Some product types get their own path. Each depot’s trade rules stay in the system the client owns.
Before any store traffic moved, we ran a written comparison. The new code matched the old one on all 41 products we tested. That is a bounded result, not a claim about every case. It was the gate we used before we moved tested behaviour.
The hub also takes Shopify events into a queue, a waiting line of jobs to work through. It keeps products, stock and other records in step. Its error handling tells a brief outage apart from bad data. A sweeper picks up stuck jobs and knows when to stop, so a failed one is not retried for ever.
Move the storefront one endpoint at a time
In plain terms: the store moves one page behaviour at a time. There is never a day when all of it has to work at once.
An App Proxy sits in front. An App Proxy is a Shopify feature that lets your own server answer a URL on the store’s domain. Ours sends each request to the old app or the new hub. So ZIP checks, container prices and stock can move over one endpoint at a time. An endpoint is one address the store calls for one answer, such as the price for a ZIP code.
A new API replaced a hand-edited sheet for sale quantities. It has a logged-in write path and an audit log driven by orders. Sale counts per depot now have a real interface and a recorded drop when an order uses one.
Checkout has its own boundary. We built a Shopify Function for delivered cart prices and tested it in a sandbox. A Shopify Function is small code that runs inside Shopify’s own checkout. As of September 10, 2026 it was not live in the store. That cutover, the day checkout switches over for good, is still a step of its own.
Pricing is less of a worry; the move goes on
Pricing is no longer a worry for Nic at Container One. That is my own read of the account, not a survey.
The record so far: a price hub that is easier to maintain, matched prices on the products we tested, repaired sync in the old app and a staged route for the rest. The PHP app is part retired. The move goes on. The work stays a run of scoped builds, each one grounded in the system the business actually runs.
People behind the work
Questions and answers
Is the legacy PHP application fully retired?
No. As of September 10, 2026 it was part retired, and the move was still going on.
Was the Shopify Function running in production?
No. We built it and tested it in a sandbox. This case does not claim a finished checkout cutover. Yet.
How was the new pricing engine checked?
We ran a written comparison. The new code matched the old one on all 41 products we tested, before the store was pointed at new endpoints.
Can Shopify handle custom pricing that depends on the customer's location?
Not from the catalogue alone. Here the price turns on the product, the stock on hand and the trip from a suitable depot. So a Django hub answers the request behind an App Proxy. We built a Shopify Function for delivered cart prices and tested it in a sandbox, but it was not live as of September 10, 2026.
What is the engagement model?
Container One began as a Memox buyer. A paid audit led to a run of scoped builds, not a retainer.