A story about people, technology, and what happens when decades of legacy systems meet the demands of a modern business.
Fluid Apparel and Footwear has spent decades adapting its technology to keep pace with a changing business. Systems were extended, new applications were added, workarounds became processes, and somehow it all kept working. Project Everest is the attempt to understand what Fluid has built, what still works, what no longer does, and what needs to change—before deciding what modernization should actually look like.
By: Jonathan Ayre
Publication: September 6, 2026
Modified: September 7, 2026
Fluid Apparel and Footwear is a global retailer selling clothing and footwear for girls and boys between the ages of 12 and 24. For decades, the company grew by doing what successful retailers do. It opened stores, entered new countries, added products, found new customers and expanded into new ways of selling. Stores were followed by ecommerce. Ecommerce was joined by wholesale. Licensing extended the brand into new categories and partnerships. Marketplaces, IOS, and Android apps created another route to the customer. Each new channel created opportunity for the business, but it also created another set of requirements the technology underneath it had never been designed to handle.
Fluid's board had become increasingly concerned about the state of the company's technology. The cost of keeping everything running continued to rise, modernization efforts struggled to gain momentum, and there was no clear view of what should be replaced, what should be retained, or where to begin. Everyone knew the technology needed to change. There was far less agreement about what that change should actually look like.
So the board brought in Jonathan Ayre, an independent technology consultant, to evaluate the current state of Fluid's technology and provide a roadmap for what should come next.
On paper, the assignment seemed straightforward. Understand the existing technology estate. Identify the major risks and dependencies. Determine where modernization would have the greatest impact. Then create a practical roadmap that could take Fluid from decades of accumulated technology toward something the company could realistically operate for the future.
But before Jonathan could recommend where Fluid should go, he needed to understand where it actually was.
That turned out to be considerably harder.
There wasn't one architecture to evaluate. There were decades of them. Systems had been layered on top of systems. Countries had made their own decisions. New sales channels had been connected to technology that was never designed to support them. Business processes crossed applications, spreadsheets, integrations and manual workarounds. Some of the people who understood why things worked the way they did had left years ago.
The assignment slowly became less about evaluating technology and more about understanding the company that had grown around it.
That is where Project Everest begins.
At the center of Fluid is an on-premises ERP whose origins stretch back to the 1980s. It is no longer properly supported, significant source code is unavailable, and generations of employees have built processes around behavior that few people completely understand anymore. Everybody knows it is old. Everybody knows it eventually needs to be replaced. Yet every day it continues helping the company buy products, receive inventory, operate stores, process orders, pay suppliers and close its books. The closer anyone looks, the harder it becomes to distinguish obsolete software from decades of accumulated business knowledge.
Fluid didn't stop growing while its technology aged. Quite the opposite. When wholesale became important, the company found a way to connect it. When ecommerce arrived, it was connected to an ERP designed before ecommerce existed. When licensing expanded, processes were fitted around applications built for a different operating model. When marketplaces started producing orders, those orders were translated into formats the existing systems could understand. New warehouses, countries, carriers, payment methods, fulfillment options and customer programs were introduced in much the same way.
The business needed to move, so technology made it work.
Sometimes that meant building an integration. Sometimes someone added another field to an old system, created a scheduled job, exported a file or wrote a script. Sometimes a country purchased another application. Sometimes a manual process was introduced that was only supposed to exist until the proper solution arrived.
And sometimes someone opened Excel.
One workaround connected to another. Temporary solutions survived. People moved on. Documentation stopped reflecting reality. Local markets solved the same problems differently. The workaround that was supposed to survive six months was still running ten years later, except by then another system depended on it and nobody could remember exactly why it had been created in the first place.
Eventually many of the workarounds stopped looking like workarounds at all.
They became how Fluid worked.
To a customer, Fluid looks like one global company. Behind the scenes, it can look like several. Countries operate their own combinations of ERP, warehouse management, store, commerce, integration and reporting systems. The same product can have different identifiers depending on which system is looking at it. The same business process can work differently depending on the country performing it. Something considered a global standard at headquarters may have been interpreted, extended or quietly worked around locally years ago.
The architecture is less a single technology stack than a record of how the company grew.
Every acquisition, expansion, sales channel, deadline and business decision left something behind. A database. An interface. A batch process. An application. A spreadsheet. A rule nobody remembers creating. Individually, many of those decisions made perfect sense. The complexity came from what happened when decades of individually reasonable decisions accumulated on top of one another.
Governance didn't always keep pace with that complexity. Different teams and countries developed their own ways of making changes. Some changes were carefully tested and documented. Others depended heavily on experience and relationships. When something unexpected happened in production, discovering what changed could become considerably harder than discovering what appeared to be broken. Code might have changed. Configuration might have changed. Data might have changed. An integration partner might have changed something. A country might have changed a local process. Or the technology might not have changed at all—the environment around it may simply have started behaving differently.
Then there are the systems that aren't really systems at all.
Somewhere inside the buying department is an Excel spreadsheet created years ago by an employee who no longer works for Fluid. It contains formulas, mappings, lookups, assumptions, macros and pieces of business logic accumulated over years of use. People understand parts of it. Nobody completely understands all of it. Other processes depend on it, which means everyone agrees the company shouldn't be relying on it while simultaneously agreeing on the one thing that matters most.
Nobody wants to touch it.
That spreadsheet is more than an example of shadow IT. In many ways, it represents the wider technology estate. Between Fluid's official systems are scripts, spreadsheets, scheduled jobs, manual reconciliations, local databases, undocumented integrations and knowledge that exists almost entirely inside people's heads.
An architecture diagram can show how Fluid believes a process works.
The people doing the work often know how it actually works.
That distinction matters because all of this is happening while Fluid itself is under pressure. Sales have struggled in recent years and remain well below their historical high. The company needs to find growth again while controlling costs, supporting more sales channels and responding to customers whose expectations change considerably faster than a forty-year-old ERP.
At the same time, the cost of technology continues to increase.
Cloud was supposed to simplify technology. SaaS was supposed to simplify technology. Automation was supposed to reduce effort. Digital transformation was supposed to make the company faster. Yet every year technology becomes more capable while the cost and complexity of operating it seem to move in the opposite direction.
And then AI arrives.
Suddenly software that once required weeks or months of development can sometimes be prototyped in hours. Small teams can build things that would previously have required much larger engineering organizations. Employees who have never considered themselves software developers can describe a problem to an AI and watch it begin producing a working application.
For a company preparing to spend millions modernizing its technology, that creates an uncomfortable question.
If AI can help Fluid build software dramatically faster, why spend millions replacing legacy applications with modern SaaS platforms? Why not build exactly what the company needs? Why not vibe-code its way around forty years of technical debt?
And if the business can increasingly build applications for itself, an even more uncomfortable question begins to emerge.
Why do we need an IT department at all?
Why should merchandising wait months for technology to add a feature when someone inside merchandising might soon be able to build it themselves in an afternoon? Why should operations submit a request, wait for prioritization, move through development and testing and eventually receive something that may already be out of date? If AI allows the people closest to a problem to create their own solutions, perhaps the traditional relationship between the business and technology is about to change completely.
It's a compelling argument, particularly inside a company where people have spent decades finding ways around technology whenever technology couldn't move fast enough.
In some ways, vibe coding isn't a completely new behavior at Fluid. It might simply be the newest version of something employees have always done.
The spreadsheet, the local database, the small application, the script and the manual workaround were all created for essentially the same reason: the business had a problem and couldn't wait.
AI changes the scale at which that can happen.
A spreadsheet created inside one department is one thing. Hundreds of AI-generated applications touching products, customers, inventory, pricing, orders, payments and company data are something else entirely. Who knows what exists? Who owns it? Who tests it? Who secures it? Who monitors it? Who decides which application contains the truth? What happens when the person who created it leaves? What happens when one AI-generated application begins depending on another application that nobody outside the department even knows exists?
Perhaps AI means Fluid needs fewer people writing traditional software. Perhaps the role of the IT department changes completely. Perhaps technology decisions really should move closer to the people running the business.
Or perhaps, without realizing it, Fluid is about to recreate forty years of technical debt at AI speed.
That tension sits at the center of Project Everest.
Project Everest is Fluid's attempt to understand what it has, decide what it actually needs and determine how a global retailer built across decades can move toward a modern technology estate without destroying the things quietly holding the business together.
It isn't happening in a vacuum. The business wants technology to move faster. Finance wants greater economic discipline. Technology has to keep today's systems operating while simultaneously replacing them. Countries want to protect the processes that make their markets work. Engineering wants systems it can support. Leadership wants to know whether AI has changed the economics of transformation altogether.
And while those questions are being debated, the business doesn't stop.
Customers are still placing orders. Buyers are still selecting next season's products. Warehouses are still receiving and shipping inventory. Suppliers still need to be paid. Ecommerce still needs to work. Marketplaces still need orders fulfilled. Stores still need prices, promotions, products and employees.
Tomorrow morning, the stores still have to open.
The more we explore Project Everest, the less this becomes a story about simply replacing legacy technology.
It's a story about change.
It's about what happens when a retailer built around stores becomes a retailer selling through stores, ecommerce, wholesale, licensing, marketplaces, apps and whatever channel comes next. It's about what happens when each generation of technology is layered on top of the previous generation rather than completely replacing it. It's about the strange point where a workaround becomes a process, the process becomes institutional knowledge, and institutional knowledge becomes something the company is afraid to change.
Throughout Project Everest, we'll follow that transformation from inside the company. We'll follow an order as it moves from a customer's phone through payment, ERP, warehouse and eventually to their front door. We'll discover why two systems can disagree about the same product. We'll investigate releases that passed every test and still produced an outcome nobody wanted. We'll encounter integrations nobody remembers building, data nobody completely trusts, warehouse processes that exist nowhere in the documentation and business rules known only by the people who have spent years doing the work.
We'll also explore the decisions that follow. When does SaaS make sense? When should a company build? What does an ERP actually need to do anymore? Can multiple countries realistically operate from a single global template? What should move to the cloud? What does good engineering look like inside a retailer? How do you establish reliable data after decades of fragmentation? Can AI accelerate modernization? Should AI agents be trusted to make decisions affecting customers, inventory or company money? And perhaps most importantly, how do you modernize a company without simply creating the next generation of legacy technology?
Architecture, Technology, Engineering, Data, and AI will be the five lenses through which we examine those problems. But the technology itself isn't really the main character.
The company is and the people that work within it.
Project Everest is the story of a retailer that spent decades making technology work well enough to keep moving, until one day it looked around and realized that almost everything worked because something else was compensating for something that didn't.
Now Fluid wants to modernize.
The first challenge isn't deciding what to replace everything with.
It's understanding how the place actually works before we accidentally replace the things holding it together.