Build vs. Buy in the Age of Vibe Coding: 4 Questions Before You Generate Your Own PPM Software

Somebody on your team has already done it.

They opened an AI app builder on a Tuesday afternoon, described the portfolio dashboard they wished they had, and forty minutes later they were demoing a working web app to the PMO. Projects on the left, RAG statuses down the middle, a resource heatmap that actually renders. It looked good. It looked specific — more specific than anything a vendor had shown you, because it used your terminology, your stage gates, your business unit names.

And it raised the obvious question: if a portfolio manager with no engineering background can generate that in under an hour, why would we pay for project portfolio management software?

It’s a fair question, and it deserves a better answer than “because enterprise software is serious business.” The economics of building have genuinely changed. What hasn’t changed is what a PPM system actually is: not a dashboard, but the operational spine that connects strategy to intake to capacity to delivery to spend — running continuously, for years, across departments that disagree with each other, on data that arrives from six other systems.

The build-versus-buy decision was never really about the cost of writing code. It’s about who carries that spine. Four questions will tell you whether that should be you. A fifth section covers what to do with all that generative capability once you’ve decided — because the answer is emphatically not “nothing.”

Question 1: What is the real start-up cost?

The prototype cost forty minutes. That number is real, and it’s also the least useful number in the entire evaluation, because generating the interface was never the expensive part of building PPM software.

Here’s what sits between the demo and something the PMO can run a quarterly planning cycle on:

The data model. A portfolio dashboard that reads from a table you invented is easy. A portfolio system that holds programs, projects, phases, tasks, dependencies, resources, roles, allocations, actuals, baselines, versions, and the relationships between all of them — while staying correct when someone reorganizes the business unit hierarchy mid-year — is a genuinely hard modeling problem. Most homegrown PPM tools die here, not at the UI layer. The screens keep working; the numbers stop reconciling.

Integrations. Your delivery data does not live in your new app. It lives in Jira, Azure DevOps, Microsoft Project, Planner, Smartsheet, monday.com, a finance system, an HR system, and a few spreadsheets nobody will admit to. Each connection means authentication, pagination, rate limits, field mapping, conflict resolution when both sides change the same record, and a sync engine that fails loudly rather than silently. AI will write you a first-pass API client quickly. It will not decide what happens when a Jira epic is deleted but the linked portfolio item has three months of reported actuals against it.

Identity, permissions, and audit. Executives see everything. Program managers see their programs. Contractors see one project and no rates. Finance sees costs but not performance notes. Someone leaves and their access has to be provably revoked. This is unglamorous, security-sensitive work that no demo ever includes, and it is table stakes the moment the tool holds real salary-adjacent or commercially sensitive data.

Migration and change management. This cost is identical whether you build or buy, and it is usually the largest line item in either case. Cleaning historical portfolio data, agreeing on a single project taxonomy, retraining managers who have filed status the same way for eight years — AI has not made any of that cheaper. Any business case that models building as “cheap” while modeling buying as “expensive implementation” is comparing an incomplete project to a complete one.

The honest way to frame start-up cost is a question: what would it take for this prototype to survive one full planning cycle with real money attached to its outputs? Estimate that, and the forty-minute number stops doing any work in the analysis.

There’s a measurement problem underneath all of this, and it’s worth knowing about before you trust anyone’s estimate — including your own. In a randomized controlled trial published in July 2025, METR had 16 experienced open-source developers complete 246 real issues from their own repositories, with AI tools randomly permitted or forbidden per task. The developers expected AI to make them 24% faster. Afterward, they reported it had made them about 20% faster. The screen recordings showed they were actually 19% slower on the AI-assisted tasks.

Read that gap carefully, because it’s the crux of the build case: the people closest to the work systematically overestimated how much time AI saved them, in the direction of optimism, on tasks they knew well. Every “we could build this ourselves in a quarter” estimate is now being made by people subject to that same bias — and unlike a coding task, a PPM rollout doesn’t give you a screen recording to check it against.

There’s an opportunity cost buried here too. In most organizations, the people capable of turning that prototype into a system are the same people your revenue-generating or customer-facing initiatives are waiting on. Every sprint they spend on internal portfolio tooling is a sprint the portfolio itself doesn’t get.

Question 2: What are the ongoing operational costs?

Software you buy has a subscription line. Software you generate has an operating model, and the operating model is where homegrown PPM quietly gets expensive.

Somebody owns it forever. Not the person who built it — that person gets promoted, changes teams, or leaves. AI-generated systems are unusually vulnerable to this, because the original author often can’t fully explain the code either. When the sync breaks the week before board reporting, “ask the AI to fix it” is a strategy that works right up until the bug is in the interaction between three subsystems nobody has ever read end to end.

This is the pattern the industry is now naming out loud: code that is cheap to produce and expensive to own. GitClear’s 2026 Maintainability Gap research, which analyzed 623 million code changes between 2023 and 2026, found that as AI authorship scaled, the maintenance behaviors that keep a codebase workable went the other way. Duplicated blocks rose 81% since 2023. Copy-pasted code climbed from 9.4% of changes in 2022 to 15.7% in the first half of 2026, while code that was moved or refactored — the signature of someone consolidating and simplifying — collapsed from 21% to 3.8%. Maintenance of older code fell 74% against 2022 levels.

That’s the shape of the problem in one dataset: AI is very good at adding, and nobody has been tidying up. In a system you run for five years, tidying up is the job.

Connected systems move without asking you. Jira ships changes. Microsoft revises Graph and Project APIs. Your finance system upgrades. A purchased platform absorbs that maintenance as part of the subscription — it’s the vendor’s problem, and they fix it once for every customer. A homegrown integration layer means someone on your side is on permanent call for other companies’ release notes.

Security and compliance are recurring, not one-time. The most instructive data here comes from inside a real enterprise rather than a lab. Apiiro studied 7,000+ developers across 62,000 repositories at a Fortune 20 company and found that AI-assisted developers produced three to four times more commits — alongside roughly a tenfold increase in security findings. More telling than the volume was the type: AI-assisted work skewed toward design-level architectural weaknesses, while unassisted developers were likelier to make ordinary logic mistakes.

That distinction matters more for PPM than almost any other category of internal tool. Logic bugs surface fast — a number is wrong and someone notices. Architectural weaknesses surface in month fourteen, when you try to add a second portfolio hierarchy and discover the permission model can’t express it. And if your PPM tool holds resource costs, vendor rates, or unannounced strategic initiatives, it needs the review cadence of a system of record: patching, access reviews, and a defensible answer when your security team or an auditor asks who reviewed it.

The debugging tax is real and widely reported. In Stack Overflow’s 2025 Developer Survey of nearly 49,000 developers, adoption of AI tools reached 84% — but only 3.1% said they highly trust the accuracy of the output, 66% named “AI solutions that are almost right, but not quite” as their top frustration, and 45% said debugging AI-generated code takes more time than writing it themselves. “Almost right” is a tolerable failure mode for a prototype. It is a terrible one for the capacity model that decides who gets staffed next quarter.

Support and enablement. Purchased platforms come with documentation, training material, a support desk, and a user community that has already hit your problem. Homegrown tools come with whoever answers Teams messages fastest. That person’s calendar is a real operating cost, and it is rarely on the spreadsheet.

Technical debt compounds on a schedule. Each urgent fix layered onto a generated codebase makes the next one harder. Purchased software has technical debt too — it’s just carried on someone else’s balance sheet, amortized across thousands of customers, and paid for out of a subscription you can cancel.

Question 3: What are your business requirements — really?

The strongest argument for building is uniqueness: our portfolio process is different. Sometimes that’s true. More often it’s the difference between distinctive and merely idiosyncratic, and the distinction is worth money.

Ask a sharper version of the question: does this process win us anything?

A pharmaceutical company’s gated R&D portfolio process, tied to regulatory milestones, is a genuine differentiator. A construction firm’s method for modeling crew availability across sites may be too. But a seven-level project status taxonomy that exists because two departments couldn’t agree in 2019 is not a competitive advantage — it’s a negotiation nobody ever closed, and building software around it makes it permanent.

Buying forces the conversation that building lets you avoid. When you evaluate a PPM platform, you’re implicitly benchmarking against how a few thousand other portfolio organizations run intake, prioritization, capacity planning, and status reporting. Where your process differs, you get to ask why. Some of those answers will be good. Others will be the most valuable finding of the whole evaluation.

The second thing worth being honest about: PPM is not a collection of features, it’s a set of interlocking flows.

• Intake and idea evaluation feeds prioritization
• Prioritization is meaningless without resource capacity
• Capacity depends on live delivery data from wherever work actually happens
• Delivery data drives financials, forecasts, and time reporting
• All of it rolls into portfolio reporting that executives will act on

Build one of those and you have a useful tool. Build a dashboard, and what you usually have is the last step without the first four — a beautiful rendering of numbers whose accuracy still depends on people manually updating a table. That’s a reporting layer, not a PPM system, and the gap between the two is where most homegrown efforts stall.

It’s worth being precise about which of these your organization is actually failing at. Wellingtone’s 2026 State of Project Management report found that only 36% of organizations mostly or always deliver projects on time, 72% of project professionals spend half a day or more each month just collating reports, and 44% are dissatisfied with their PMO’s reporting capability. Note what that combination implies: the pain is real, and a generated dashboard addresses the symptom — report collation — without touching the data plumbing that causes it. A dashboard fed by the same manual updates is half a day of collation with better fonts.

A practical filter: list your requirements and mark each one differentiating, necessary, or habitual. Buy for the necessary. Configure or extend for the differentiating. Retire the habitual. If the differentiating column is short — and for most organizations it is — the case for building a system of record from scratch gets thin fast.

Question 4: How future-proof will it be?

Whatever you choose today has to still be defensible in three years. Two things determine that.

AI readiness is a data problem, not a model problem. Every PPM vendor is shipping AI features, and so can you — the models are the same models. The difference is what they can see. Predictive risk alerts, capacity forecasting, and automated status narratives are only as good as the underlying data: centralized, consistently structured, historically complete, and reconciled across connected systems. Organizations that spent three years building a homegrown tool typically have the opposite — fragmented data with inconsistent definitions and gaps wherever a sync broke. Bolting an AI layer onto that produces confident, well-written, wrong answers. Which is worse than no answers, because people act on them.

There’s a broader finding worth sitting with. Google’s 2025 DORA research on AI-assisted software development reported that around 90% of technology professionals now use AI at work and over 80% believe it makes them more productive — while roughly 30% have little or no confidence in the code it produces. Crucially, higher AI adoption correlated with both increased delivery throughput and increased delivery instability. DORA’s own framing is that AI acts as an amplifier: it magnifies whatever engineering discipline an organization already has.

Apply that honestly to your own situation. If you have strong platform engineering, code review, and operational practice, AI will make a homegrown PPM build go faster and hold up. If those muscles live in a different department from the PMO — which is the normal case — AI amplifies the absence just as efficiently.

Roadmap and gravity. A purchased platform has a published direction, a release cadence, a support commitment, and a customer base pushing it forward. Your internal tool has whatever attention it can win against revenue work in next quarter’s planning. Ask what happens to it when budgets tighten, when the champion moves on, or when the organization acquires a company running an entirely different toolchain. These are not hypotheticals; they’re the ordinary life of a five-year-old internal application.

There’s also a durability question specific to generated software. When the framework you built on ships a breaking change two years from now, migrating a codebase nobody deeply understands is a materially harder project than migrating one that was designed and reviewed by people. That cost lands in a future budget cycle, usually one where you’re already committed to something else.

When building is the right call

This isn’t an argument that nobody should ever build. A homegrown solution genuinely makes sense when:

• Your portfolio process is the product. If how you select and sequence investments is core intellectual property — think investment firms, some R&D-driven manufacturers — encoding it in software you own can be a real moat.
• You have engineering capacity that isn’t otherwise revenue-critical, plus a named long-term owner and a maintenance budget that survives leadership changes.
• Your requirements are narrow and stable. One team, one workflow, no financials, no cross-system integration — a well-scoped internal tool can be exactly right, and AI makes it cheaper than ever.
• A regulatory or data-residency constraint genuinely rules out every viable vendor. Verify this rather than assuming it; the answer has changed for most industries in the last few years.

Notice that the AI-generation question doesn’t appear in that list. AI changes how fast you get to a first version. It doesn’t change whether you should be in the business of running portfolio infrastructure.

The option most teams miss: run on the platform, extend at the edges

The build-versus-buy framing is dated, because for most organizations in 2026 the real answer is both — just not in equal parts.

Split your portfolio stack into two layers, and the decision gets much easier.

The spine is the system of record: the data model, the integrations, the permission and audit layer, the resource and capacity engine, financials, and the reporting foundation. This is the part that has to be right for five years, that every other system connects to, and where the cost of being wrong compounds quietly until it doesn’t. Buy this. There is no version of the argument where hand-rolling it is a good use of your organization’s attention.

The edges are everything narrow, local, and specific — the things that made that Tuesday-afternoon demo feel more relevant than any vendor’s. A view of the portfolio shaped the way your board thinks. A projection model that uses your finance team’s assumptions. A connector to the one system nobody else in your industry runs. These are real needs, and they are exactly the needs a generic platform historically handled badly — with a change request, a professional services engagement, and a nine-month wait.

This is what extensibility is for, and it’s the part of the build-vs-buy debate that AI has genuinely changed.

Extensions: vibe coding with the risk taken out

In PPM Express, an extension is a small web application — often AI-generated, often built in an afternoon — that runs on top of the platform and uses its data, its APIs, and its permission model. It isn’t a plugin you wait for a vendor to approve, and it isn’t a fork of the product. It’s your own narrow application, sitting on infrastructure somebody else maintains.

In practice, extensions tend to fall into three shapes:

Custom integrations. You run a system the standard connector list doesn’t cover — a legacy ERP, an industry-specific scheduling tool, a homegrown CRM your company has used since 2011. Rather than waiting for it to appear on a roadmap, you build the connector as an extension and it behaves like any other source in the portfolio.

Financial projections and modeling. Every organization calculates forecast, margin, capitalization, and recovery slightly differently, and those differences are usually non-negotiable because finance already agreed to them. An extension can hold your exact formulas and present them alongside live portfolio data, instead of forcing your model into somebody else’s field names — or, more commonly, into a spreadsheet nobody can audit.

Narrow business applications. The compliance checklist that only your regulated business unit needs. The vendor-onboarding tracker used by nine people. The custom intake form for one department’s peculiar approval chain. Individually, none of these justify a platform change; collectively, they’re most of what makes a PMO’s job specific.

Now re-read the four questions above with this structure in mind, because every objection to vibe-coded software shrinks dramatically when the generated code sits at the edge instead of at the center:

That last row is the whole argument. AI generation is genuinely excellent at producing small, specific, disposable software, and genuinely risky at producing durable infrastructure. Extensions put it where it’s excellent. When an extension turns out to be wrong, you throw it away and generate a better one — which is the correct relationship to have with software that took forty minutes to write. When a homegrown PPM system turns out to be wrong, you have a migration project.

There’s a governance dividend too. The Apiiro and GitClear findings above are about code that accumulates unreviewed in systems people depend on. An extension that reads from a governed platform, writes through its API, and respects its permission model has a much smaller blast radius by construction. You are not relying on the generated code to be secure; you’re relying on the platform underneath it, which is reviewed, patched, and audited by people whose full-time job that is.

That’s the shape of the decision. Not “can we build this?” — you almost certainly can, faster than you could two years ago. It’s which layer you want to be responsible for at 2 a.m. the night before a board meeting. Buy the layer where that question is terrifying. Generate freely on the layer where the honest answer is “we’d regenerate it in the morning.”

A five-minute gut check

Before your next build-versus-buy conversation, answer these:

1. Who is the named owner of this system in three years, and is that commitment written down anywhere?
2. How many external systems must it stay synchronized with, and who tracks those vendors’ API changes?
3. What is our honest total — build plus integrate plus secure plus migrate plus train plus maintain — against a subscription plus the same migration and training?
4. Which requirements are differentiating, and which are just habits we’ve never questioned?
5. If this tool were unavailable for a week, what stops? If the answer is “quarterly planning,” it’s infrastructure — and infrastructure deserves an owner with a support contract. If the answer is “one team’s custom view,” you’ve described an extension, and you should build it this afternoon.

If those answers make you uncomfortable, that’s useful. It’s much cheaper to be uncomfortable now than eighteen months into maintaining something you generated in an afternoon.

Get the spine and keep the speed. PPM Express connects the tools your teams already use — Jira, Azure DevOps, Microsoft Project, Planner, Smartsheet, monday.com — into a single portfolio view with resource management, financials, and reporting built in. Then extensions let you build the narrow, specific applications your organization actually needs, at the speed AI now makes possible, without owning the infrastructure underneath them. Book a demo and bring your homegrown wish list — most of it is either already in the platform or a short extension away.

Sources

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025)
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research
• Apiiro, 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks (September 2025)
• Stack Overflow, 2025 Developer Survey — AI
• DORA / Google Cloud, State of AI-assisted Software Development 2025
• Wellingtone, The State of Project Management Annual Report 2026