We audited what it would take to build a Sourcegraph equivalent internally, mapped the platform to 90 engineering requirements across 10 categories, and modeled 3-year costs for different environment sizes.
People ask us some version of the same question a lot: what would it take to build a Sourcegraph equivalent internally?
It's a fair thing to ask right now. Several core components of what we do are open source, like Zoekt, SCIP, and language indexers. AI coding agents write more code every month. Engineering teams build more internal tooling than they used to. The question comes down to: is code intelligence something your company should own, or something you should buy?
So we ran the exercise on ourselves. We audited the platform as if we were starting from zero in 2026, mapped it to 90 engineering requirements across 10 categories, and modeled 3-year costs for different environment sizes.
Before the numbers, we'll zoom out to look at the shape of the problem.
When someone says "build code search," they picture a search box, a results list, and a code viewer. That's the 10% above the waterline. Below it, the work is larger than most people expect. The hardest parts to build are also the parts that matter most for the AI agent workflows everyone is investing in right now.
Search. Code search isn't web search. Engineers need to find exact strings, regular expressions, and structural patterns across millions of files, with results streaming back fast enough to feel interactive. Doing this well means coordinating multiple search backends (each tuned for a different slice of the corpus, e.g. indexed vs. unindexed content) and careful query planning for the large set of search predicates a real codebase requires. Things like repo:contains.file(...), file:has.owner(...), and file:has.contributor(...) narrow the search space before text matching runs, and have to be planned and pushed down correctly so queries stay fast. After results come back, they still have to be ranked so the most useful match rises to the top.
Code intelligence. This is the part that answers where is this function defined (the exact file and line it lives on) and where is it used (every call site, every reference, every implementation of an interface, across your entire codebase and across repositories). It's what turns a pile of files into something an engineer (or a coding agent) can actually navigate. The language-specific indexers are open source these days. SCIP is an independently-governed standard with indexers for Go, TypeScript, Java, Python, and others, so "our" code intelligence system is not the indexers. What you still have to build and operate is the processing and querying layer on top: a pipeline that stitches indexer output into a unified graph, a resolver that follows a reference from one repository to its definition in another, a scheduler that re-indexes the right things when code changes, and logic that keeps navigation accurate as the graph evolves. Our version of that layer is roughly 96,000 lines of Go, and it requires ongoing maintenance, debugging, and security work.
Most engineers assume this part is simpler than it is. It's also the capability that determines whether AI agents can work effectively on large codebases. More on that below.
Repository syncing and Git serving. Every code host (GitHub, GitLab, Bitbucket, Gerrit, and others) has its own API quirks, rate limits, webhook formats, and authentication models. Integrating one takes days. Keeping twelve of them working reliably takes a dedicated team, because APIs drift, webhooks drop, tokens expire, and every partial failure has to be handled without losing data. After the code is synced, there's the layer that sits underneath every file view, search result, and navigation action: it clones, fetches, and serves repository data to the rest of the system. The challenge here is scale. If the organization has terabytes of repositories, the Git-serving layer has to hold it, fetch against it, and feed it to search and indexing without falling over, while also handling the edge cases large organizations tend to hit: shallow clones, Git LFS, submodules, partial fetches on monorepos too large to clone fully, and occasional on-disk corruption.
Permissions. Your identity provider decides who can log in, but you'll need additional configuration to specify which repositories each person can see. That requires continuously syncing access control lists from every code host, applying them to every search query in real time, and supporting directory-level permissions inside large monorepos. For regulated industries, this subsystem is what determines whether you pass your audit.
Storage and the rest. The plumbing underneath all of this is substantial. The totals below are not a shopping list an internal build would need to reproduce one-for-one. They reflect years of supporting many customers with different deployment models, code hosts, compliance regimes, and scale profiles. Read them as a marker of scope: 240 database tables across three databases, 29 services communicating with each other, an API with more than 100 endpoints, 51 types of background jobs, and 17 authentication mechanisms covering every SSO standard enterprises require. Plus observability: 26 monitoring definitions and 121 alert thresholds so the system tells you when something is wrong before your users do. An internal build would intentionally cut a large portion of this, but each category (storage, inter-service communication, APIs, jobs, auth, observability) still has to exist in some form.
Our scope is broader than an internal build would require, because our support structure is more generalized. But the set of things any given organization has to support isn't static either. Every acquisition adds new code hosts, new identity providers, and new compliance requirements to the internal platform team's list, whether the company is acquiring or being acquired. Enterprise environments demand many layers of complexity that are easy to underestimate, and the list tends to grow rather than shrink.
When teams scope an internal build, they reasonably start by identifying where the scope can be reduced. Fork an open source search engine. Reuse your existing identity provider. Support only the two or three code hosts you actually use. Skip batch changes and code insights for now. These are sensible reductions. The problem is that cutting features doesn't save much work, because most of the work isn't in the features. It's in the enterprise requirements underneath them: scale, authentication, the quirks of your specific environment, and the user experience polish that decides whether your engineers actually adopt the tool and benefit from it.
The search engine is forkable. The search infrastructure around it is not. The open source search engine (Zoekt) gives you a fast way to look up text across a lot of files. What makes it useful for engineers is the layer on top: a query language they can use to express real questions, a planner that respects permissions, result streaming so answers arrive quickly, and ranking so the most useful matches come first. That layer is what has to be built. Without it, you have an engine with no car around it.
The language indexers are forkable. The integration layer is not. The open source indexers (one per programming language) produce a raw map of a codebase. Turning those maps into working cross-repository navigation takes additional infrastructure: a pipeline that stitches them together, a resolver that follows a function call from one repository to its definition in another, a scheduler that re-indexes the right things when code changes, and logic that figures out how to build and index a given repository in the first place. None of that is included.
Your identity provider handles who can log in. It does not handle which repositories each person is allowed to search. That's a separate subsystem, and it's the one regulated environments care about most. It has to continuously sync access control lists from every code host, enforce them on every query in real time, and support directory-level permissions inside large monorepos. For SOX-regulated environments, this is the piece that determines whether you pass an audit.
You can narrow the scope of what you build around these open source components, but you cannot skip them. You don't necessarily need to build a Ferrari for your engine, but you'll need a car around it to drive.
Scope reductions are smaller than they look on paper because most components depend on several others.
Consider a single feature: code search. To search, you need an index. To build the index, you need repository data. To retrieve repository data, you need a connector for each code host. To authenticate those connectors, you need an identity system. To apply per-user access controls, you need a permissions model. To keep permissions up to date, you need background workers. To run workers reliably, you need a database. To evolve the database safely as the system changes, you need a migration framework. Every piece of that chain has to exist before the search box at the top returns a single result.
Code intelligence stacks another chain on top. When an engineer clicks "go to definition," the system has to figure out which version of the code was indexed, adjust for any changes since then, follow the reference across repositories if the definition lives in a different codebase, and translate the result back to the version of the code the engineer is actually looking at. "Find all references" is harder still, because the answer can span thousands of locations across the entire organization's codebase and must be returned in a way that remains responsive.
When we mapped the platform to 90 engineering requirements, we found that even a minimum viable version of basic code search touched 8 of the 10 major subsystems. About 30% of the feature set requires building across 80% of the engineering surface area. That's the pattern that causes scoped internal builds to overrun their timelines.
AI agents write code faster every month. For bounded, well-understood work (basic API handlers, logging boilerplate, test scaffolds, database access code, migration templates), they meaningfully accelerate builds. We use them ourselves.
Two things are true at the same time, and both matter for the build decision.
First, for novel infrastructure, writing code isn't the bottleneck. The bottleneck is the design decisions you only discover by operating the system in production. Our codebase has more than 800 database migrations, and each one represents a decision we made in response to something we observed running under real load across hundreds of enterprise environments over nine years. An AI agent can write code that plugs into an existing search engine. No agent can tell you from a prompt that you need a specific storage strategy to keep search fast as your index grows, or that your permission-sync service needs particular safeguards to stay consistent when code hosts fail, or that your code-intelligence pipeline needs to clean up stale references in a specific order to avoid returning wrong answers. Those decisions come from operating the system, not from designing it on paper. Agents compress the writing of code. They don't compress the operational learning that tells you what to write.
Second, and this is the more interesting point for most teams right now: code intelligence is what makes AI agents effective on hard problems in the first place. An agent that can only search a codebase by keyword hits a ceiling, and a smarter model doesn't fully overcome it. What makes the difference is precise code navigation: the ability to ask "where is this function defined?" and "where is it used?" and get accurate answers across the entire codebase, including across repositories. On large codebases (millions of lines of code, with deeply interconnected components, like large Rust, C++, or Java projects), the difference between an agent with navigation tools and an agent without them is often the difference between solving the problem and getting stuck.
So the build decision isn't "build code intelligence or let AI agents handle it instead." The agents need the infrastructure. The real question is whether you want to build and operate that infrastructure yourself, or buy it.
Based on patterns we've seen in teams that have tried, internal builds tend to hit the same friction points in roughly the same order.
Early on, permissions become their own project. The team recognizes that enterprise code search requires enforcing access at the repository level, but their existing identity provider doesn't support this. It only tells you who someone is, not which repos they're allowed to see. Building a system that continuously syncs those permissions across every code host becomes a subsystem with its own roadmap, on-call rotation, and bugs. The bugs here aren't benign. A mis-applied permission can expose source code to someone who shouldn't see it. Perforce is the canonical cautionary tale: every directory or file can have completely different permissions, with overlapping allows and blocks down the directory tree. Any in-house search system built on top has to parse the p4 protects file correctly, for every user and every query, or it will leak content. That's the kind of bug you find out about from a compliance review rather than a stack trace.
Then, search quality at scale becomes the problem. General-purpose search engines are built for documents, not code. Teams discover they need code search that understands programming language syntax, regular expressions that run across millions of files in a reasonable amount of time, results that stream back as they're found rather than arriving in one chunk, and ranking that knows a function definition matters more than a comment mentioning the same word. None of this comes out of the box.
Next, the code host integrations start breaking. Connecting to a code-host API for the first time can take days. Keeping that connection working over years takes a dedicated team, because webhooks fail silently, rate limits change without notice, API versions get deprecated, and authentication models get updated. The integration layer is never done.
Eventually, the project hits a maintenance cliff, and the team that was supposed to build a platform becomes the team that keeps it from falling over. New features stop shipping. Engineers who joined to build something new spend their time patching what they've already built.
It's easy to underestimate the build-vs-buy cost by focusing only on the build portion, but system maintenance is also part of the calculation.
At a fully-loaded cost of $220K per engineer, a 5-person maintenance team runs $1.1M per year, indefinitely. Those engineers spend their time just keeping the platform alive: responding to code host API changes, applying security patches, fixing permission sync failures, and reconciling your fork of the open source components with upstream updates. They are not shipping features for your customers.
In every scenario we modeled, maintenance costs over years 4 through 10 exceed the initial build cost. The cost question has two parts: how much to build, and how much to keep running for as long as your engineers need it.
Forking is free. Maintaining a fork is not. The open source components we mentioned earlier receive regular upstream updates, which means forking them costs nothing on day one. The cost arrives later. Every internal customization your team makes adds another layer of distance between your fork and upstream, making subsequent upstream merges harder. Our own fork of the open source search engine has diverged in nine significant ways, including changes that let us run multiple customers on shared infrastructure, changes to storage strategy at very large scale, and a faster regex engine. None of these changes exist upstream. After about 18 months of accumulated customization, most forks reach the point where merging upstream changes back in becomes impractical, and you're effectively maintaining your own private version of the software, with no upstream community to share the work.
We modeled three scenarios against a fully-loaded cost of $220K per engineer, covering both the build phase and ongoing operations.
| Environment | Build team | Build duration | Ongoing ops | 3-year total |
|---|---|---|---|---|
| 500 repos, 1 code host | 8–12 engineers | 12–18 months | 5–8 engineers | $5.5–9.4M |
| 2,000 repos, 2–3 code hosts, SOC 2 | 15–20 engineers | 18–24 months | 10–15 engineers | $10.4–17.5M |
| 5,000+ repos, 3–5 code hosts, regulated | 20–30 engineers | 24–36 months | 15–22 engineers | $27.3–58.0M |
Cutting scope helps less than it looks. A build that delivers only search, skipping the rest, still lands in the multi-million-dollar range over three years, because the enterprise requirements underneath search (permissions, code host integrations, reliability at scale) are the same either way.
These numbers are based on scoping the work against the surface area we maintain today. Your numbers will differ depending on how much you descope, how much technical debt you're willing to take on, and how much of your engineering capacity you're willing to tie up in maintenance work that doesn't ship features to your customers. The ranges are wide on purpose because many variables are at play. This is just the shape of the decision. We plan to share documents outlining our methodology in more technical detail, including a total cost of ownership breakdown across various enterprise tiers and a build-readiness checklist in a follow-up post.
We've been framing this as a build vs. buy decision, but that's not the full picture. A few other options deserve consideration.
Native code host search. The built-in search in GitHub, GitLab, and Bitbucket works well for keyword searches when your code lives in a single place. It doesn't let engineers navigate between repositories, and doesn't unify search across multiple code hosts.
AI-native coding tools with built-in indexing. Tools like Cursor and Copilot Workspace are built for the individual developer's workflow: the engineer opens the tool, points it at their repository, and gets intelligent assistance inside their editor. These are good at what they're designed for. They're generally not designed to serve as shared infrastructure across a large engineering organization, and their index scope and permission models vary in ways that matter at enterprise scale.
A lighter open source stack. You can assemble something from open source pieces (a search engine, an indexer, and whatever else you need to tie them together) and stand up a basic system cheaply on day one. The catch is that this puts you back at the top of this post, building the integration layer that makes those pieces work together as a product your engineers will actually use.
A commercial platform. Sourcegraph is one. We're not the only option in the category.
Build it yourself. The option this whole post has been about.
Different options fit different organizations. A 200-engineer company on a single code host is making a legitimately different decision than a 5,000-engineer regulated enterprise with five code hosts and a compliance team. We'd rather have the conversation about which option fits your situation than pretend the choice is binary.
Your engineers could build code intelligence. They could build cloud infrastructure, but you buy AWS. They could build single sign-on, but you use Okta. They could build observability and monitoring, but you use Datadog. Code intelligence belongs in the same category: a deep, specialized capability that sits underneath your business but isn't your business.
15 to 20 engineers working for 3 years is 45 to 60 engineer-years of effort. At most companies, that's an entire new product line, a major platform migration, or the AI features your customers are actually asking for. Even at the lower end of the estimates, a scoped search-only build still represents real work that won't happen while the build is underway, and real hiring that won't go toward your core product.
The question isn't whether your team could build code intelligence. It's whether 45 to 60 engineer-years is the best use of that headcount, given that commercial options exist today, and given that the infrastructure in question is what your AI-assisted developer workflows will increasingly depend on to be effective.
There's also an economies-of-scale argument that's easy to miss. An internal build absorbs 100% of the cost of becoming specialists in code intelligence. The headcount, the on-call burden, the operational learning, the ongoing maintenance, all of it is carried by one company for the benefit of one company. A vendor spreads the same expertise across many customers, so each customer pays a share of it rather than the whole thing, and the specialists get to focus on code intelligence as their core product rather than as one more thing on an internal platform team's list.
If you're working through this decision and want to discuss the trade-offs (including whether buying from us is the right answer or not for your situation), reach out.
With Sourcegraph, the code understanding platform for enterprise.
Schedule a demo