Internal Chatbot: Build It In-House or Buy One, Costed Honestly

<p id="tldr"></p>

TL;DR

• Building an internal chatbot is genuinely easy to start and genuinely hard to finish, and the gap between those two facts is where most of these projects die.
• The model API is the cheapest line item by a wide margin. Retrieval, identity, logging, refusal behaviour, an admin interface and a retraining pipeline are the actual product.
• The cost nobody budgets is evaluation: a way to know whether a change to the prompt or the corpus made answers better or worse. Without it you are editing blind.
• Build is defensible if you have engineers to spare, unusual data residency constraints, or a requirement no vendor meets. It is rarely defensible to save money below about 1,000 employees.
• Buying costs between roughly $29 and a few hundred dollars a month depending on basis, which is less than a fortnight of engineering time in almost any market.
• The honest middle path is buying for the common case and building only the one integration your business genuinely needs.

The Prototype That Worked in a Week

A senior engineer built it over four days because the alternative was a procurement process. He pointed a model at the handbook, wrote about two hundred lines of retrieval code, put a text box behind an internal URL, and demoed it to the people team on a Thursday. It answered their questions. It answered them well.

Eleven months later it was still running and nobody could change it. The engineer had moved to a different team. The handbook had been updated twice and the chatbot had not, because refreshing it meant running a script on a laptop that had been reimaged. Nobody knew whether its answers were still correct, because there had never been a way to check beyond asking it things and nodding. It had no log of what employees had asked, so there was no way to find out what it had been getting wrong. And it was answering questions from contractors and from the finance team identically, because it had no idea who was asking.

Recommended Tools

Best tools for AI HR Tools

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

None of that was incompetence. The prototype was good and the demo was honest. What happened is the ordinary fate of a successful prototype: the easy 70 per cent got built in four days, and the remaining 30 per cent, which is the part that makes it a system rather than a demo, never got scheduled because the demo already worked.

The real question is not whether you can build an internal chatbot. You can, quickly. It is whether you will finish it.

What an Internal Chatbot Decision Is Actually Comparing

The comparison is usually framed as a model API bill against a vendor subscription, and that framing is why build looks cheap. It compares one component of the build against all of the buy.

A vendor product is not a wrapper around a model. It is a wrapper around a model plus retrieval, plus document ingestion for a dozen formats, plus an admin interface so non-engineers can change things, plus authentication, plus conversation logging, plus a retraining pipeline, plus whatever behaviour the vendor has tuned over thousands of deployments about when to decline. You either buy that stack or you build it, and the model bill is a rounding error in either case.

So the correct comparison is engineering time plus ongoing ownership against a subscription. Once you frame it that way the arithmetic usually resolves quickly, which is why vendors prefer that framing and why internal engineering teams, entirely sincerely, prefer the other one.

The Nine Things a Vendor Product Already Does

Worth listing explicitly, because the build estimate is usually made against a mental model containing two or three of them.

Document ingestion across formats. Your content is not in one place or one format. It is in documents, PDFs, intranet pages, slide decks and at least one spreadsheet. Handling that variety reliably is unglamorous work and more of it than anybody estimates.

Chunking and retrieval that works on policy text. Policies are structured in ways that break naive chunking, with conditions in one paragraph and exceptions three paragraphs later. Getting retrieval to return the whole rule rather than half of it is the single biggest determinant of answer quality.

Identity and group scoping. Knowing who is asking and varying the corpus accordingly. This is real authentication work and it is not optional for an internal deployment of any size.

An admin interface for non-engineers. Somebody in HR needs to add a document, change the tone, or correct an answer without filing a ticket. If every change requires an engineer, the system will stop being maintained the moment that engineer is busy.

Conversation logging you can read. Not analytics. The actual questions, readable, searchable, with the answers given. This is where you find out what it is getting wrong.

Refusal behaviour. Deciding when to decline and composing a useful decline. Easy to describe and surprisingly hard to get right, and the thing vendors have genuinely tuned.

A retraining pipeline. Something that notices the handbook changed and updates accordingly, on a schedule, without a human remembering.

Rate limiting and cost control. So one enthusiastic user or one loop does not produce a surprising bill.

An evaluation suite. Which is the next section, because it is the one that decides whether any of the above stays good.

When You Don't Need to Build

You do not have spare engineering capacity. Not "we could find some". Spare. If the engineers who would build this have a roadmap, this project will reach 70 per cent and stop, which is the worst outcome available because you will then be maintaining a half-system instead of paying a subscription.

Under about 1,000 employees with ordinary requirements. At that size the subscription cost is smaller than the fortnight of engineering time it takes to get to a credible prototype, let alone production. The money argument for building does not survive contact with a day rate.

Your constraint is content, not tooling. If your documents contradict each other, building a bespoke system will produce bespoke contradictions. The work is editorial and no amount of engineering substitutes.

Nobody will own it after launch. This is the condition the opening story illustrates. A built system with no owner decays faster than a bought one, because a vendor at least keeps the underlying model and infrastructure current while your bespoke stack quietly ages.

What the Build Actually Costs

Here is the shape of a real build estimate, stated as ranges because your rates and your existing infrastructure will move the numbers substantially.

A credible internal pilot, meaning retrieval over a curated corpus with authentication and basic logging, is typically three to six engineer-weeks. Production hardening, meaning the admin interface, the retraining pipeline, rate limiting and the evaluation suite, is usually another six to twelve. Call it somewhere between two and four engineer-months before you have something you would be comfortable pointing the whole company at.

Then there is ongoing ownership, which is the line that actually decides this. Budget something in the region of a day a month in steady state, more in the first quarter, covering model and library updates, corpus refreshes, investigating wrong answers and the occasional change in the underlying API. That is not a large number. It is a permanent one, and it belongs to a team whose priorities will change.

The model bill, by contrast, is genuinely small for this use case. Internal policy questions are short, the context retrieved per question is modest, and the volumes are low compared with any customer-facing deployment. For a few hundred questions a day it is a minor line item, and it is the only part of the build that behaves the way the optimistic estimate assumed.

The honest summary is that building trades a predictable subscription for an unpredictable internal commitment, and the trade is sometimes worth making. It is just rarely worth making for the reason people initially give, which is cost.

The Part Nobody Budgets: Evaluation

This is the single most common omission and the one that determines whether a built system stays good.

An evaluation suite is a fixed set of questions with known-correct answers, which you run after every change. Change the prompt, run it. Add forty documents, run it. Upgrade the model, run it. Without it, every change is a guess, and the specific failure mode is that somebody improves one category of answer while silently breaking another, and nobody notices for six weeks.

Building one is not hard and it is not glamorous. Thirty to fifty questions drawn from your real inbox, each with a correct answer written by somebody who knows the policy, plus a scoring step. The scoring is the fiddly part, because a correct answer can be phrased many ways, and the practical approach is a mix of checking that required facts appear and having a person read a sample.

The reason this matters more for a build than for a purchase is that a vendor has already absorbed this problem across many customers, and their regressions get caught by other people. Your bespoke stack has exactly one set of eyes on it. A model provider updating a model underneath you is a real event, and we have written about what happens when the model changes underneath you. Without an evaluation suite you will find out from an employee complaint rather than from a test run.

If you are going to build, build this first. A team that has an evaluation suite and no chatbot is in a better position than a team with a chatbot and no suite.

What Employees Need, Either Way

A straight answer rather than a document link. True of both routes and worth stating because home-built systems often default to returning the source paragraph, which is search with extra steps.

An honest refusal. The behaviour that most distinguishes a tuned product from a quick build. A bespoke system will happily paraphrase the nearest document unless somebody explicitly makes it decline, and nobody thinks to until the first bad answer.

Consistency with their manager. Cross-checking happens. If the system and the manager disagree, trust goes.

Privacy about what they asked. With a build, this is entirely your responsibility: where logs live, who can read them, how long they are kept. With a purchase it is a contractual question. Neither is automatically better, but only one of them is somebody else's job.

Availability on a phone, late. Both routes can do this. Builds frequently do not, because the internal URL sits behind a VPN that was never considered part of the project.

What Buying Costs, On What Basis

Every figure below was read from the vendor's own page on 15 October 2026: Matram, SiteGPT, Crisp and Chatbot.com.

The number that matters for this decision is the smallest credible subscription against the smallest credible build. Matram Pro at $199 a month is $2,388 over a year. Two to four engineer-months, at essentially any professional day rate in any market, is a larger number than that, usually by a multiple rather than a margin. And the subscription includes the nine things listed above plus somebody else's ongoing maintenance.

That is the whole cost argument, and it is why the cost argument for building almost never survives being written down. Which is fine, because cost is usually not the real reason anybody wants to build.

The Three Build Routes

From scratch on a model API. Maximum control, maximum work. You are writing the retrieval, the chunking, the auth and all nine components. Defensible if you have genuinely unusual requirements and engineers who want to own this.

On a retrieval framework. Use an existing library for the retrieval and orchestration layer and build the rest. This is where most serious internal builds actually land and it removes perhaps a third of the work. It also adds a dependency whose release cadence you do not control, which has its own maintenance cost.

On a platform with an API. Buy the retrieval and answering layer, build only your own integration and interface on top. This is the pragmatic middle and it is underused, because it is less satisfying than building and less simple than buying. It is often the right answer when you have one genuine special requirement and nine ordinary ones.

The Comparison at Three Sizes

The pattern is that build becomes defensible on scale and on constraints rather than on cost, and it becomes defensible later than most engineering teams estimate.

How to Choose: Five Questions

Is there a requirement no vendor meets? Name it specifically. Data residency in a particular jurisdiction, an integration with an in-house system, a regulatory constraint. If you cannot name one, the build is being motivated by preference rather than requirement, which is allowed but should be said out loud.

Who owns it in eighteen months? Not who builds it. Who owns it after the builder has moved on. If the answer is unclear, that is the answer.

Do you have an evaluation suite, or will you build one? If the honest answer is that you will not, do not build the chatbot, because you will have no way to tell whether it is still working.

What is the subscription you are avoiding? Write the number down. Then write down two engineer-months at your real rate. Then decide whether the difference is being spent on something that matters.

Can you buy the common case and build the exception? Usually yes, and usually nobody considers it.

Six Options Worth Knowing

Matram. Best for teams who want the stack handled and flat, predictable billing. Disclosure, which should shape how you read this: Matram is owned by the same people who publish this site. It is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats, and a 30-day trial that takes no card. Flat and seat-independent is the useful property for an internal audience, since the audience is everybody. Where it struggles, plainly: there is no free tier, so no indefinite zero-cost option; it answers questions but does not action tickets; and it is not an HR workflow platform, so approvals, cases and acknowledgement records sit elsewhere. If your reason for building is a bespoke integration with an internal system, that is exactly the requirement a packaged product will not satisfy and you should weigh this accordingly.

SiteGPT. Best for teams happy with an annual commitment. One yearly payment of $468, $948 or $3,108, equivalent to $39, $79 or $259 a month billed yearly. Where it struggles: the annual basis is the model, and the page-count ceilings matter with a large corpus.

Crisp. Best where you also want a shared inbox. Flat per workspace at $0, $45, $95 and $295 a month, with additional agents charged on top. Where it struggles: support-shaped assumptions, and the per-agent extras mean the flat rate is a floor.

Chatbot.com. Best for website-first use with internal as secondary. $19 per user a month entry, $29.50 Essential, $79 Growth. Where it struggles: per-user pricing fits a support team rather than a whole company.

Leena AI. Best for large organisations wanting an internal-first product. Where it struggles: no published price, enterprise sales cycle, oversized below a few thousand people.

Build it yourself. Best when you have a named unmet requirement, spare engineering capacity, and somebody who will own it in eighteen months. Where it struggles: everything in this article. The honest version of this option is not "build a chatbot" but "build and maintain nine components and an evaluation suite", and teams that frame it that way make better decisions in both directions.

The Decision Table

The Hidden Cost of Owning a Model Dependency

If you build, you take on a dependency whose behaviour can change without your doing anything, and this is the cost least visible at decision time.

Model providers deprecate versions, adjust defaults and release successors on their own schedule. A prompt tuned carefully against one version may behave differently against the next, usually subtly: slightly more verbose, slightly more willing to speculate, slightly different about when it declines. None of that announces itself. It shows up as a gradual change in answer quality that nobody attributes to the model because nobody changed anything.

Vendors absorb this on your behalf, imperfectly but genuinely, because it is their job and because their other customers notice too. Owning it yourself means owning a watch on provider changelogs and a re-run of your evaluation suite whenever something moves. Which, again, is manageable, and is a permanent commitment belonging to a team with other priorities.

Factor in library churn too. The retrieval frameworks in this space move fast and break things, and a build pinned to a version from last year accumulates security updates it cannot easily take. A year of neglect on a bespoke stack is more expensive to recover from than a year of neglect on a subscription, where the worst case is that your corpus is stale.

When Building an Internal Chatbot Is Genuinely Right

Three situations, and they are narrower than enthusiasm suggests.

A hard data constraint. Your data cannot leave a jurisdiction or a network, and no vendor can satisfy that. This is the cleanest case and it is a requirement rather than a preference.

An integration nobody sells. The valuable answers live in an internal system with no public API and no vendor connector. Note that this argues for building one integration, not nine components.

Scale where the subscription genuinely bites. At several thousand employees with high volume on a per-seat or per-resolution basis, the subscription can reach a number where a dedicated team is cheaper. Run the sum rather than assuming it; the crossover is higher than people expect.

Outside those three, the strongest honest argument for building is that your engineers will learn something useful and will enjoy it. That is a real benefit. It should just be stated as a development investment rather than as a cost saving, because finance will eventually notice which one it was.

What to Do With the Prototype You Already Have

A good proportion of companies reading this are not deciding whether to build. They already have something, built by somebody enthusiastic, running quietly. The decision in front of them is what to do about it, and that is a different question with a better answer than most teams reach.

Start by auditing it against five specific things rather than by asking whether it works. Does it log the questions people asked, in a form a human can read. Does it update when a policy changes, on a schedule, without somebody remembering. Does it know who is asking. Can a non-engineer add a document. And is there any test that would tell you if the answers got worse. A prototype typically scores one or two out of five, and the score matters more than the answer quality, because answer quality on launch day is not the thing that degrades.

Then make an explicit decision rather than letting it drift, because drifting is the default and the expensive outcome. There are three honest options. Finish it, which means scheduling the remaining components as real work with a named owner. Replace it with a product, which is usually cheaper than finishing. Or turn it off.

Turning it off deserves more consideration than it gets. An internal chatbot that nobody maintains is not neutral; it is actively giving a few hundred people confident answers drawn from a corpus that may be a year stale. Switching it off and going back to a shared inbox is a downgrade in convenience and an upgrade in accuracy, and it is a perfectly respectable decision while you choose properly.

Whatever you decide, extract the two useful artefacts before you touch anything. The curated document set somebody assembled is genuinely valuable and transfers to any product you buy. And if there are logs, read them, because they tell you exactly what your employees ask and where your documentation is thin. Teams routinely decommission a prototype and throw away both, then start the evaluation of a replacement from scratch with no data about their own question volume.

One caution on the finish-it option. The remaining 30 per cent is the unglamorous 30 per cent, and the engineer who enjoyed building the prototype may not enjoy building an admin interface and a retraining pipeline. Check that before committing, because a half-finished rebuild is worse than either of the other two options.

Who Actually Decides This

This decision reliably stalls, and it stalls because it sits between three functions who each hold part of it and none of whom owns it.

HR owns the problem and the content. They know what gets asked, they know whether the documents are correct, and they will own the thing day to day. What they usually cannot assess is whether a build is two weeks or four months, which means they are at the mercy of whoever gives them an estimate.

Engineering owns the estimate and, if you build, the delivery. The failure mode here is sincere and predictable: engineers estimate the interesting part accurately and the boring part optimistically, because the boring part is the bit nobody has thought about yet. An estimate that does not explicitly price the admin interface, the retraining pipeline and the evaluation suite is an estimate for a prototype wearing a production label.

IT and security own the review, and they enter late. This is where build-versus-buy decisions get reopened after they were thought settled, because a purchase triggers a data protection assessment and a sub-processor review, while a build triggers questions about where logs live and who can read them. Both are answerable. Neither is quick if first asked in week six.

The practical fix is to get all three in the room once, before any estimate exists, and agree three things in writing. What requirement, if any, a vendor cannot meet. Who owns the thing in eighteen months, by name. And what the subscription you would otherwise buy actually costs, so the comparison is against a real number rather than against an impression.

That meeting takes an hour and routinely saves a quarter. Teams that skip it tend to arrive at an answer anyway, usually whichever function pushed hardest, and the answer is often right by accident. The reason to run the meeting is not that the decision is hard; it is that an internal chatbot touches content, infrastructure and employment information at the same time, and no single function can see all three.

What Getting This Wrong Costs

The expensive failure is the 70 per cent build, and it is expensive in a way that does not appear on any budget line.

A system that answers questions but has no logging gives you no way to discover what it got wrong. A system with no retraining pipeline is correct on the day it launches and progressively less so thereafter. A system with no identity cannot be widened beyond the audience it launched with. Each of those is individually survivable and collectively they produce something nobody will decommission, because it works well enough to defend and badly enough to distrust. Meanwhile the subscription you avoided would have cost less than the first month of engineering.

The other failure is buying when you had a real unmet requirement and did not name it. Six months later the integration you actually needed is still impossible, and you have a subscription plus the original problem. That is a cheaper mistake and a more annoying one, and it is prevented entirely by writing the requirement down before the evaluation rather than during it.

There is a third cost that is easy to miss because it lands on a different team. An internal chatbot built in-house becomes a permanent small claim on engineering attention, and small permanent claims are how roadmaps quietly erode. One day a month sounds trivial next to a quarter's worth of feature work, and it is, right up until there are six such claims and a fifth of a developer is spent on things the company bought rather than built. Nobody ever decides to allocate that; it accumulates. When an engineering leader later asks where the capacity went, an internal chatbot is rarely the answer anybody remembers, because it was never on a plan. The subscription alternative has the opposite property: it is visible, it is on somebody's budget, and it gets reviewed annually. Visible costs are easier to manage than invisible ones even when they are nominally larger, and that is a reasonable thing to weigh rather than a trick of accounting.

So the question is not whether you can build an internal chatbot. It is whether you have a requirement that demands it, capacity to finish it, and somebody who will still own it when the person who built it has moved on.

When You're Ready to Decide

Write down the requirement that a vendor cannot meet. If the page stays blank, buy, pick on billing basis, and spend the engineering time on something only your engineers can do.

If the page is not blank, scope the build honestly as nine components plus an evaluation suite, and get an estimate from the people who would actually do it rather than from the person who wants it to happen. Then compare that against the subscription over three years, including the day a month of ownership.

And whichever way it goes, build the evaluation suite. It is useful if you buy, because it tells you whether the vendor is still good. It is essential if you build, because without it you are changing a system that affects a few hundred people's understanding of their own employment, with no way to tell whether you made it better.

A closing note on how to run the comparison, since the two options are not symmetrical and treating them as such distorts the result. A vendor can be trialled in an afternoon: point it at twenty documents, ask it thirty real questions, and you have genuine evidence about accuracy, refusal behaviour and whether non-technical staff can administer it. A build cannot be trialled, only estimated, and estimates in this category are reliably optimistic for the specific reason that the interesting third gets costed carefully and the boring two thirds get costed by assumption. So the fair comparison is not estimate against estimate. It is measured vendor performance against an engineering estimate you should mentally widen. Run the vendor trials first, even if you expect to build, because they cost an afternoon and they give you a concrete quality bar for what the build has to beat. Several teams who did that found the bar higher than they expected, particularly on the decline-cleanly behaviour, and changed their minds on evidence rather than on preference. That is the outcome worth aiming for either way.

Frequently Asked Questions