When to build vs buy software for SAP workflows

I’m putting an end to the build vs. buy debate once and for all. Every legal leader has been in this meeting. Someone from engineering says we can build this CLM replica in a quarter. Someone from finance says the vendor wants $200K annually. And you’re stuck in the middle trying to figure out which mistake is less expensive. Can you build it? Of course you can. Your engineers are smart. They’ve built way harder things than a contract workflow tool. But what happens after you build it? Month 1-3: Engineering ships v1. It works. Everyone’s excited. Month 4-6: Users want changes. Engineering is now on other priorities. Tickets pile up. Month 7-12: The tool breaks when you upgrade your CRM or when you want to scale from 100 to 1000 contracts. Month 13+: You’re maintaining legacy code for a problem vendors solved three years ago. Meanwhile, you’ve spent zero time on the stuff that actually matters, like figuring out why Sales takes 47 days to close deals, or why your renewal process is held together by spreadsheets. So let’s make it simple. Build if: ↳The capability is core to your competitive advantage ↳You need it to work exactly one specific way ↳You have dedicated engineering resources with no other priorities ↳You’re prepared to maintain it for the next five years Buy if: ↳The problem is common across your industry ↳The vendor has solved edge cases you haven’t thought of yet ↳Your engineering team should be building product, not internal tools ↳You value your legal ops team’s sanity Most of the time, the answer is buy because your lawyers didn’t go to law school to become product managers for homegrown software. Honest question - where are you drawing the line?

Building software in-house costs logistics companies $4M annually on average. 35% of warehouses still choose it over buying proven solutions. After analyzing 100+ warehouses, here's what 3PLs need to know about building vs buying in 2025. Building requires full development teams, constant maintenance, and endless updates. A $4B logistics company we work with spent $10M on their custom OMS. Modern solutions will deliver the same capabilities for one-fifth that amount over three years. Companies spend 15% of their annual budget just to keep old systems running. One warehouse executive told me last week they had an entire team dedicated to fixing their custom platform daily. That's millions in payroll solving problems that shouldn't exist. A $400M retail brand we serve eliminated manual processes and found hundreds of thousands in missing inventory after switching to Pipe17. Their implementation took six weeks. An enterprise 3PL client cut tech costs by 70% after replacing their custom system. More importantly, they onboarded new customers in days instead of months. Their sales team now closes deals faster because they can say yes to any integration request. Getting modern software running in your warehouse isn't rocket science. We sit down, understand how you operate, connect everything you already use, and get your team comfortable with the new tools. No army of developers needed. Most of our warehouse partners are up and running in six weeks, handling orders while their competitors are still writing code. 87% of logistics companies are spending more on technology this year. They’ve figured that very dollar and hour spent building software from scratch is a dollar and hour taken away from running an excellent operation. The market demands speed and flexibility. Modern commerce needs warehouses that adapt fast. That happens through proven technology, not custom development that takes years to match basic market capabilities. Your customers don't care about your amazing homegrown software. They care about getting their products to the right place, on time, every time. Focus on that. Let technology partners handle the rest.

“There are only three options,” they say. 𝗕𝘂𝗶𝗹𝗱. 𝗕𝘂𝘆. 𝗜𝗴𝗻𝗼𝗿𝗲. It sounds clean. Confident. Like the kind of choice an executive makes before lunch. Like you’re choosing between chicken and fish at a wedding. Reality?… The 𝗕𝘂𝗶𝗹𝗱 team is reverse-engineering ChatGPT plugins and calling it “differentiated IP.” The 𝗕𝘂𝘆 team is on its fourth vendor in six months because none of them “fully understood our needs.” The 𝗜𝗴𝗻𝗼𝗿𝗲 camp? Quietly running an AI pilot under a different budget line so they don’t have to explain it to finance. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗶𝘀𝗻’𝘁 𝗔𝗜. It’s pretending this decision is clean. 𝗕𝘂𝗶𝗹𝗱 sounds bold. Strategic. A castle you control. Until you realize castles need architects, guards, and moat maintenance. And you’ve got a few interns and a Kaggle-winning prototype. 𝗕𝘂𝘆 sounds fast. Until your shiny new tool updates itself into a compliance nightmare. Or sunsets the feature your workflow depended on. 𝗜𝗴𝗻𝗼𝗿𝗲? It’s a story you tell yourself. Until a competitor launches something half as good but ten times louder—and now the board wants answers. Most companies don’t decide. They drift into what’s easiest to explain. Here’s the truth no one markets: It’s not “Build vs Buy.” It’s: What are you willing to own, break, adapt—or bet on? It’s messier than a matrix. Riskier than a pilot. Too important to leave to instinct. So here’s a Playbook — not a framework, not a template, just how to think clearly in a murky world: 1️⃣ Know what you want. Define it in one sentence. No metaphors. Will it make money? Can you exit? Would customers care if it vanished? 2️⃣ Audit your real capability. Do you truly have ML talent, data, ops maturity, leadership support—or just "interest"? 3️⃣ Build = 5-year marriage. If you’re not budgeting for support, legal, updates, and team retention, don’t swipe right. 4️⃣ Buy = one-night stand with shared bank accounts. Can you live with their roadmap? Get your data back? Exit without wreckage? 5️⃣ Ignore—but on purpose. Write it down. Share it. Set a 6-month trigger to revisit. Silence is not a strategy. 6️⃣ Hybrid is negotiation, not strategy. Buy what you’re not great at. Build what you can’t afford to get wrong. 7️⃣ Run a 'What if we’re wrong?' simulation. Early, late, wrong partner—can you absorb it? 8️⃣ Measure what matters. Shipping ≠ success. If no one uses it, you built something impressive—but ineffective. 9️⃣ Governance is not optional. Assume models will lie. Assume people will believe them. Bake in review. Audit. Fallbacks. Or bake in headlines. There’s no perfect choice. Just trade-offs you understand—or trade-offs that blindside you. AI strategy isn’t about tech. It’s about how brave you are in facing what you can’t control— And how grown-up you are in owning what you can. ✅ Which of these steps do you think most companies ignore—and regret? #AI #Leadership #DigitalStrategy ♻️ Repost ➕ Follow 👉 https://2ly.link/22zte

Every PMM team is racing to build internal AI workflows. But a question almost no one is asking is: What should you not build, but BUY instead? AI has made internal tooling feel easy (and I love it), but not every workflow should be automated, rebuilt, or “AI-ified” in-house. Some categories are simply better (and cheaper long-term) to buy. If you’re a PMM leader or solo PMM prepping for 2026, here’s the Build vs Buy framework I recommend (see graphic): 1️⃣BUILD When: The workflow requires PMM judgment or nuance The workflow is unstable, evolving, or unique to your org The category is immature (no clear SaaS leader) The workflow is internal-facing and low risk You need flexibility + fast iteration, not rigidity You have a clear internal owner to maintain it Here is an example of something you should build:  Your internal messaging and narrative development. This workflow is highly customized, requires significant PMM judgment, needs iteration, and varies by product, audience, and campaign. 2️⃣BUY When: The workflow is mature, repeatable, and well-defined It is cross-functional (touches Sales, CS, PM, Execs) You need reliability + consistency, not customization The workflow requires automation, ingestion, or governance You need fast time-to-value Engineering won’t maintain an internal version Here is an example of something you should buy: customer proof infrastructure. For example, with UserEvidence. This workflow is mature, repeatable, and heavily dependent on automation, ingestion, and governance. It doesn’t benefit from deep customization or human-in-the-loop judgment. Buying is dramatically easier (and more reliable) than trying to stitch together an internal system with agents, spreadsheets, and makeshift permission workflows. Ultimately, deciding whether to buy or build is a trade-off between quality vs. time vs. money. So, before you invest time in AI workflows for yourself or your team,  Ask two questions: 1️⃣ Is this workflow mature enough that SaaS will do it 10x better? 2️⃣ Or is this workflow too nuanced or evolving to outsource? How do you evaluate build vs. buy decisions? I would love to hear your thoughts! #productmarketing #ai #software

Most procurement teams overthink the Build vs. Buy decision... They turn a strategic choice into an endless debate that delays critical projects and frustrates stakeholders. Here's the long and short of it... 95% of the time, the answer is BUY! But the remaining 5%? Those are the decisions that can make or break your competitive advantage. I created this decision tree after watching countless organizations waste months (and millions) building solutions that already existed in the market. The framework cuts through the noise with one fundamental question: → Is this capability core to our competitive advantage? If YES, you dive deeper into capability, resources, and economics. If NO, you should almost certainly buying. Even if something is core, you might BUY if you lack technical expertise, need it NOW or can't acquire it cost-effectively. Even if something isn't core, you might BUILD if no suitable commercial solution exists and it's business-critical. Tempted to build a procurement automation tool that already exists as a mature SaaS product? 👀 (I'm looking at you the "I can code anything with Gen-AI and Power Automate" crowd...) It might look cheaper on paper... But I assure you you're either missing assumptions or your assumptions are just plain wrong... You've got "super(wo)man syndrome". The bottom line? Strategic differentiator + internal capability + good economics = BUILD. Everything else = BUY. Stop debating. Start deciding. Get on with your core business. This is what's important. What's the most common mistake you see in Build vs. Buy decisions? Let me know in the comments 👇 _________________________ 𝗣.𝗦. I help companies choose and implement ProcureTech solutions for a living. Every Sunday, I send out a free newsletter which documents the best practices, trends and frameworks in ProcureTech. It's read by 10,000+ Procurement professionals (and counting...) Subscribe here for free: https://lnkd.in/ezb5wiFK

Build vs buy has become one of the biggest questions of 2025 The "buy" camp gets immediate wins that are hard to ignore: 1/ Speed to deployment - you get immediate access to proven, enterprise-grade technology. No waiting 18 months for your dev team to figure out what vendors already perfected. 2/ Lower upfront costs - avoid massive R&D investment and tech talent acquisition. Why spend millions building what you can license for thousands? 3/ Continuous updates - vendors handle model improvements and feature releases. Your AI gets smarter without your team lifting a finger. 4/ Reduced risk - benefit from testing across multiple clients and use cases. 5/ Focus on core business - legal teams concentrate on law, not software development. Stick to what you do best. But the "build" argument has serious strategic weight: - Custom fit means perfectly tailored workflows. - Data control gives complete ownership of training data and model outputs. - Revenue generation creates opportunities to commercialise tools. But even firms that build sometimes buy: Eg. Linklaters created Laila, their homegrown GenAI chatbot built on Microsoft Azure. But they recently rolled out Legora firm-wide. My takeaway: I think we should be asking: "What must we own vs. what can we rent?" Own what makes you irreplaceable. If losing access to a tool would destroy your competitive position, you don't own it - it owns you. Build the capabilities that clients come to you specifically for. Rent everything else. Why own a data center when AWS exists? Rent commodity capabilities and redirect that capital to what actually differentiates you. Join over 500 professionals getting the latest insights on AI: https://lnkd.in/eNXHfEX3 Follow me George Hannah for more on Legal AI

“𝗜𝗳 𝗔𝗜 𝗺𝗮𝗸𝗲𝘀 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝘀𝗼 𝗲𝗮𝘀𝘆 𝗻𝗼𝘄... 𝘄𝗵𝘆 𝗻𝗼𝘁 𝗷𝘂𝘀𝘁 𝗯𝘂𝗶𝗹𝗱 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗶𝗻𝘁𝗲𝗿𝗻𝗮𝗹𝗹𝘆?” HubSpot’s CEO, Dharmesh Shah, shared a great perspective on this, even with hundreds of engineers and world-class AI capabilities, HubSpot has replaced 𝘇𝗲𝗿𝗼 of its core SaaS systems with internally built versions. Not because they can’t build them. Because they shouldn’t. His point is simple: 𝗔𝗜 𝗹𝗼𝘄𝗲𝗿𝘀 𝘁𝗵𝗲 𝗯𝗮𝗿𝗿𝗶𝗲𝗿 𝘁𝗼 𝗰𝗿𝗲𝗮𝘁𝗶𝗼𝗻. 𝗜𝘁 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗹𝗼𝘄𝗲𝗿 𝘁𝗵𝗲 𝗯𝘂𝗿𝗱𝗲𝗻 𝗼𝗳 𝗼𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽. Even the best engineering teams don’t want to maintain 100+ internal tools, keep them up to date, track industry changes, respond to security shifts, and rebuild every time the business evolves. But here’s the part most enterprises miss: 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗳𝗮𝗶𝗹𝘂𝗿𝗲 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗵𝗮𝗽𝗽𝗲𝗻 𝗮𝘁 “𝗯𝘂𝗶𝗹𝗱” 𝗼𝗿 “𝗯𝘂𝘆.” 𝗜𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝗹𝗼𝗻𝗴 𝗯𝗲𝗳𝗼𝗿𝗲, 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗵𝗮𝘃𝗲 𝗰𝗹𝗮𝗿𝗶𝘁𝘆 𝗼𝗻 𝘄𝗵𝗮𝘁 𝗶𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱𝘀. That’s why Build vs Buy decisions go sideways: • Requirements are incomplete or AI-irrelevant • Stakeholders are misaligned on the problem itself • Dependencies between systems and teams aren’t visible early • Operational and governance constraints surface too late • Success metrics are undefined or unmeasurable When you skip this planning layer, Build vs Buy becomes guesswork and guesswork gets expensive fast. Here’s the reality I’ve seen inside enterprise cycles: 𝗕𝘂𝗶𝗹𝗱 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂’𝗿𝗲 𝗰𝗿𝗲𝗮𝘁𝗶𝗻𝗴 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘁𝗵𝗲 𝗺𝗮𝗿𝗸𝗲𝘁 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗼𝗳𝗳𝗲𝗿. But you need a full blueprint: problem definition, flows, data, integrations, acceptance criteria, handoff assets. 𝗕𝘂𝘆 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲 𝘄𝗵𝗲𝗻 𝘁𝗵𝗲 𝗺𝗮𝗿𝗸𝗲𝘁 𝗶𝘀 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗮𝗵𝗲𝗮𝗱 𝗼𝗳 𝘆𝗼𝘂. But only if you know which vendor actually fits your exact technical + functional requirements. 𝗕𝗼𝘁𝗵 𝗺𝗮𝗸𝗲𝘀 𝘀𝗲𝗻𝘀𝗲 𝗺𝗼𝗿𝗲 𝗼𝗳𝘁𝗲𝗻 𝘁𝗵𝗮𝗻 𝗽𝗲𝗼𝗽𝗹𝗲 𝗿𝗲𝗮𝗹𝗶𝘇𝗲. Most modern enterprise systems aren’t built or bought, they’re assembled, integrated, and extended. And none of these decisions should rely on instinct, preference, or internal politics. They should rely on 𝗮 𝗽𝗹𝗮𝗻. Because once you have clarity on, what you need → why you need it → who it impacts → what constraints exist → what good looks like → how it scales, the build vs buy answer becomes obvious. Most enterprises don’t struggle because they pick the wrong option. They struggle because they pick before they’re ready. Force Equals is the 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺 that makes both options viable, efficient, and high-confidence. If you're making Build vs Buy decisions for 2026 initiatives and want to see how this would pan out, let's have a chat. Amy Lakshit . Greg Tom #EnterpriseAI #CXLeadership #EnterprisePlanning #ForceEquals

Most build vs buy discussions happen too late And they start with the wrong question.... By the time the conversation comes up, the business is usually feeling the pain. Teams are bogged down in workarounds. Systems no longer fit the way the company operates. Delivery slows. Visibility drops. At that point, the decision feels urgent:  “𝗗𝗼 𝘄𝗲 𝗯𝘂𝗶𝗹𝗱 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗼𝘂𝗿𝘀𝗲𝗹𝘃𝗲𝘀 𝗼𝗿 𝗳𝗶𝗻𝗱 𝗮 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝗼𝗳𝗳 𝘁𝗵𝗲 𝘀𝗵𝗲𝗹𝗳?” But by then, the choice is reactive and not strategic. A better approach is to start with a few critical questions much earlier: ↠ What are we optimising for? Speed, control, scale, or cost? ↠ Where do we need flexibility, and where can we adapt to standard tools? ↠ How easily can our team adopt and maintain the solution? ↠ What are the longer-term risks of fitting the business around the tool? These questions help shift the decision from tactical to strategic. Most of the time, the answer isn’t fully “build” or fully “buy.” It’s a combination. Commercial tools for standard processes, and lightweight customisation where differentiation matters. Good architecture decisions support the business long after the implementation is done. That only happens when you ask the right questions up front. #scaling #buildvsbuy #software #softwaredevelopment

We spend $350K+ a year on AI agents. Here's our exact framework to decide build vs. buy. Quick background: We’re building Swan AI to hit $30M ARR with just 3 founders and a swarm of agents. No hires. No shortcuts. Just intelligent leverage. We call this playbook "the autonomous business". Today, our ai agents power GTM for 150+ B2B companies - from intent to booked meetings. And we run on the same stack ourselves: AI agents for Support. Onboarding. Product. R&D. Most teams get AI wrong. They build when they should buy - or buy tools they can’t adapt to their edge. We’ve made both mistakes. That’s why we built a matrix: To avoid wasted time, protect focus, and double down where leverage lives. It’s a simple 2x2. X-axis: how unique the use case is. Y-axis: how strong your internal capability is. Plot where you stand - and the decision makes itself. No endless debates. No guesswork. Just a clear call on where to spend your time. Start with the X-axis: How unique is this use case to you? Ask yourself: Is this a problem only I have - or one everyone has? Is the playbook clear - or constantly evolving? Does it rely on one tool - or ten systems and scattered data? If it’s horizontal, stable, simple → that’s common. If it’s specific, evolving, complex → that’s unique. Now for the Y-axis - and it’s not what most people expect. Being “AI-ready” has nothing to do with AI. It’s about automation muscle. Low-code fluency. The ability to build fast, and debug faster. If your team knows how to ship in Make or n8n - you’ve got high capability. If not, buy until you do. Don’t have that muscle yet? No problem. You don’t need to understand AI. You need to understand systems. Start here: Pick one workflow you repeat every week. Map the input. Define the outcome. Build a scrappy agent in Make or Zapier. Forget elegance. Just get it working. Because in this new era, the most valuable skill isn’t prompt writing or LLM tuning. It’s knowing when to build, when to buy - and having the muscle to do both. That’s why we didn’t stop at sharing the matrix. We built an AI agent that doesn’t just tell you what to do - it helps you do it. It guides your build vs. buy decisions, then walks you through building your first agent, fast. comment Muscle below and I’ll send you free access (just make sure we’re connected). p.s. if you're still waiting for it, DM and I'll make it right.

Build or Buy? It sounds binary. It rarely is. Every growing company hits the same fork in the road. You spot a need - a customer experience gap, a workflow bottleneck, a new growth lever. Now the real question: Do you build it yourself? Or do you rent it from someone who’s already done it? Seems simple. Until… The “buy” option delays launch because integration with your stack turns into a six-month headache. The “build” route burns 9 months of engineering time only to realise you’ve reinvented a mediocre wheel. And both cost more than you expected. Sound familiar? At London Tech Week, two leaders in conversation with Nikki Dean, broke this open with brutal honesty. Marcus Hunter, CTO at Evri Built their own customer routing platform to maintain control over the delivery experience - a strategic moat. But, they still plug into Databricks and AWS for the heavy lifting. “We wanted to keep the customer touchpoints close, but scale with proven infra. It's not all or nothing.” Sean Duffy, Software Lending Lead at CIBC UK & Europe Sees thousands of SaaS businesses. Doesn’t see SaaS as the enemy. “SaaS isn’t stifling innovation. Blind faith in it is.” In his world, the winners use SaaS to automate smart, focus internal build on what makes them different, and stay agile. What came through clearly: Build when it shapes customer loyalty or speeds time-to-value. Buy when someone else’s scale, support and stability beats your dev sprints. Both when integration isn’t an afterthought but part of your strategy. Neither if you don’t have clarity on the why. One profound note from Marcus: “Innovation fails when we don’t scope tightly. Big budgets and loose specs are a graveyard.” And a smart reminder from Sean: “You’re not just buying the tool. You’re inheriting its guardrails, agents, and governance risk.” Their shared caution about AI? Watch out for agent sprawl. Buy AI-enhanced tools blindly and you’ll wake up with 50 half-baked copilots and no control. Governance isn’t a blocker, it’s how you scale safely. Final word? Innovation lives or dies in how decisions get owned. Not just bought. Not just built. Owned, with eyes open and tradeoffs understood. Because the best systems aren’t monoliths - they’re modular, intentional, and built to evolve.