Composable Commerce: How to Have Your Lunch & Eat It Too


The Evolution to Composable Commerce

The Monolith

There was a very specific routine for how lunch was served in elementary school. At the beginning of the day – after dropping backpacks off in cubbies – students would line up in-front of a chart pinned to the wall. There were three columns on the chart indicating different types of lunch – “hot lunch”, “cold lunch”, and “brought your own”. Each column had a string of yarn running vertical, and each kid was handed a wooden clothes pin with their name written on it. After the teacher announced the headliner for each type of lunch (“pizza” or “turkey sandwich”), one-by-one we’d pin our selection to the string of yarn under our column of choice.

When lunch time rolled around, everyone stood in a single file line behind the teacher and walked to the cafeteria. If you chose hot lunch earlier in the day, you’d enter the first doorway to the left. If you chose cold lunch, you’d walk through the second door. I vividly remember walking through those doorways and seeing an assembly line of school employees behind a counter putting together lunches. Hot lunches were served on a tray – the first employee in line might toss on a pizza slice and pass it down to the next employee for a scoop of steamed mixed vegetables, who would further pass down the tray to receive baked apples, and so on. Cold lunches often consisted of two pieces of bread complimented with cold deli meat in a Ziploc bag, a package of baby carrots, and some sort of fruit. In either case, students couldn’t dictate the contents of their lunch, just the thematic choice between hot or cold after knowing the entree being served. At the end of the assembly line, the final employee would hand over a full tray or brown paper bag and watch while the student swiped their school ID as form of payment.

Exiting the lunch line back into the open cafeteria was an early introduction to negotiation and bartering. I hated carrots, so I’d always try to find those weird kids who liked the ranch dip and would trade for applesauce or yogurt. And yes, for those wondering, there was always a black market of skittles or cookies from the kids who brought their own lunch, establishing a power-rich cast system for the next 23 minutes.

Monolithic architectures are akin to my elementary school cafeteria experience, or a boxed lunch you might receive at a corporate event. Just like the selection between hot or cold lunch, a single key differentiator often drives software selection, even though a variety of features come packaged together. And similar to how the lunch tray or brown bag was only complete after being filled with food prepared by school chefs and servers, both front-end and back-end developers work together to deploy a single unit of software.


Steak-n-Shake was the late-night hangout spot when I was a teenager. Those of us with freshly-minted driver’s licenses would pack our cars way too full and roll into the parking lot around 10 PM. Even though the food was subpar, Steak-n-Shake was a hot-spot because it generically appealed to the masses – you could get a meal, dessert, or both.

After our group of fifteen or so gathered at the entrance and were directed to a few vinyl booths in the back by the hostess, a waiter would come by and write down our orders on a pad of white and green-lined paper. After going around the group, the waiter would walk back to a wall with a mid-height pass-through to the kitchen, rip off the ticket with scribbled food items, and attach it to a metal carousel to be picked up by cooks tasked with flipping burgers and mixing milkshakes.

Ten minutes later, hot plates and chilled glasses would pass back through the same opening for the waiter to pick up and deliver to our table. All interaction between kitchen and waitstaff was very structured, consisting of either commands for the cooks or prepared food to be delivered. This way of working allowed both teams to focus on their driving efficiencies through their craft, whether that was driving a positive experience through customer interaction or producing the meal customers ordered. Both teams were not only measured, but incentivized, by factors that drove success in their respective objectives; the waitstaff worked for tips, while the kitchen staff was timed on how fast they could serve up an order.

Headless architectures embody targeted focus and efficiency gains through separation of customer experience and transactional back-office activities. Similar to cooks taking action on ticketed orders from waitstaff, front-end developers make requests to back-end services using pre-defined communication contracts (referred to as APIs, or application programming interfaces). Back-end developers are responsible for taking action on requests submitted from the website, on behalf of end users. This separation of responsibility allows each team to focus on executing against their domain of expertise, while only communicating what is explicitly necessary for the other team to properly deliver. The evolution of web browsers, expansion of internet bandwidth, and modernization of Javascript frameworks have paved the way for front-end developers to build fast, immersive customer experiences, while web services and associated architectural styles (such as SOAP or REST) have enabled structured means of communication between websites and servers.


Nowadays, DoorDash is my go-to. There never seems to be enough time in the day, I have young kids with “acquired taste” I can’t get behind, and the pandemic catalyzed almost exclusive adoption of on-demand delivery for my family. Perhaps the best feature of middle-man delivery services is the flexibility; everyone in my family can get exactly what they want. At a dine-in restaurant there is a menu, often with a variety of options, but you are still held to food prepared by the same business. With DoorDash, my daughter can get her beloved mac-and-cheese from Chick-Fil-A, while my partner and I opt for a bánh mì from the local brewpub. And this isn’t just a self-concocted hack; DoorDash considers this a marketable paradigm for their business. After placing an order, I’m almost always greeted with a prompt to “DoubleDash” – or add on additional items to my order from nearby stores. Cold Stone for dessert is popular with the kids, and every once in a while I’m prone to tacking-on a six-pack of IPA from the corner liquor store.

Composable commerce is centralized around the idea of leveraging a variety of vendor-offered services to create a truly tailored ecosystem. It’s not always combining “best-of-breed” software, but instead focusing on “best-fit”. While the local authentic Italian restaurant has a pretty killer mac-and-cheese kid’s meal (made with handmade noodles!), that’s just not going to work for my two-year-old daughter who effectively swears by cheese out of a packet. Composable commerce embraces flexibility by laying a foundation for a diverse portfolio of software to be interwoven, without enforcing this concept as a hard-and-fast requirement.


If you Google “composable commerce” and you don’t have a background in technical architecture, there’s a good chance you’re going to end-up confused. Like any of the new, shiny, magic bullets we’ve seen come-and-go in the past, marketing materials and even analyst-attempted definitions are riddled with buzzwords. In the case of “composable”, similar to “headless” a few years ago, most discussions start with the technology that enabled innovative thinking – not the potential business value and outcomes that really make a difference.

We believe the lynchpin of modern composable ecosystems is the function-first thought process, not the underlying use of modern technology. In fact, we don’t believe in deterministic labeling of ecosystems to begin with; instead we envision composability as a multi-dimensional spectrum. Just like the Silk Road of the Harrison Parkway Elementary School cafeteria, we’ve been decoupling features from out-of-the-box software and setting aside basic functionality in-lieu of robust third-party integrations for decades. This sort of thinking – leveraging services not because of the technology that upholds them, but because of the value they yield for a particular business – is at the heart of composable commerce.