The Refinery

When I was a kid, LEGO was my world. This week, this picture popped up in my Facebook feed, from a vintage LEGO group.?? Instantly, I was back on the floor of my childhood bedroom, building my?6929 Starfleet Voyager.?Mine took MANY adventures, but eventually it was disassembled and the pieces mixed in to my big tub. ?? That's when the real fun started, building my own creations (normally more space ships).?Figuring out how to build bigger and more complex things, each with a story behind it. Those little plastic bricks weren’t just toys; they were lessons in creativity, problem-solving, and structural integrity (because nothing was worse than a ship that crumbled mid-flight). Looking back, I can see how those hours spent experimenting with LEGO shaped the way I approach building software.??You start with a blueprint, but the real magic happens when you go beyond it. When you adapt, optimize, and push boundaries to create something truly useful. Building software, like building with LEGO, isn’t just about putting pieces together. It’s about understanding how they fit, how they support each other, and how to take them apart and improve them when things change. Did LEGO play a role in shaping how you think today? Or was there another childhood obsession that still influences you?

If your dev team isn’t thinking like your CFO, you’re wasting money. Most developers are great at building things. But they should also be asking: Should we? ?? Every tech decision has a cost. Not just in dollars, but in opportunity. Too often, teams default to “What can we build?” instead of “What’s the smartest way to solve this?” I’ve seen teams spend months coding a solution that a $100/month SaaS tool, or even a well-structured spreadsheet could have handled. That’s six figures of wasted effort that should have gone into solving other business problems. ?? A strategic dev team isn’t just efficient at writing code. They challenge assumptions, evaluate ROI, and think like investors. If your team isn’t questioning tech decisions with a business lens, you’re throwing money away. How does your team approach build vs. buy decisions?

“Ditch your legacy systems!” ??? You’ve heard it before, right? But what if that advice is costing you more than you think? ?? I keep seeing articles telling manufacturers to "ditch their legacy systems!" The latest one from Code District makes the case that old systems are holding businesses back and should be replaced with modern solutions. ? I don’t buy it. Yes, some legacy systems come with challenges—technical debt, outdated interfaces, lack of vendor support. But that’s only part of the story. What these articles always miss is the massive value these systems provide. If something has been running your business for years (or decades), there’s a reason for that. It works. It’s been refined and adapted to fit your exact needs. Tearing it out isn’t just a technical decision—it’s a full-scale operational upheaval with hidden costs in retraining, workflow disruption, and unexpected failures. The article does recommend a phased approach to replacement, which is better than a rip-and-replace mindset. But I’d argue an even smarter approach: integration, not replacement. Instead of throwing away what already works, why not extend it? APIs, middleware, and smart integrations can often give you 80% of the benefit at a fraction of the risk and cost. Before you decide to scrap your legacy system, ask yourself: ?? What problem are you really trying to solve? ?? Can this be solved through integration instead of replacement? ?? What’s the true business cost (not just the software cost) of change? Legacy isn’t a bad word. The right system is the one that delivers business value, whether it’s 30 years old or built last week. What do you think? Have you seen companies waste money replacing systems when integration would have been enough??

“The data has value in itself!” Simply said in passing, this quote illustrates Mark Wallinger's depth of wisdom. Mark is right. But most companies fail to recognize just how much untapped value sits in their legacy systems. Decades of production records, inventory trends, and customer orders... this isn’t just old data. It’s a goldmine. The question is: Are you using it? A manufacturing company sitting on years of data can leverage it to: ?? Improve demand forecasting by analyzing historical patterns. ?? Reduce downtime by predicting maintenance needs. ?? Optimize inventory levels to cut costs without risking shortages. This foundational truth applies to tech startups too.?Data isn’t just exhaust from daily operations, but can be a strategic asset. ? User behavior insights can drive product decisions. ? Operational data can reveal inefficiencies before they scale. ? Industry trends can open doors to new revenue streams. The key is to stop treating data as an afterthought. Whether you’re running a factory or building a SaaS platform, a proactive data strategy can be the difference between growth and stagnation. How is your company thinking about the value of its data? Let’s talk.

Your MVP Isn’t an MVP. It’s Just Version 1.0 with a Budget Cut. An MVP isn’t a small version of your product. It’s a test. I’ve seen companies spend months on an “MVP” packed with features—only to launch and realize they solved the wrong problem. A real MVP should: ? Prove or disprove a hypothesis ? Take weeks, not months ? Focus on learning, not launching The real win comes from answering the question: ?? What is the smallest and simplest thing I could possibly build, that a customer would pay me to use? The faster you validate, the less money you waste. What’s the scrappiest MVP you’ve ever seen?

Quantum computing in supply chain technology is an exciting concept. But here’s the real question: Where’s the business impact? Right now, quantum computing sits at the bleeding edge. It's full of potential, but short on immediate, practical applications. Yet, the promise is clear: solving optimization problems at a scale classical computers can’t handle. Think route optimization, inventory balancing, or predictive demand forecasting at an unprecedented level. But let’s apply the Language of Business Impact (LoBI) here. Technology is only as valuable as the measurable outcomes it drives. Quantum computing’s impact in supply chain tech will depend on: ? Time-to-value – How soon can businesses implement and see returns? ? Cost-effectiveness – Does the solution outperform existing methods in a way that justifies the investment? ? Scalability – Is this a niche advantage for massive enterprises, or can mid-market manufacturers realistically leverage it? ? Risk reduction – Can it help predict disruptions, mitigate delays, or optimize logistics to prevent waste? Right now, the ROI equation is unbalanced. Quantum is expensive, complex, and largely experimental in supply chains. The real LoBI question is: What’s the opportunity cost of waiting versus investing early? If you’re a supply chain leader, the move today isn’t betting big on quantum. It’s staying informed, tracking progress, and identifying when the cost-benefit equation flips in your favor. What do you think? Where do you see quantum computing making the first real impact in supply chains?

Visibility solutions are everywhere in supply chain risk management. But is visibility alone enough? ?? Think of it like a flashlight in a dark maze. It shows the obstacles, but if you can't move, you're still stuck. Data is valuable. KPIs matter. But numbers alone don't change outcomes. What separates resilient companies from the rest isn’t just knowing when something goes wrong. ? Having the ability to act does. When your metrics show a delay, a shortage, or a demand spike, do you have a plan? Or are you just watching it happen? True risk reduction isn’t about playing defense. It’s about being agile enough to move when the data signals trouble ahead. ??

Yet another post about LLMs? I know. But hear me out. I get it.?AI posts are everywhere. But here’s the thing: I’m not using ChatGPT just to generate content or summarize meetings. ?? I’m using it as a diversity of thought engine. I throw ideas at it - concepts I’m refining, business strategies I’m exploring - and ask for different ways of looking at them. It’s like having a never-tiring thought partner that forces me to consider angles I might have overlooked. ?? I ask it to make ME think. The recently released Deep Research feature is already bringing me a ton of value. Sure, it digs up relevant research much faster than I could by hand. But its real power? It helps me connect dots I didn’t even realize were related. I’ll drop a couple of the more powerful Deep Research prompts I’ve been using in the comments. If you’re not using AI this way, you’re leaving serious insights on the table.

Technology evolves. People resist. That’s the paradox of modernization. Replacing legacy systems is sometimes the right answer. But we forget that while the technologists working on the new system have spent months immersed in it, the people actually using the old system day in and day out are about to experience a shock. ? ??? Humans are wired for familiarity. We try to navigate today and tomorrow with yesterday’s maps. Those maps feel safe, even when they’re out of date. Even when people ask for change, they struggle with it once it arrives. A new system is a disruption to routines, muscle memory, and workflows. People feel confident and competent - change disrupts that. This is why the deployment phase of every modernization project must be more than just DevOps. It must include a deliberate, structured plan for adoption and transition. ?? How do we help the directly impacted team work through the change? Without this, even the best technology upgrade can feel like a failure.

Vendor or Partner? The Difference Matters. Yesterday, I was part of a conversation that reinforced something I’ve believed for a long time: I don’t want to be a vendor. Our core belief at The Refinery is simple—“We don’t have clients; we have partners.” What’s the difference? ?? A vendor is given a list of deliverables and expected to execute. ?? A partner is part of the conversation where that list is created, helping to define the problem, challenge assumptions, and ensure the highest-value work gets done. That doesn’t mean vendors aren’t critical. Some needs are well-defined, and execution is all that matters. ?? Not every company needs a partner for every problem. Sometimes, the best way to be a partner is to make the introduction to just the right vendor.