Tag: Network Software

The SaaSpocalypse Isn’t Coming for Print-On-Demand

Posted on by Maddy Alcala

The Doomsday Narrative

I was listening to a podcast the other day featuring the Chief Economist of Ramp. He confidently combated the narrative of the “SaaSpocalypse”—an opinion I yearned to hear.

If you’re unfamiliar with this Armageddon-y term, I’ll explain briefly. The SaaSpocalypse seems to have a pretty clear origin, going back to February 2026 when an equity trader at Jeffries described what he called “an apocalypse for software-as-a-service stocks.” Whether or not he truly invented the term isn’t my concern, but I’ve heard about this concept from many prominent venture capitalists and AI-obsessed technology leaders across various mediums over the past several months.

The idea behind the SaaSpocalypse is that software-as-a-service (SaaS) businesses will collapse now that we’re living in the era of AI. Agents will take over writing and creating applications for us, including common platforms that most businesses subscribe to like CRMs and project management tools. As a result, the world of SaaS will die a quick and painful death, sparing no one who invests or works in the space.

Forget about sales people trying to sell SaaS—they will be laughed out of the Zoom call by a prospect who gleefully screenshares to show off their swarm of agents who just replicated your product.

This doomsday narrative has grown in fervor as we’ve all sat back and watched Anthropic outpace OpenAI as the leading lab. Anthropic launched Claude Cowork in late January, followed by 11 specialized plugins for legal, financial, sales, and HR workflows. Wall Street’s reaction was swift. A journalist built a complete project management kanban board in under 10 minutes and posted a video… Monday.com’s market cap dropped $300 million before the session closed.

Yikes! This seems like a bad time to be building and running a SaaS company!

What the Data Actually Says

So, fast forward to the other day while I’m trying to self-soothe on a miserable trans-Atlantic flight by voraciously consuming podcasts. As the President and head salesperson of a SaaS business, you can imagine that I was tickled to hear the Ramp Chief Economist pronounce this doomsday SaaS-death scenario as overblown.

For those who don’t know, Ramp has a phenomenal newsletter called Leading Indicators (you should subscribe) where they share insights about the tech and finance space collected from their transactions data. They published an article in April this year showing that:

 

  • Seat-based contracts for software have stuck at 65-75% of company spend.

  • Platform SaaS subscriptions have stayed flat at 20-30% of company spend.

  • Consumption-based SaaS spend stuck at 4-6%.

 

Those percentages have barely moved in 12 months. Ramp concluded that the death of SaaS, at best, has been predicted too early.

Is AI changing our technology world? 100% yes. But are businesses changing tooling decisions at the rate that the clickbait LinkedIn influencers want us to believe? It appears not.

Why Print-on-Demand is Built Differently

Now, all of this got me thinking about print-on-demand. Will software die for POD, far before it’s ever had a chance to truly live? I don’t think so and here’s why.

The SaaSpocalypse narrative targets a particular kind of software: tools built on seat counts, designed to put a human in front of a workflow, or tools that provide business efficiency but aren’t crazy complicated to replicate. As a leader who has aggressively cut software subscriptions from a company budget this year, I buy into this part of the narrative. I’ve seen firsthand in the past 6 months how AI means we no longer have to shell out tens of thousands of dollars per year for certain tooling.

This SaaSpocalypse narrative, however, does not apply to most types of print-on-demand software, in my view, especially those focused on order management and workflow solutions. My reasoning is that POD is still really, really hard and messy without the right kind of software—and solving hard problems is what makes software sticky.

Software in the POD space is usually built to be the connective tissue between commerce channels, production facilities, shop floors, and business systems.

It often deals with messy, nonstandard product data, and it usually doesn’t replace workers or people. POD software platforms, if they’re good, replace the chaos that occurs when all of those systems don’t speak to each other. It gives humans tools to deal with the inevitable soul-crushing pain that comes with building and scaling a print-on-demand business. (Just kidding, most days it isn’t that soul-crushing).

The New Operational Reality

There’s more. For the last two decades, the SaaS space was driven by an unshakeable assumption that at the core of every software implementation, there are humans. That assumption is what’s breaking in the era of the SaaSpocalypse.

But in POD software, there are different assumptions we’re wrestling with:

 

  1. We assume that someone sells something or wants to buy something.

  2. That physical thing has to be produced somewhere.

  3. Said order has to route to that somewhere.

  4. The artwork to be printed has to match that somewhere’s specifications.

  5. Whatever exceptions exist that can prevent this from happening have to get resolved before someone notices and gets upset.

 

Throughout this whole flow, AI can make things easier. AI makes that routing smarter, but it doesn’t make it unnecessary. In fact, the more AI agents enter the procurement and fulfillment stack, the more critical the underlying software infrastructure becomes.

Agents need deterministic rails to route on. An AI agent that triggers a print order still needs a system that knows where to send it, can confirm the facility is capable, and can handle the exception when something goes wrong.

In my opinion, the SaaSpocalypse correctly identifies that software built on human headcount is in trouble and that incumbent technology companies are going to face real challengers. It’s faster, easier, and cheaper to build software than ever before. Businesses like Salesforce are going to be challenged by AI-native platforms like Attio, and we’ll see this across every sector. Technology and software leaders have to be more paranoid than ever before about new entrants popping up that can steal market share.

That said, I don’t think the SaaSpocalypse extends uniformly across all software categories. The print industry is, in several ways, the opposite of the exposed case. The operational complexity in print scales as the per-unit volume contracts and the frequency increases (aka POD). The businesses winning in this world are not reducing their software infrastructure investment—they are deepening it.

Run Your Own POD Network or Have The OrderMesh Team Run It for You

Posted on by Maddy Alcala

The Print-on-Demand Crossroads

The print-on-demand market is no longer a niche. Major brands, retailers, seller and gifting platforms, and promo distributors across nearly every geography are being asked to deliver products faster with lower (or no) MOQs and offer personalized, flexible print & merch solutions with minimal room for error. If you ask the OrderMesh team, the question is no longer whether or not you need a print-on-demand network: it’s do you want to build it yourself or have someone run it for you. 

 

When I speak to potential OrderMesh customers, this is the first question I try to help them answer. 

The Software Approach: Full Control and Custom Routing

The OrderMesh software platform is designed for businesses that want to build, run, and maintain their own POD networks. Businesses can connect directly to print vendors, build routing logic that makes sense for them, access product data to support merchandising and product expansion, and control every commercial relationship with print-on-demand partners from end to end. The OrderMesh platform handles all of the technical complexity in the middle, including SKU normalization across production locations, multi-variable order routing, order exception handling, and analytics so the team can focus on growth rather than infrastructure maintenance. For operators who want full control over their print-on-demand network, and have the sophistication to exercise it, this is the model that makes sense.

 

However, some businesses want or need something different. They know they need a sophisticated POD solution but for whatever reason, it doesn’t make sense for them to build a print network from the ground up or spend the time augmenting the production footprint or network they already have. This when the OrderMesh Fulfillment Network makes sense. This solution runs on the exact same software as the software solution described above but it’s a different service model.

The Managed Solution: Scaling Without the Overhead

The OrderMesh Fulfillment Network is a managed print-on-demand service for high-volume brands and platforms that want the POD outcome without the operational overhead. OrderMesh acts as vendor of record for your business: we design an ideal POD network to meet your business and customer needs, hold the supplier relationships (including contracting), manage the production network to achieve the right outcome for every order, own the routing and exception logic, handle customer service, and provide you with a single consolidated invoice no matter what POD product you sell. You connect to OrderMesh and send us orders. We handle the rest. The complexity of designing and orchestrating a POD supply chain lives with us.

 

The OrderMesh Fulfillment Network is not a marketplace where you browse suppliers and negotiate your own terms. It is a managed service solution: OrderMesh has already done the work to build the network, including vetting production partners, establishing commercial terms, building technical integrations, and organizing the network around clear performance expectations. When an order comes in, we route it to the right producer based on product type, geography, cost, capacity, and quality history, among other variables. And because the Fulfillment Network aggregates volume across all of its customers, the pricing leverage that comes with that scale benefits our business customers. A brand going direct to a print supplier negotiates from its own order volume. A brand operating through the Fulfillment Network transacts at a tier that reflects something much larger.

The Financial Reality and Long-Term Graduation Path

What you pay for the SaaS solution vs. the OrderMesh Fulfilment Network follows the logic of each model. Software customers pay a tech platform license and operate the network themselves. Fulfillment Network customers pay for the cost of goods and shipping, which includes the management fee for the OrderMesh team. 

 

With more than a decade of experience operating a fulfillment network, the OrderMesh team has learned that it’s often the largest brands and platforms that desire a managed POD solution because they understand the economics of headcount & technical infrastructure avoidance. For example, the OrderMesh team has serviced a platform supporting thousands of creators that needed to add a native print-on-demand merch solution to their platform. Building a POD fulfillment operation was not the business they were built to run, so they partnered with OrderMesh instead and became a Fulfillment Network customer. OrderMesh collects orders from their platform via API, routes them through the production network, and invoices the platform on a consolidated basis tied to store and customer IDs. Their customers never leave the platform or know that OrderMesh is running the POD network behind the scenes. The platform GM oversees POD revenue and COGS without a single line of additional headcount because they are backed by the OrderMesh team, from operations to customer service.

 

If this managed fulfillment path stops working for a business, there is a natural graduation path and interplay between the two OrderMesh service offerings. Fulfillment Network customers who reach the scale where they want more control, like owning vendor selection and routing decisions, can graduate to a direct OrderMesh software license without having to re-integrate into a different tech platform.

 

Knowing which model fits (and when to move between them) is what I spend a lot of time helping businesses figure out. In the posts that follow this one, I’ll go deeper on the specific situations where the Fulfillment Network is the right answer. Coming up…

 

  • Launching POD Without Building: How fast-moving platforms add print-on-demand to their products without buying equipment, hiring teammates, or touching infrastructure.
  • Grow Your Catalog, Not Your Overhead: What it actually costs to scale a print operation in-house, and the headcount and overhead you quietly accumulate along the way.
  • The Capacity Opportunity & Problem: How manufacturers with in-house production handle seasonal surges and capacity gaps without buying equipment that sits idle.
  • When to Sell Your Printers: The hidden cost of owning your own print production, and what operators who have exited manufacturing found on the other side.
  • Outsourcing to Insourcing Management of POD: When a Fulfillment Network customer outgrows managed fulfillment and is ready to own their network.

 

Stay tuned! 

The Four Types of POD Software and What Each One Actually Does

Posted on by Maddy Alcala

Many print-on-demand technology buying decisions go wrong before any vendor is ever evaluated because the buyer doesn’t have a clear picture of which software category solves which problem. As a result, they either buy the wrong tool for the job or they ask one tool to do the job of three and wonder why nothing works the way it should.

This is a quick reference guide to the four types of software you’re likely to run into if you’re evaluating tech for your POD operation. I’ll cover what each one does, what it doesn’t (or shouldn’t do), how to tell these systems apart, and example platforms in each category.

Layer 1: The Shop Floor / Workflow Management System

What it is: The software that runs production inside a facility.

A shop floor or workflow management system (sometimes called a WMS, MIS, or production management system depending on the segment) is concerned with one thing: getting physical work produced correctly and on time. It usually manages job scheduling, machine queuing, print file preparation (sometimes), operator task assignment, quality checkpoints, and production reporting. It speaks the language of the production room, including things like imposition, ganging, substrate types, color profiles, decoration methods, and press schedules.

What it knows: What machines you have, what they can produce, what’s queued up, and what’s currently running.

What it might not know: Where the order came from, what channel it was placed on, how it should be priced, or what happens after it ships.

The key distinction: A shop floor system operates inside the four walls of a production facility. Its job begins when a production job arrives and ends when that job ships. It is not responsible for deciding whether a job should come to this facility in the first place, and it usually has no native mechanism for receiving orders from external customers or routing to partner facilities.

How to recognize it in a demo: The screens show job queues, machine capacity, color calibration workflows, and operator assignments. The conversation is about throughput, turnaround, and visibility at the machine level. 

Examples: Printavo (screen printing and decorated apparel), EFI Pace (wide-format and commercial print production), Print Factory (large-format and digital print workflow and color management), Shopworks (decorated apparel and promotional products shop management), Gelato Connect (production job intake and management for Gelato’s partner print facilities), Fulfill Engine (POD and decorated product shop floor / job management).

Layer 2: The Enterprise Resource Planning System (ERP)

What it is: The system of record for your business finances and operations.

An ERP is the financial and operational backbone of the business. It manages general ledger accounting, accounts payable and receivable, inventory valuation, purchasing, fixed assets, and financial reporting. It is the source of truth for what your company owns, what it owes, what it has spent, and what it has earned.

In a production environment specifically, the ERP manages pricing, the bill of materials, and tracks raw material inventory. It is the system that knows how much blank stock is on hand in a given warehouse, what a job cost to produce, and how to record that cost in the general ledger.

What it knows: Your financials, your inventory at facility level, your supplier purchase orders, your cost of goods, your payroll.

What it doesn’t know: Which of your five production facilities should receive an inbound order from a new eCommerce customer, how to normalize product data across suppliers with different catalog formats, or how to onboard a new customer through a self-service API. When ERPs try to do order management, the result is typically slow, manual, and brittle under volume.

How to recognize it in a demo: The screens show charts of accounts, purchase orders, inventory transactions, financial statements, and maybe HR records. The conversation is about month-end close, audit trails, and compliance. 

Examples: SAP (large enterprise standard), Oracle NetSuite, Microsoft Dynamics 365, Odoo (modular open-source ERP common in mid-market operations that need financial and operational management without SAP-scale implementation overhead).

Layer 3: The Order Management System (OMS)

What it is: The coordination engine between where orders are placed and where they get fulfilled.

This is the layer that causes the most confusion, because it sits between the other systems and its job is invisible when it’s working well. An OMS receives orders from one or more commerce channels — eCommerce storefronts, marketplaces, company store platforms, B2B portals, API-connected platforms — and makes the decisions about how and where those orders get fulfilled. It applies routing logic, normalizes product data across suppliers or locations that all use different formats, manages split shipments, handles exceptions when something goes wrong, and gives everyone in the operation end-to-end visibility from order placed to order shipped. 

The OMS is the system that answers questions like: this order has three items — one we produce in-house, one our partner in Dallas can fulfill faster, and one that needs to ship from our wholesale supplier. How do we treat that as one clean customer experience while executing it across three different production sources? That problem is called mixed-channel fulfillment, and it’s one of the hardest things to do well in print and POD. The shop floor system can’t solve it because it only sees its own queue. The ERP can’t solve it easily because it wasn’t built for real-time external routing. The store platform can’t solve it because it has no production logic. The OMS is the only layer whose job this actually is.

A well-built OMS can also handle customer or sales channel onboarding for print suppliers. Modern digitally native brands expect a self-service API portal, interactive developer documentation, sandbox environments, and the ability to start sending orders without a manual integration project on either side. If your “integration” process involves back-and-forth emails and a months-long implementation, you don’t have a simple front door for your business that new customers can walk through without encountering friction. Sometimes the WMS provides this integration tooling too but OMS systems are typically much more flexible in accommodating complex customers and/or those who need multi-channel fulfillment. 

What it knows: Every order from every channel, which vendor or facility is fulfilling each item, where each order is in the fulfillment lifecycle, and when something goes wrong.

What it doesn’t know: How to run your machines, what your general ledger looks like, or how to display your product catalog to a customer.

The key distinction: The OMS sits above the shop floor and next to the ERP. It doesn’t replace either one. It is the decision layer that determines where work goes before the shop floor receives it and before the ERP records it. If you remove it, someone is probably making those routing and exception decisions manually or this logic is hard-coded into your eCommerce backend or WMS. 

How to recognize it in a demo: The screens show order dashboards across multiple sources, routing rule configuration, vendor network management, exception queues, and API documentation. The conversation is about integration speed, routing logic, and what happens when a vendor fails a job. If someone is walking you through how to configure a routing rule, you’re in this layer.

Examples (traditional retail/enterprise): Manhattan Associates OMS, IBM Sterling Order Management, Salesforce Order Management. Examples (print and POD-specific): OrderMesh.

Layer 4: The Store, eCommerce Platform, and/or Front End

What it is: The tech the customer sees and interacts with.

This is where transactions happen and this tech includes the storefronts, the product configurators, the checkout experience, the customer account portal, the design tool, and the marketplace listing. This layer is responsible for the buying experience, the presentation of your product catalog, the pricing the customer sees, and the payment transaction. It is the revenue surface of your business.

A well-built front end is optimized for one thing: converting a visitor into a buyer and making that experience fast, clear, and trustworthy. It should not be carrying production routing logic, vendor selection rules, or fulfillment orchestration. When store platforms are asked to do those things, they become slow and brittle, and they break when order complexity increases or a new production source is added.

Design and editor tools like Fast Editor also live at this layer or immediately adjacent to it. They sit between the customer experience and the order handoff to the orchestration layer. Getting the hand-off from design tool to production file clean and automated, without a manual step in the middle, is one of the most operationally impactful integrations a print business can make.

What it knows: What your customer wants to buy, what they’re willing to pay, and what they experienced during the transaction. The store platform’s job ends at the order. Everything that happens after the “place order” button is pressed belongs to the OMS and the production layer. 

How to recognize it in a demo: The screens show storefronts, product pages, checkout flows, and customer account dashboards. The conversation is about conversion rate, page speed, and customer experience. If the pitch involves themes, templates, or abandoned cart recovery, you’re in this layer.

Examples: Shopify (dominant in DTC eCommerce), WooCommerce (WordPress-native, open source), Magento / Adobe Commerce (complex B2B and enterprise commerce), BigCommerce, Salesforce Commerce Cloud. At the marketplace and social commerce level: Amazon, Etsy, TikTok Shop. In company stores and promo: Brikl, Order My Gear / Brightstores, Chipply.

Every System Is the Source of Truth for Something.

The cleanest way to draw boundaries between these four layers is to ask a simple question about each one: what is this system the authoritative record for? When there’s a dispute, a question, or an audit, where does the definitive answer live?

The ERP is the system of record for your business finances. What did this job cost to produce? What does this vendor invoice say? What is the inventory valuation at this facility? What did the company earn last quarter? The ERP owns those answers. 

The shop floor system is the system of record for what happened inside production. Was this job produced? When did it complete? Which operator ran it? Did it pass quality control? What machine was it run on? The shop floor system owns that history. No other layer has visibility into the production execution record the way the shop floor tool does.

The store platform is the system of record for the customer transaction. What did the customer order? What price did they pay? What did they see in the checkout? What is their account history? The storefront owns the commercial relationship with the buyer and the record of every interaction within it.

The OMS is the system of record for the order across its entire lifecycle, from the moment it enters the network to the moment it’s fulfilled. Which vendor was it routed to and why? When did it change status? What happened when it failed and how was it resolved? How many orders moved through the network this week, from which channels, to which production sources? No other system in the stack has that end-to-end view, because no other system sits in the middle of all the others.

This is also where most stacks break down. The shop floor system knows what was produced but not where the order came from. The ERP knows what it cost but not which channel originated it. The store platform knows what was ordered but not whether it was fulfilled correctly. Without an OMS connecting and tracking across all of them, the end-to-end order record lives in nobody’s system, which means it lives in a spreadsheet, an inbox, or someone’s memory.

Why the Most Competitive Businesses in Print-On-Demand Are Building Networks, Not Facilities

Posted on by Maddy Alcala

There is a seductive logic to owning your own production. You control quality and capacity. You control the customer relationship from the moment an order arrives to the moment it lands on a doorstep. For most of the history of the print and decorated products industry, that logic was sufficient but it is becoming less so.

Not because ownership is the wrong instinct, but because the economics of getting a product from a facility to a customer have shifted in ways that a single production location, no matter how well-run, was not designed to absorb. Shipping costs are rising and consumer expectations around delivery speed have tightened considerably. Product breadth demands are expanding and geographic reach has become a competitive variable rather than a fixed constraint. The businesses responding most effectively to these shifts are not the ones that built a better facility. They are the ones that built a network.

A Tax on Distance

For most ecommerce businesses, shipping runs between 10 and 15 percent of total order value or more. In categories like decorated apparel and promotional products, where margins are already under pressure and average order values are not enormous, that is a meaningful slice of every transaction. And it has been growing. Shipping costs in the United States have risen more than 40 percent over the past five years, with UPS and FedEx both raising rates by roughly 5.9 percent in 2024. The postal service followed in 2025. 

What is often discussed less is that shipping cost is not purely a function of weight or carrier selection. It is heavily a function of distance, specifically the number of shipping zones a package crosses between the facility where it was made and the address where it is going. A decorated t-shirt shipping from a single facility on the West Coast of the US to a customer in Boston may cross four, five, or six zones. Move the production closer to the customer and the same package might cross one or two. That zone compression, which sounds like a logistics detail, can reduce per-shipment cost by 30 to 50 percent on a given order.

That is not a theoretical efficiency. It is money that currently leaves the business on every package.

The consumer side of the equation adds another layer of pressure. Fifty-eight percent of global shoppers cite high delivery costs as their primary source of frustration when shopping online. Nearly half of all online shopping carts are abandoned because of unexpected fees added at checkout. Sixty-three percent of consumers say they will take their future business elsewhere if a first delivery takes longer than two days. These figures come from ecommerce research, but they describe the customers of your customers. That pressure does not stop at the storefront. It travels up the supply chain and eventually arrives at the production decision.

The Lesson from Logistics at Scale

The most rigorous real-world test of the proximity principle did not happen in the print industry. It happened at Amazon.

By 2021, Amazon’s fulfillment network had grown so large and so quickly that its own scale had become an operational liability. Orders were being shipped from wherever capacity existed rather than wherever it made geographic sense. Costs were rising and delivery times were not improving despite continued infrastructure investment. The company committed to a significant restructuring built around a single organizing idea: divide the country into eight largely self-sufficient regions, stock each region with enough inventory and capacity to serve customers within it, and route the overwhelming majority of orders to the production or fulfillment node closest to the destination.

The outcome was that 76 percent of Amazon’s order volume shifted to being fulfilled from within the customer’s own region. Delivery times fell. Transportation costs fell. Amazon has since continued refining the model, working toward even smaller, more localized regions, because the data keeps confirming the same thing: proximity to the customer is not a convenience. It is an economic advantage that compounds.

Amazon has applied this logic to print directly, opening a print-on-demand facility in Florida specifically to produce books locally and support faster, cheaper fulfillment for customers in the region. 

The print industry did not invent this problem, and it does not need to invent the solution. The solution is already well-documented. What it requires is the willingness to organize production around a network model rather than a single-source model, and the infrastructure to route orders across that network intelligently.

If You Own the Equipment

For businesses that own production capacity, the case for a network mindset tends to arrive in one of three forms, usually in this order: a peak season that overwhelms the facility, a customer that asks for a product category outside the core, or a new client in a geography that the current location cannot serve economically.

Each of these is a version of the same underlying problem. A single facility is optimized for a specific set of conditions: a particular product mix, a particular production volume, a particular geographic footprint. Outside of those conditions, it has limited flexibility. It cannot add capacity without capital. It cannot add capability without equipment and expertise. It cannot add geographic reach without a second location.

A network extends all three without requiring any of it.

Overflow capacity is the most immediate application. When a facility is running at capacity and a new program arrives, the business faces a binary choice: accommodate it or decline it. A production business with established network relationships has a third option. It routes the overflow to a trusted partner, retains the customer relationship, collects the margin, and does not turn away revenue. This is not an exotic arrangement. It is how the most sophisticated operators in the market have managed demand variability for years.

Product expansion is the second application. The market is converging. Commercial print, apparel decoration, promotional products, hard goods, and branded packaging are increasingly being purchased by the same buyers through the same channels. A brand that works with a production partner for decorated apparel increasingly wants that same partner to handle the hard goods component of a campaign or the kitting. A production business that can only say yes to a portion of that request is a production business that is gradually being designed out of larger programs. Filling the gap through a network partner is often faster, less capital-intensive, and lower-risk than building the capability internally, and it lets a business test category demand before committing to the investment.

Geographic reach is the third. A single facility serves the geography around it efficiently and the rest of the country at an increasing cost disadvantage. As customers grow and their own footprints expand, the production partner that can meet them across regions becomes structurally more valuable than the one that cannot. A network makes that coverage available without opening a second facility.

If You Don't Own the Equipment

For businesses that source production rather than own it, the argument is even more direct.

A single production partner is a single point of failure. Equipment goes down. Capacity fills. Quality inconsistencies emerge. Pricing changes. When any of these things happen and there is no routing alternative, the exposure is total. The customer relationship absorbs the disruption regardless of where the fault originated.

But the risk argument, while real, is less compelling than the opportunity argument. The more important reason to build a distributed production footprint is not what it protects against. It is what it makes possible.

Geographic coverage means that orders are fulfilled closer to the customers receiving them. The shipping cost savings either improve margin or get passed along as a pricing and speed advantage, which in a market where 88 percent of consumers say free shipping matters more to them than fast delivery, is a meaningful lever. Capability breadth means a more complete program offering without being constrained by what a single vendor can produce. Capacity resilience means that demand growth, seasonal spikes, and successful program launches do not immediately become fulfillment problems.

The platforms and programs that have built this kind of distributed footprint deliberately operate with a fundamentally different posture than those still organized around a single production relationship. They are not immune to disruption. They are structured to absorb it, route around it, and keep the customer experience intact regardless.

The Infrastructure Behind the Network

None of this is self-executing. A network of production partners without intelligent routing is not a network. It is a vendor list with a manual decision-making process sitting in the middle of it.

What Amazon’s regionalization story is really about, beneath the fulfillment center geography and the supply chain research, is a software and data problem. The physical facilities existed. What changed was the logic governing which facility fulfilled which order, optimized in real time across proximity, available capacity, product capability, and cost. The network became more valuable not because Amazon added more buildings, but because it got better at routing across the ones it had.

The same dynamic applies in print. A production network is only as strong as its ability to move the right order to the right node at the right moment. That requires catalog normalization across vendors, routing logic that accounts for capability and geography, exception handling when a primary route is unavailable, and visibility across the entire order flow. Without that infrastructure, every new partner added to the network adds operational complexity rather than operational leverage.

This is the gap that most operators are still working in. And it is the gap that separates businesses that can genuinely scale a distributed production model from those that are simply managing a more complicated version of the same manual process.

The single-source model served the industry well for a long time. It offered simplicity, control, and predictability. What it cannot offer, in the current environment, is the geographic flexibility, the capacity resilience, and the cost efficiency that a distributed network provides when it is built and operated correctly.

The shift is not about abandoning what has worked. It is about recognizing what the next phase of this market requires, and building the infrastructure to compete in it.

Two Industries Sitting on Exactly What the Other Needs

Posted on by Maddy Alcala

I attended Kornit Konnections this week and spent most of my time listening to retailers describe their own problems, mostly disconnected systems and planning calendars that had quietly become constraints rather than tools. But the elephant in the room was the problem that retail has been trying to solve for 20+ years: inventory. 

There is a particular kind of organizational pain that comes from knowing exactly what is wrong and being structurally unable to fix it. Retail has been living with that pain around inventory for a generation.

On the balance sheet, finished goods inventory looks like an asset. To a lender, it is collateral. Banks typically advance between 50 and 80 percent of appraised inventory value against it. Public markets treat inventory turns as a signal of operational health. Entire finance functions have been built to optimize these numbers, and for a long time the model held together well enough. The cracks in that model are widening. 

In 2023, the fashion industry produced somewhere between 2.5 and 5 billion unsold garments, representing an estimated $70 to $140 billion in retail value sitting in warehouses, on markdown racks, or written off entirely. Nike reported in 2024 that markdowns affected 44 percent of its assortment, more than double the figure from two years prior. The cost of holding unsold inventory typically runs 20 to 30 percent of product value per year so a garment worth $100 costs $25 to carry for twelve months. Across millions of units, the math becomes unforgiving.

The root cause of this is structural. Most retail planning still operates on a 12 to 18 month calendar, with buyers committing to finished goods nearly a year before a consumer ever sees them. The strategy can work brilliantly for brands that correctly predict what consumers will want six or nine months out. But for every brand riding high on the right bet, there is another working through an inventory overhang it cannot move. This planning and purchasing calendar is not just a process. It runs through organizational structure, vendor contracts, financing covenants, and incentive systems built around certainty that the market rarely provides, especially now. 

Retail has been talking about fixing this problem for two decades and largely has not because of the complex change management problem embedded in how retail companies are built, capitalized, and led.

I listened to a panelist at Kornit Konnections talk about a solution. He spoke about how the longest lead time in any apparel value chain is the raw material component. The more finished a product is when you take a position on it, the worse your flexibility when demand shifts. The brands that win the flexibility game are the ones that take positions on the raw materials underlying the majority of their volume and hold inventory in its most configurable, unfinished state for as long as possible. Imagine a roll of fabric before it is printed, dyed, or decorated. This approach preserves optionality. 

While I was listening to this panelist talk, I thought of the dozens of print-on-demand facility tours I’ve done over the years. POD operators have understood this plan instinctively for years. 

What POD has gotten right by necessity

Print-on-demand businesses were not built around a planning calendar because they could not afford to be. With no MOQs or bulk buys, why or how could you hold onto warehouses of finished goods, all wagered on demand that has not yet materialized. The entire POD model was constructed around a single structural insight: produce only what is ordered, when it is ordered, and hold raw material in its most configurable state until the last responsible moment.

Companies like Kornit Digital have built their entire operating thesis on this principle, making the case that businesses should not hold inventory they have not yet sold. The economics are not complicated. The capital efficiency is real. The inventory risk is structurally neutralized rather than managed after the fact.

This is what retail needs to borrow. Not just the philosophy, but the operating model behind it. The two-week product drop, executed through a small nimble team or through vendors taking product to market directly on a brand’s behalf, is not a fantasy. It is already happening with brands who have punched through the change management challenge. The brands not doing it are mostly waiting for their planning process to approve something the market already validated.

What POD has not figured out yet

As I was listening to these same retailers talk, I also ruminated on what I think is a harder truth that tends to get less airtime at POD-centered industry events.

The flexibility that makes print-on-demand structurally superior is also the thing that keeps most POD businesses from becoming “real” brands. When you never fully commit to a product, you never fully commit to a point of view, which is what brands are built on. The blank t-shirt that can become anything is, in a meaningful sense, nothing in particular until a decision is made about what it should be. I think back to a conversation I had with the COO of one of the original POD-native marketplaces — she told me her organization was moving away from POD as a supply chain strategy because the products weren’t unique enough and she couldn’t hold onto her customers’ loyalty. Her brand had lost its point of view by relying 100% on a POD model. 

Retail, for all its dysfunction, has produced enormously wealthy companies and operators because the model generates real brand equity, real consumer loyalty, and real pricing power. That value compounds over decades. POD has largely produced high-volume, low-margin fulfillment infrastructure that struggles to hold pricing because differentiation is thin and switching costs are low. The moment a POD operator or brand starts spending like a retailer, without the brand equity to support it, the economics unravel. The capital efficiency that makes the model attractive disappears the instant traditional retail cost structures get layered on top of unit economics that were never designed to carry them.

The financial disparity between the two industries tells this story precisely. The global retail technology solutions market reached $234.5 billion in 2023. In a single quarter of that same year, retail tech financing deals alone totaled $4.7 billion. More than 18,000 venture capital investors are active in the space. Against that backdrop, the entire print-on-demand software market is estimated at $4.5 billion in total market size in 2025. Not invested capital. Market size. The POD largest fundraising round into pure software ($260mm into Gelato) is the major VC financing deal of this decade, and that is no discredit to Printify who raised material capital around the same time. 

This comparison is not a criticism of POD software but rather a precise measurement of how differently capital has flowed into these two industries, and how much of the capability gap between them traces directly back to that difference.

That capital built something specific in retail and did not just fund talented people. That money has built the data infrastructure, the demand forecasting systems, and the organizational muscle required to move from operator-driven decisions to systems-driven flows. The Harvard MBA founders and McKinsey-trained data scientists who entered retail over the past two decades tell another story of this funding, technology, and talent gap. The destination retail is sprinting toward, thanks to the large amount of money that has flowed into that world, is a business where systems handle the routine decisions, humans make the judgment calls, and the gap between sensing demand and responding to it collapses toward zero. POD is, by and large, still at the beginning of that journey.

The shift that changes everything

The transition from operator-driven decisions to systems-driven flows is the defining operational shift of this decade, and it is arriving in both industries simultaneously, though from very different starting points.

Retail built toward this transition over decades of capital investment and institutional development. The infrastructure exists. The discipline exists. What retail is now discovering is that the systems it built to optimize a calendar-planning model are capable of something far more dynamic, if the organizational will is there to let them evolve.

POD is approaching the same transition from the opposite direction. Less infrastructure. Less institutional data. Less financial backing. But a model that is already structurally aligned with on-demand, unit-level economics. 

AI and autonomous workflows are an accelerant for both industries, if used correctly. AI can be a great equalizer for the POD market if we leapfrog ahead in how we build software, analyze data, and solve complex data and systems integrations. AI can help us close the distance between the instinct-driven POD operator and the analytically rigorous retail planner. The data sophistication that retail spent decades and billions building is becoming accessible in compressed time and at a fraction of the historical cost. The POD business who makes routing decisions, pricing adjustments, and replenishment calls by feel will be competing against systems that make those same decisions in milliseconds, with full visibility across every variable. That is not a threat to dismiss. It is an invitation to build.

The most important variable is still the people

I think that the POD and retail industries are missing deliberate cross-pollination of talent. The POD industry needs more operators who have run sophisticated retail planning functions and supply chains, who have sat inside organizations where Harvard MBA founders set the strategic direction and McKinsey-trained data science teams built the analytical infrastructure beneath it. People who understand what it means to manage inventory at scale, build a brand that commands pricing power, and run a business with the financial discipline the next stage of growth actually requires. Retail needs people who have built nimble, inventory-light operations from the ground up, who understand configurable supply chains, unit-level economics, and what it actually means to take a product to market in two weeks without a planning committee signing off on it.

Right now, those two talent pools barely intersect. That is one of the most consequential gaps in either industry and one of the least discussed, in my view. The conversations happening inside POD companies and inside retail organizations are almost entirely separate. The insights being generated on one side are not reaching the other.

That is the conversation worth having and Kornit Konnections made huge strides this week in starting it. I applaud Kornit for a fantastic show that recognized how much retail and print-on-demand have to offer each other. These industries have more to offer each other than either has been willing to admit, and the window to act on it, before systems make the capability gap irreversible, is open right now.

Don’t Buy Software, Make an Infrastructure Decision

Posted on by Maddy Alcala

Why the tech you use right now will determine your competitive position for the next decade: what to look for in a platform built for what comes next.

There is a question that every CEO in the print and promotional products supply chain is eventually going to face. Most of them are already facing it, whether or not they have named it as such.

The question is not which software platform has the best feature set today. The question is which technology architecture will still be serving your business effectively in three years, in an environment that is changing faster than any roadmap can predict.

The Environment Your Next Software Decision Will Actually Operate In

The scale of investment flowing into AI and software infrastructure right now is unlike anything the technology industry has experienced before. Microsoft, Google, Amazon, and Meta are collectively deploying hundreds of billions of dollars annually into AI infrastructure, foundation models, and developer tooling. A generation of well-funded AI labs is compressing years of software development capability into months. The pace of change is not a temporary spike and by every credible measure, it is accelerating.

For a CEO in the print or promotional products supply chain, this matters in a specific and practical way: the software platform you select in the next twelve months will be operating in this environment for the next five to seven years. The question is not whether that platform handles your current workflows. It is whether its underlying architecture can absorb what the market demands next without requiring you to rebuild from scratch when the next capability shift arrives.

That shift is not hypothetical. It is already visible. AI agents that browse, select, and fulfill on behalf of buyers are moving from research projects to production deployments. 

Hyper-personalized content, generated at the individual recipient level, is becoming the input that feeds print production at scale. Sales channels are multiplying faster than integration teams can keep pace with. Production networks are becoming more distributed, more global, and more capability-diverse with every quarter.

The technology decisions being made right now are not decisions about features. They are decisions about architecture. And architecture decisions compound — in both directions.

The businesses that built on open, API-first, cloud-native infrastructure during the shift to SaaS a decade ago compounded their advantage with every year that passed. The ones that stayed on legacy systems spent the next decade paying to migrate. The same dynamic is playing out now, faster, with AI as the forcing function.

Anyone Can Write Code Now. That Is Not the Same as Building Infrastructure.

One of the most significant developments in the technology landscape over the last two years is the emergence of AI-assisted coding tools that have dramatically lowered the barrier to writing functional software. A single developer, or in some cases a non-developer, can now produce working code at a pace that would have been impossible three years ago. The industry calls this vibe coding: rapid, AI-assisted software development that produces functional outputs quickly, often without deep architectural planning.

This is genuinely useful for prototypes, internal tools, and simple automations. It is not a substitute for production-grade engineering infrastructure. And this distinction matters enormously for any CEO evaluating platforms to run mission-critical order management, fulfillment routing, and supplier connectivity.

The gap between vibe-coded software and production-grade infrastructure is not visible in a demo. It shows up months or years later, in specific, costly ways that are difficult to reverse.

Security is the most immediate risk. Production systems handling order data, customer records, and supplier integrations are targets. SOC 2 compliance is not a certification that can be acquired after the fact; it is a continuous engineering discipline that requires dedicated security investment, regular audits, penetration testing, and documented controls. Most rapidly-built systems do not have it. The exposure is real and the liability compounds with every enterprise customer you add.

Scalability is the second failure mode. Software that works cleanly in a demo environment and software that processes hundreds of orders per second under sustained production load are different engineering problems. Auto-scaling infrastructure, event-driven architecture, and self-healing systems require deliberate architectural decisions that cannot be retrofitted. They have to be built in from the start or you rebuild when volume exposes the gaps.

The third failure mode is the one most CEOs do not see coming until it is expensive: API fragility. Every supplier, every sales channel, and every business system that connects to your order management platform depends on stable, versioned APIs with documented change management. A platform without disciplined versioning forces every integration partner to absorb the cost of breaking changes. That cost multiplies with every new connection added to the network. And in the print and promotional products supply chain, the network is the business.

The moat is not the ability to build software. Anyone can do that now. The moat is the ability to build software that is secure, scalable, and architected to evolve without constant rebuilding.

The Giants Are Setting the Bar

The technology arms race is not abstract. It is playing out in the specific platforms and capabilities that the largest players in adjacent markets are deploying right now and those deployments are setting the technical expectation floor for every supplier and operator in their orbit.

Shopify has invested heavily in making its platform the default commerce layer for businesses that sell physical products online. Its developer ecosystem, its APIs, and its logistics network are all moving toward deeper integration with on-demand production. Any order management platform that cannot integrate cleanly and reliably with Shopify and with the commerce platforms that follow is already behind.

Amazon continues to raise the bar on what sellers and fulfillment partners are expected to deliver: speed, real-time visibility, automated exception handling, and zero tolerance for manual intervention in high-volume workflows. Those expectations do not stay inside Amazon’s ecosystem. They migrate across every sales channel your customers use.

 

Canva’s expansion into print is the most instructive example for anyone in this space. Canva built an API layer connected to production networks and made the entire backend invisible to their users. Every print business that wants to work with the next platform like Canva needs to be technically capable of connecting on demand, at scale, with no manual work required on either side.

In promotional products specifically, distributors on modern software are going to route work to suppliers who can receive and process orders programmatically. The ones who cannot will find themselves progressively excluded from the programs that matter most.

The competitive dynamic here is asymmetric. Platforms and brands building modern, API-first infrastructure get more capable with every integration they add. The businesses running on legacy systems fall further behind with every integration they cannot make. The gap compounds. It does not close on its own.

What to Look For in a Platform Built for What Comes Next

The specific features a platform offers today are less important than the architectural decisions underneath them. Here is what to evaluate when selecting technology infrastructure for an environment that will look fundamentally different in 24 months.

API-first with documented versioning. Every capability available through the user interface should be available through the API. Versioning should be explicit, with documented deprecation timelines and advance notice. This is the architectural prerequisite for any future integration — with AI tools, with new channels, with new production partners — to be built reliably and maintained without constant renegotiation.

AI-native integration capability. The Model Context Protocol is becoming the standard interface through which AI agents interact with software systems. A platform with a documented MCP server is already built for AI-native operation. A platform without one will require architectural work to support the AI integrations that are coming and they are coming faster than most roadmaps anticipate.

Event-driven architecture. Systems that push events rather than requiring polling are fundamentally better positioned for AI integration, real-time operational visibility, and automated exception handling. Event-driven architecture also provides resilience during outages: events queue rather than drop, and the system recovers to a consistent state without manual intervention.

Open integration framework. A platform that connects to any ERP, any commerce platform, any editor tool, and any production management system through documented APIs is a platform that can grow with the ecosystem. A platform that requires custom development for every new connection creates technical debt with every integration added.

Security as architecture, not certification. SOC 2 compliance is not a document that can be acquired after a system is built. It is an engineering discipline that must be designed in from the beginning. Ask any vendor you are evaluating to walk you through their security controls, their audit cadence, and their data isolation architecture. If they cannot answer fluently, you are looking at a system that was not built with security as a design constraint.

Ask any software vendor you are evaluating: what does your architecture look like when AI agents are placing orders, when a new sales channel launches overnight, and when your production network doubles in 90 days? The answer will tell you everything about whether that platform was built for today or for what comes next.

Why This Is the Moment to Decide

There is a specific window of competitive opportunity that opens during periods of rapid technology change. The businesses that make the right infrastructure decisions before the market fully absorbs what is happening compound their advantage with every passing month. The ones that wait discover that the gap they were avoiding closed and a larger one opened in its place.

That window is open right now in the print and promotional products supply chain. The structural shift toward on-demand production is accelerating. The technology environment is changing faster than any individual business can track. The competitive consolidation that reshaped the industry in 2024 and 2025 is not finished — the next wave will reward the businesses with the infrastructure to operate across category lines and at the technical sophistication level that modern buyers and channels require.

The businesses making the right technology decisions now are not solving a software problem. They are building a network, including a connected system of production partners, sales channels, and operational workflows that becomes more valuable and more defensible with every integration added. The software is the foundation. The network is the competitive moat.

OrderMesh was built for exactly this environment. The platform is API-first, SOC 2 compliant, event-driven, and MCP-enabled. It was built by a team that has been using AI in its own development cycle for over two years. It is backed by Taylor Corporation, one of the largest commercial print operators in the world, which evaluated the entire market, chose OrderMesh to solve its own digital transformation, and then acquired the company to power its future. That sequence is not a footnote. It is the proof that this platform was built for serious operations at serious scale.

Is your current infrastructure built for what comes next?

We put together 10 questions every business should ask their print order management provider. If your vendor cannot answer them, you are likely carrying technical debt that will become a competitive liability before you expect it. You can find the 10 questions below.