The short answer
Building an internal search engine is cheap to start and expensive to keep. A competent team can stand up a working prototype over a few sources in two to four weeks, because retrieval itself is close to a solved problem now. The cost is everything after that: connector maintenance across source APIs that change without warning, mapping each system's very different permission model into something you can evaluate at the moment of the query, and incremental sync that does not fall behind. Those three are permanent engineering, not a project with an end date. Build if search is something you sell, or if your important content lives in systems no vendor supports. Otherwise the honest arithmetic favors buying, and the number that decides it is not the license fee, it is the fraction of an engineer you will spend every year forever.
Last updated: August 2026.
The proposal usually arrives from a good engineer with a reasonable case. We already run OpenSearch. Embeddings are a library call now. The APIs for Slack and Drive are documented. Why are we paying a vendor per seat for something we could put together in a quarter?
It is not a silly question, and the first part of the answer is that they are right about the part they estimated. You genuinely can index a few thousand documents, embed them, and get sensible semantic results back in a couple of weeks. Most build-versus-buy debates in this category go wrong because both sides argue about that first two weeks, which is the only part that is easy.
How much does it cost to build an internal search engine?
Model it as three separate things: the initial build, the infrastructure, and the permanent maintenance. Most internal business cases include the first two and quietly omit the third, which is the one that dominates the total.
| Cost line | Build in-house | Buy |
|---|---|---|
| First working version | Two to four weeks for a demo over two or three sources. Three to nine months for something a whole company can use | Hours to a couple of days, most of it initial indexing time |
| Connectors | You write and own one per system, plus pagination, rate limits, retries, and the rewrite when the source API version changes | Included, and the vendor absorbs API changes. Check your less common systems are on the list before signing |
| Permissions | The hardest part. Every system models access differently and you have to evaluate all of it per user, per query | Inherited from each source. Ask whether it is enforced at query time or copied on a sync schedule |
| Infrastructure | Index or vector store, embedding calls, model inference per question. Real but usually the smallest line | In the subscription |
| Ongoing engineering | Continuous. Plan on a meaningful fraction of an engineer permanently, and it does not taper | A few days of an IT admin's attention for connections and access reviews |
| Failure mode | A broken connector returns confidently incomplete answers rather than an error, so nobody reports it | Vendor dependency: connector coverage and roadmap are not yours to set |
There is a staffing line underneath all of this that rarely makes the spreadsheet. Search engineering is a specific skill set, and the people who have it are not usually sitting idle on your platform team. If the plan depends on hiring, add the months it takes to find and screen engineers who have actually shipped retrieval systems to the timeline, and price the risk that the one person who understands the ranking code leaves in year two.
What is actually hard about building an internal search engine?
Three things, in this order. None of them is the part people expect.
Connector maintenance is permanent, not a project. Writing a Slack connector is a week. Keeping seventeen connectors working across vendors who deprecate API versions, change rate limits, restructure their permission endpoints and add new content types is a standing obligation. The cruel detail is the failure mode: when a connector silently stops syncing, search does not go down. It keeps answering, using stale or partial content, and it sounds exactly as confident as it did before. Users do not file a bug for an answer that is merely incomplete, so these failures can run for months.
Permissions are the real engineering problem. Google Drive has per-file sharing plus shared drives plus domain-wide links. Slack has public channels, private channels, DMs and shared channels with external organizations. Confluence has space permissions plus page restrictions that inherit in their own way. Jira has project roles and issue-level security schemes. Now evaluate all of that for one person, at query time, fast enough that the search feels instant.
The tempting shortcut is to copy permissions into your index on a nightly job and filter against the copy. It is much easier and it introduces a window: between somebody losing access and the next sync completing, they keep receiving that content in answers. On the day someone leaves under difficult circumstances, or on the day the compensation spreadsheet gets re-shared, that window is the thing your security team will ask about. We go into the mechanics on permission-aware AI search.
Incremental sync is harder than the first crawl. The initial index is a batch job and it either finishes or it does not. Keeping up with changes means change detection per source, handling deletions and permission changes as first-class events rather than content updates, and backfilling after every outage. Systems that do not expose a reliable change feed force you to re-crawl, and re-crawling large sources on a schedule gets expensive quickly.
Can you just use a vector database and an LLM?
You can, and it will demo beautifully. A retrieval-augmented pipeline over a few thousand documents is a genuinely small amount of code in 2026, and the quality of current embedding models means the results will look convincing straight away. This is why so many of these projects get funded.
What the demo does not test is any of the three problems above, because a demo runs on a fixed content set, with one user, whose permissions are "everything." Scale it to a real company and the vector database turns out to have been the easy component. The distinction between a retrieval pipeline and a search product is roughly the distinction between an HTTP client and a browser: same core operation, and almost all of the work is elsewhere.
There is also a relevance issue that shows up only at scale. Pure vector similarity is bad at exact matches, so a search for a specific error code, invoice number or project key returns things that are thematically related instead of the thing you asked for. Production systems combine keyword and vector retrieval and then rerank, which is another component to tune and keep tuned. The architecture in full is on how AI enterprise search works.
When does building actually make sense?
Three cases, and they are narrower than the enthusiasm for building suggests.
The first is when search is part of what you sell. If your product has a search surface your customers use, you already have the team, the on-call rotation and the institutional appetite, and internal search is a marginal addition to something you were going to staff anyway.
The second is unusual sources. If the content that actually matters lives in a bespoke internal system, a niche industry platform or something air-gapped, no vendor has a connector and none is coming. In that case you are building at least part of it regardless, and the honest question becomes whether to build everything or buy the common sources and build the exception.
The third is a hard sovereignty or regulatory constraint that rules out every vendor deployment model available to you. Worth testing before you assume it: many buyers discover their constraint is satisfiable, and self-hosting an existing product is a middle path that self-hosting versus buying enterprise search covers.
Notably absent from that list: "we have good engineers." You almost certainly do. The question is not capability, it is what you want them permanently responsible for, and a connector fleet is a strange thing for a company that does not sell search to own forever.
What does buying cost, and what do you give up?
Per-seat pricing in this category, where vendors publish it at all, runs from roughly $10 to $40 per user per month, and a large part of the market publishes nothing and quotes on a call. The number that changes your total more than the headline rate is the seat minimum: some vendors sell from one seat, some require ten, and some effectively start around fifty to a hundred, which converts a manager's discretionary purchase into a procurement cycle. Ask for the minimum in the first email.
What you give up is genuine and worth stating. You are dependent on somebody else's connector coverage, so a system they do not support is a system you cannot search. You are dependent on their roadmap, which is why vendor ownership changes matter, and on their uptime. And you inherit their architectural choices, including the query-time-versus-scheduled permissions decision, which is why it belongs in your evaluation rather than in a footnote.
How do you decide?
Answer four questions honestly and the decision usually makes itself.
List every system whose content matters, then check how many a vendor already supports. If it is nearly all of them, buying is a configuration exercise and building is a duplication exercise. Second: write down which team is on call for internal search at 9am on a Monday in three years. If no name fits comfortably, you have found the real constraint. Third: baseline the problem before you solve it, by asking twenty people across three teams to log for ten working days every time they searched for something and every time they gave up and asked a colleague. That gives you both a defensible time figure and a list of real questions, which becomes your test set. Fourth: run those exact questions against a bought tool during a trial. Two weeks of evidence beats a quarter of architecture debate.
Most companies that run this properly end up buying, not because building is beyond them but because the maintenance is a recurring tax on a team that has other work. If you want the comparison of the four routes side by side, including the two most companies are already quietly paying for, it is on internal company search engine, and the capability itself is covered on internal knowledge search. If you would rather test than read, the console on either page runs real questions against real content.