Stop Building What Already Exists: Graph-Grounded Feature Discovery for Engineering Teams

Engineering leaders at B2B SaaS companies have been telling each other a version of the same horror story for at least a decade: somebody on team A spent two quarters building a thing, then discovered that team B had built essentially the same thing 14 months ago, but called it by a different name and parked it in a different repo. The duplicate could just as easily sit in a vendor integration the company already pays for, or in a competitor's GA release. Most engineering leaders have a version of this story, and nobody measures it, because duplicated work never shows up in a retrospective.

The Standish CHAOS Report has been measuring software outcomes for 30 years from a different angle. Their 2020 report put the share of software projects that finish on time, on budget and with a satisfactory result at 31%.[3] Two-thirds of the work either ships late, ships over budget, ships descoped, or doesn't ship at all. Some of that descoped work, in our experience, is functionality the team found mid-cycle already existed.

The cheapest feature to build is the one you don't need to build — because you discovered the equivalent in a vendor integration, an internal library, or a competitor's public API before kickoff.

This post is about why feature discovery is structurally a graph problem, what the GraphRAG benchmarks actually show, and what an engineering organization looks like when its decision-making substrate is a knowledge graph instead of a Confluence search.

Section 1: The discovery problem is multi-hop

Consider the question a tech lead asks at sprint planning: “Before we commit two engineers to building this capability, does any vendor we already integrate with ship it, does our codebase already have a version of it in a sibling product line, and have any of our top three competitors shipped it in their last two quarterly releases?”

That's three traversals:

• Internal product: this capability → does it exist in our own feature taxonomy → which internal team owns it → is it accessible via our internal APIs?
• Vendor integrations: this capability → which of our active integrations ships it → does it cost extra → who owns the integration relationship?
• Competitor releases: this capability → which competitors → in which of their products → in which release window → with what reception?

Each traversal requires a different data substrate. Internal product: an architecture wiki, plus tribal knowledge from engineers who've been at the company more than three years. Vendor integrations: a contract repository, plus the vendors' own release notes. Competitor releases: whatever the CI team ships in their slack updates, if anyone reads them.

The result is that the question doesn't actually get answered before kickoff. The team starts building. Mid-sprint, somebody notices the vendor integration ships it. Mid-quarter, somebody sees Competitor B already has it. The work ships, gets repackaged or descoped, and the org records a successful release. The duplicated effort never shows up in any retrospective because nobody owns documenting it.

Section 2: What GraphRAG actually measures

A public benchmark of graph-grounded retrieval against the status-quo vector-RAG approach is Microsoft Research's April 2024 paper, From Local to Global: A Graph RAG Approach to Query-Focused Summarization by Edge et al.[1] It's worth reading directly because the results aren't marketing · they're a head-to-head benchmark on two corpora (podcast transcripts and news articles), with an LLM as the judge.

Microsoft GraphRAG: wins most head-to-head comparisons on global questions

The paper distinguishes between two question types:

• Local questions: "What did this specific document say about X?" — the retrieval problem vector RAG was designed for. Both approaches perform well here.
• Global questions: "Across the entire corpus, what are the recurring themes about X?" · the aggregate, whole-corpus problem many enterprise questions actually require.

On global questions, GraphRAG's answers won 72-83% of head-to-head comparisons against a conventional RAG baseline on comprehensiveness, as judged by an LLM evaluator.[1] The reason: vector retrieval surfaces semantically similar passages, but it has no mechanism to recognize when two passages refer to the same node or when one node is a parent of another. GraphRAG builds an explicit graph of the nodes in the corpus and summarizes communities of related nodes to answer aggregation questions more comprehensively.

For an engineering team trying to answer "has this capability been built anywhere we should know about?" the bar is an answer good enough to redirect two engineers on. That takes an answer that knows which nodes are the same thing, which a vector index alone does not.

Section 3: Why this maps onto engineering productivity

McKinsey's 2023 generative AI report named software engineering one of the functions with the most to gain, estimating the direct productivity impact at 20 to 45 percent of current annual spending on the function.[2]

The mechanism is the same as the discovery problem above: when the engineer asking "has someone built this?" gets a useful answer in seconds instead of days (or never), they make different decisions.

Atlassian's 2024 State of Developer Experience survey of 2,100+ developers and leaders found 69% of developers lose eight or more hours a week to inefficiencies.[7] Some of that lost day is the "trying to find out if X exists" problem.

69% of developers lose a full day a week to inefficiencies. Some of that day goes on finding out whether X already exists.

Section 4: What an engineering org looks like with a graph in place

Pre-sprint capability check

Before the sprint commit, the tech lead asks the graph: “Capability X — does it exist anywhere we can reach?” The graph traverses:

• Internal product nodes · have we shipped this in another product line? Returns: yes, the Risk product team shipped a version in 2024 Q3. Slack thread linked.
• Vendor integration nodes · do any of our active integrations ship this? Returns, in this example: one of the team's CRM integrations already ships a version, included in the current contract.
• Competitor product nodes · which competitors have shipped this in the last two quarters? Returns, in this example: three competitors shipped versions in the last 90 days, each with citations to release notes and review sentiment.

Total cost: zero engineers redirected. Outcome of the sprint planning conversation: “Let's wire up the integration for the immediate need and watch how the strongest competitor's version performs over the next 60 days before we commit to building.”

In-cycle drift detection

Six weeks into the build, a competitor ships an updated version with a feature the team hadn't scoped. When the release appears in one of the signal sources the graph watches, it is written to the graph as a dated signal on the competitor's product node and flagged to the engineering team as a watch item. The team decides whether to expand scope, ship as planned, or pause.

Post-ship competitive positioning

After shipping, the team queries the graph for: “Across our 80 most-similar accounts, which are now evaluating Competitor B's version of this capability?” This isn't engineering work anymore · it's GTM work · but the substrate is the same graph.

Section 5: The architectural choice

Engineering orgs that have looked seriously at building this for themselves typically end up at one of two architectures:

Path A: Internal-only knowledge graph (Neo4j-class build)

Build a Neo4j cluster (or equivalent), define your schema, ingest your internal systems (Jira, GitHub, Confluence, Salesforce, Pendo), and iterate. This is what LinkedIn, Google, and Microsoft did at scale.[5][4] It works, but it is a large engineering programme, and the ongoing maintenance is its own team.

Path B: Hybrid · subscribe to a market graph, integrate your internal data into it

Subscribe to a productionized market graph (vendor, product, category, signal data) and integrate your internal nodes (your accounts, your product, your integrations) into the same graph schema. The market side is already there; you only own the internal side. This is the build-vs-buy math that recently flipped.

Path B is the architectural pattern PYRAMYD is built around. The market graph is the public side; tenant slices add your internal product, your accounts, and your integrations into the same graph — with row-level security so your data never crosses tenant boundaries.

What this means for the next 24 months

The vector-RAG era of enterprise AI is going to age the way the "upload your PDFs and chat with them" demos from 2023 did. They were impressive, but the answers weren't reliable enough to redirect engineering work on. GraphRAG's benchmark made part of the reason measurable: on questions that span a whole corpus, a graph-built index beats plain vector retrieval.

Engineering organizations that ground their AI tooling in a knowledge graph — whether built or bought · are going to spend the next 24 months pulling away from the ones that don't. The question is which side of the gap your team wants to be on.

We'll cover the GTM side in the next post: The Account Intelligence Problem · and the Graph that Solves It.