Guerrilla Shopping Carts

It’s that time of year again! That’s right, it’s the restless winter season where the days are long, the sun is dead, and you finally go rogue and build your own shopping cart. But why? Indeed, why, dear voices of the internet! 

There comes a day in every developer’s inane excuse for a life where you say, ‘I accept my place in society and have no friends anyway, so I’m going to write a full e-commerce application to support a vague semblance of a business idea that does not exist outside of the manic caverns of my own severed psyche’. 

In my case, that day was 9 months ago, and today, dear reader, I will recount to you the tale.

Cart dreams

Like most devastatingly powerful events, the incipient reaction began with a spark. This spark was a humble cart session. As I stared vacantly into my IDE typing and deleting nonsensical functional gibberish, I had a strong impulse overwhelm me. ‘Buying shit on the Internet is so easy, but WTF is a shopping cart anyway?’

The impulse was more than a rhetorical question, and I promptly closed my bloated Jira board to ponder this deep mystery that has only been solved for 25+ years. I simply could not continue participating in the Internet without addressing this. 

From this impulse, a new file emerged, cart-handler.tsx….

Street carts

Let’s take this idea to the streets where shopping carts abound. You grab an cart from the corral - broken wheel, soulless, dejected from a thousand parking lot batterings. This is your container. You wheel it moaning into the store, fill it up, ditch a few items before checking out, and finally cast it back empty, decisively crashing it into the herd of other forlorn carts on your way back to the car.

Carts, in e-commerce, besides suffering much less physical abuse, are just stateful containers - which are really just memory centers. You have some data coming from somewhere, you render it to a document, and now you need to relocate it and remember what you relocated. You need to keep track of what changes and update accordingly. Now toss in some event handlers for modifications like adding, subtracting, deleting, keeping count, and bada bing, you got a digital shopping cart! 

As much as I aspire to evolve out of the React cradle, tomb..?, it is a technology particularly well suited to a shopping cart feature. createContext API and the formidable useState hook are powerful allies when spinning up a cart. 

useState is pretty self-explanatory as a basic feature of managing a component’s memory between renders. In the cart, this is likely going to be focused on the data that’s coming in and going out. 

You’re gonna want to eventually pass events around the larger application too. The context object allows for managing the core cart logic in one place, and for methods to easily be extracted into another component on-demand.

So, carts really aren’t that mysterious and I’ve dug myself into a nice UI for managing some incoming product data. But how did we even get here?

Subscription hell 

As a developer (or anyone, really), paid services are the reality of life at the casino. Sometimes you can maneuver around the high stakes, negotiate a less punishing SLA, or maybe you call the house and try to roll your own implementation, but you’re going to eventually pay someone to enter the room and sit at a table. From registrations and hosting to storage / usage / seats based pricing and name your (P)(I)(S)AAS provider, the Internet is a recurring death by ten thousand cuts from which you will never be set free. Anytime you can reduce or eliminate a cost is a small tourniquet to slow the bleeding. 

In my case, a significant expense was e-commerce ‘platforms as a service’. Once I realized that I was actually going to bootstrap an e-commerce application, the next question was, with which platform? 

In 2025, the options are vast, well marketed, mostly homogenous, and, in most cases, somewhat costly. Costly is relative, but to a poor, amateur developer, a $30/mo subscription qualifies as such. 

Evaluating e-comm platforms requires peeking into a lot of corners. Setting aside subscriptions, there’s the above mentioned domain registration, hosting / storage costs. There’s also business registration fees, payment processor fees, production costs for a physical product, shipping costs, sales tax, assorted tooling / marketing, and of course, the largest cost of them all - your own time. 

Weighing each of these informs your strategy out of the gate. Most of these are mandatory liabilities, with degrees of damage. Since I was unwilling to assume the platform subscription liability, I was at a proverbial fork. 

I could go right towards the blinding technocracy mainlining AI powered slop into my humble digital homestead, or left into the shadowed back ways of the free products, through the API mangroves, on a faint path towards something resembling a complete solution.   

Bending the fork

I chose neither and instead wandered semi-aimless for a month. I spun up a Hydrogen app, attempted to hook into storefront collections, customers, etc, and tinkered until the docs led me cleverly back into the subscription honeypot…well played.

 rm -rf ./shopify-sandbox

I attempted to detach the head from WooCommerce and fuse it to my React app, but after setting a couple hours ablaze in consumer key authentication to the WooCommerce REST API, finding myself facing the horrifying Cerberus of a wp-* schema, plugin + npm package hellscape, and finally navigating the distended wp-json/wc/v3 response, I retreated and vowed (again) to never install Wordpress anywhere ever again.

There are plenty of features bundled with the average e-commerce service and the barrier to entry is little more than an internet connection, a credit card, and a dream. This accessibility is fantastic and has enabled anyone to start a store. 

But I enjoy immense suffering and learning how shit works. 

I needed something that allowed me to build the frontend UI I wanted, manage products, and eventually hook up a checkout - all without initially paying for more than the mandatory core business setup costs.

I already had a working shopping cart and a basic storefront UI, so I really just needed a product CMS and a payment gateway. 

Wrapping the wires

By this point, I had resigned that this project would just be a toy shopping cart - at best just another NPM package - but one day I bumped into the Stripe API. I was probably going to have to use this in some capacity for payments regardless of the platform, so I drifted into the docs.

Upon finding a product CMS built in, I wired up an API call to an Express server and had a look around. While not nearly as featured or fluid as a dedicated e-commerce platform, it was just scrappy and micro-service(y) enough to handle my use case — API-as-a-service (Aaas). 

I now had a product CMS that also allowed me to build a custom checkout flow from my cart, so now I just needed to wrap the red wire around the white wire…or was it blue, and supply some power.

Sh*t gets web-hooky

The Stripe API provides some fantastic opportunities to construct a custom checkout experience. Since my product catalog was here, it was fairly trivial to pass the cart items props - cartLineItems - into the checkout session. 

An added challenge emerged when I realized my Stripe products would need to be passed into my order fulfillment service. Another API wire would need to be threaded into the fray. 

To allow my now completed checkout session to be passed into my order fulfillment service, I needed a way to send the checkout data to that service. I packaged the relevant data into a payload and instantiated the POST request.

Stripe has full Webhook support to create a custom URL listener for selected API events, such as complete checkout sessions and payments. This would allow for some callback to run upon successful checkout. 

The fulfillment handler would run after a specific checkout event, such as a payment success, with the order payload being sent to the fulfillment service. There were several additional considerations and challenges involved in ensuring the order was properly received by the recipient API, however, in aggregate, this was a fully automated checkout to fulfillment workflow. 

Tyranny of one

After 4 hard months of working on this project - from de-toying the cart to deploying to production, I’m not sure that I meaningfully stuck it to any technological / corporate adversary, and really, I just architected a lot of emotional strife for myself and more than a few 12 hour days complete with AI assistant sanity checks. 

For personal / educational ends, this was a great experience. I learned a ton about carts, variants and cataloging, checkout handling, order fulfillment, transactional email, API edge cases, and e-commerce in general. Payment processing aside (don’t do this yourself), piecing together a complete digital storefront is a worthy challenge. 

If you are inclined to peek behind the curtain, It has probably never been easier to get started building with the massive range of libraries and APIs, not to mention platforms that let you offload the heavy CMS side, however, spinning up a complete store from ‘add-to-cart’ to shipping a product generates a renewed appreciation of the ‘magic’ in buying shit on the Internet. 

Its not magic, but as I reflect on the sensation of getting my first customer order in production on a site that started as a clunky React state hook and an excuse to spend a few hours coding something I’ve never done before because I didn’t want to buy someone else’s solution, I still feel a little bit of that fuzzy sorcery that ‘building your own’ conjures.

You’ve peered deep inside the machine but you stand fixed in amazement all the same.

dev