Build or Buy: The PM Tooling Decision in the Age of AI
Buying Default: Most leaders prefer to buy solutions unless specific workflow issues require building a custom tool.
Core Question: Determine if a workflow is crucial for differentiation or basic infrastructure to guide the buy/build decision.
Building Necessity: Companies may need to build solutions when no suitable off-the-shelf options are available for unique workflows.
Vibecoding Impact: AI-assisted tools like vibecoding lower barriers for non-engineers to create functional software quickly.
Hidden Costs: Building custom software can lead to long-term maintenance challenges, often making buying a safer option.
For project and operations leaders, few decisions carry more long-term consequence than whether to build a proprietary tool or buy an off-the-shelf solution. Get it right, and your team has exactly the infrastructure it needs to move fast and stay aligned.
Get it wrong, and you're either locked into a bloated SaaS stack that doesn't fit your workflows or buried under the maintenance burden of a homegrown system nobody fully understands anymore. The question has always been hard. Now, with “vibecoding” making it easier than ever for non-engineers to spin up functional software, it's gotten more complicated — and more interesting.
The Default Starting Point: Buy Unless You Have a Reason Not To
Most experienced operations leaders will tell you that buying should be the default position, and that building earns its way onto the table only when there's a clear, specific reason. Philip Stoelman, Founder & CEO of Network Republic, puts it plainly: "We default to buy unless we run into a workflow issue that no tool currently exists to solve without a lot of compromises. That's the honest starting point, and I believe most operations leaders who have been at this long enough end up there eventually."
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
We default to buy unless we run into a workflow issue that no tool currently exists to solve without a lot of compromises.
The logic is straightforward. Off-the-shelf tools come with support, documentation, continuous updates, and a user base that has already stress-tested the product. Building, by contrast, requires ongoing investment in development, maintenance, and institutional knowledge. Abdullah Shoaib, CEO & Founder of Energy Solutions, frames it this way: "We typically buy when a solution addresses a common business need and can be deployed quickly. We consider building only when the process is a competitive differentiator or when existing tools require too many workarounds that create inefficiencies."
We typically buy when a solution addresses a common business need and can be deployed quickly. We consider building only when the process is a competitive differentiator or when existing tools require too many workarounds.
The Core Question: Differentiator or Plumbing?
If buying is the default, what tips the scales toward building? For most leaders, the answer comes down to a single diagnostic question: Does this workflow differentiate our business, or is it just infrastructure?
Lizelle Balanco, Business Systems Manager at Cloudflare, describes the filter her team applies: "Our first question is always: Is this something that differentiates our business, or is it simply something we need to run the business? If it's a unique workflow, a competitive advantage, or a process that existing solutions don't handle well, then building becomes a serious consideration."
Our first question is always: Is this something that differentiates our business, or is it simply something we need to run the business?
Ciaran Burke, COO & Co-Founder of Swoop Funding, uses a similar binary: "We start with a simple test: is this capability core to how we differentiate, or is it table-stakes plumbing? Anything tied to our matching engine, lender workflows, or proprietary data we build; anything commodity — CRM, ticketing, BI, comms — we buy."
We start with a simple test: is this capability core to how we differentiate, or is it table-stakes plumbing?
The pattern across leaders is consistent: commodity functions belong in commodity tools. Proprietary workflows — the ones that encode how your business actually thinks and operates — are the ones worth building for.
When the Gap Is Too Big to Ignore: Building Out of Necessity
Sometimes the decision to build isn't a strategic choice so much as a practical one. The right tool simply doesn't exist, and no amount of configuration will make an off-the-shelf product do what needs to be done.
Dixie Willard, Founder & Chief Project Strategist of Poised & Plumb, arrived at this realization working in the interior design industry. When asked whether an off-the-shelf tool could solve her needs, her answer was blunt: "There isn't one. There just isn't one. And there are a lot of tools that designers could use that just don't exist.” Subsequently, Dixie has been working on various vibecoded projects to address this need.
There are a lot of tools that designers could use that just don’t exist.
Daniel Preston, Founder of LiveInCare USA, approaches the question more diagnostically: "The first question I ask is whether the process we're trying to support is actually unique. If the process is common, such as email marketing, analytics, payments, or CRM functions, I usually prefer buying an existing solution." The implication is clear — when the process is genuinely uncommon, buying stops being the right answer.
Aniket Ghonge, Senior Supply Chain Manager at Amazon, encountered this ceiling firsthand when existing enterprise tooling couldn't keep pace with his operational needs: "The current CRM technology that I was working with didn't have the capabilities I needed. I needed something that could help me automate my work, give me a way to compare multiple sources, and then generate a final demand plan for our new shippers." Ghonge went on to build a system that solves this niche problem, cutting 18 hours of work down to 1 hour.
When Vibecoding Changes the Math
For years, the build side of the equation carried a significant barrier to entry: you needed developers, time, and money. AI-assisted development tools — vibe coding platforms like Replit, Cursor, and others — have begun to erode that barrier in meaningful ways. For PMs and operations leaders without engineering backgrounds, the ability to prompt a functional tool into existence has introduced an entirely new option into the decision framework.
Michael Gold, Founder and Fractional Head of Delivery, recently put this to the test with his own CRM: "I just built my own CRM using Replit because I was using Close and it was costing me $100 a month. I won’t lie to you and say it's better than Close, but it's free, or at least it's $25 a month for Replit." The trade-off Gold describes — less polished, but dramatically cheaper and tailored to his exact needs — is one that more practitioners are starting to make.
I just built my own CRM using Replit because I was using Close and it was costing me $100 a month.
The Hidden Costs of Building: A Cautionary Perspective
The accessibility of vibe coding tools doesn't eliminate the risks of building — it just lowers the upfront threshold. The longer-term costs of owning proprietary software remain, and experienced consultants who have watched clients go down this road are quick to flag them.
Marissa Taffer, Founder and President of M. Taffer Consulting, has seen organizations spend heavily on custom builds that never should have left the whiteboard: "If I had been involved from the get-go, I think my recommendation would have been to buy something off the shelf and customize it instead of building what my client built.” Reflecting on this experience, Taffer elaborates on the frustrations: “I often had to go through the administrator to like get anything fixed. The tool was not very well-kept." The maintenance problem Taffer describes — tools that slowly decay because no one is properly resourced to keep them healthy — is one of the most common failure modes in homegrown software.
If I had been involved from the get-go, I think my recommendation would have been to buy something off the shelf and customize it instead of building what my client built.
The Vibe Code Ceiling: When Prototypes Become Products
There's an important boundary that vibecoding's rise has made newly urgent to define: the line between a prototype and a production system. A tool built in an afternoon to validate an idea is one thing. A tool that a team of twenty people depends on daily is something else entirely — and the path from one to the other requires more than prompting.
Tim Fisher, VP of AI at The Digital Project Manager, draws this line clearly: "If you build something that people rely on, it needs to become more than just a vibecoded project; it needs to be absorbed by the people that do this professionally and know things that you don't even know to ask. The value of these tools for non-coders is to be able to shortcut things like alignment around an idea and get past the 'is this going to work?' phase."
If you build something that people rely on, it needs to become more than just a vibecoded project; it needs to be absorbed by the people that do this professionally and know things that you don’t even know to ask.
Fisher's framing is generous toward vibecoding — it's genuinely valuable for collapsing the distance between idea and proof of concept — but clear-eyed about its limits. The prototype is the beginning of the conversation about whether to build, not the build itself.
Want more insights like these? Sign up for a free DPM account to hear from more experts like these.