Build or buy? What an AI knowledge layer actually costs an equipment manufacturer

"We could build this ourselves."

It's a fair thing to say, and you should say it before you spend money with anyone. Including us, which does make this a slightly awkward post to write. So here are our own numbers, and the cases where you shouldn't call us.

Your engineer points an LLM at a folder of manuals and has something working by Friday. It answers questions. It cites a document. In a demo, it looks finished.

So: why buy a platform for something you prototyped in a week?

Because the prototype isn't the thing. The prototype answers questions from a pile of PDFs. The thing has to return the right procedure for the right product variant, cite the page it came from, and still be right in three years, after two product launches, a refrigerant transition, and the departure of the engineer who built it.

And here's the awkward part. You're asking this question because your support desk is under pressure: the same recurring error codes, the escalations that only two people in the building can resolve, the January queue. That pressure is exactly what makes a knowledge layer worth having — and exactly why nobody has ten months of engineering attention spare to build one properly.

That's the real decision. Not whether your team could.

Why this is harder for a manufacturer than for a software company

Most build-vs-buy advice assumes a software company with a help centre, one product and one language. You're an equipment manufacturer. Four things are different, all of them in the direction of cost.

You answer three audiences from one set of documents. Your own after-sales and first-line support team, an installer network you don't employ, and end customers. Same manuals, three levels of expertise, three tolerances for a wrong answer. That's not one assistant with an FAQ. It's one knowledge base with three carefully different exposures.

Your installer base grew faster than your support team. Heat pump volumes have climbed across Europe while the workforce doing the installing is newly trained. Every question the manual doesn't answer clearly arrives at your desk instead. And these are third parties: you can't train them, you can only answer them. We know that from the inside. Chapter spent three years training installers before we built software for them, and stopped because answering scales and training doesn't.

Your documentation is permanently slightly out of date. Product launches, spec revisions, F-Gas changes, R290 transitions. Each one puts a manual out of step with a machine that's already installed in someone's house.

You're multi-country and seasonal. A German question answered from a Spanish manual, in Dutch, in January, when the queue is longest and your best engineer is on holiday.

None of it is exotic. It's just a much harsher environment than "index the docs and add a chat box."

Two ways to build it yourself

The build-vs-buy framing hides something important: "build" means two quite different projects.

Not every "build it ourselves" is the same. The scope differs before the cost does.

Track A — light DIY: keep your assistant, build the knowledge layer

You already run an assistant, or your CRM vendor bundles one. It's fine on order status and unreliable on product data, because it's guessing from unstructured documents.

So you build only the layer underneath it: structure hundreds of technical data points, build retrieval and hallucination checks, and keep it current as specs change.

Narrower scope, smaller bill. But this is the layer that decides whether an answer about a specific variant is correct or merely plausible.

≈ €110K to build · ≈ €45K/year to run · ≈ 5 months to live · year one ≈ €135K

Track B — full DIY: assistant and knowledge system, end to end

Your team builds the assistant, the pipeline and the interfaces, and owns all of it from then on. Accuracy and governance realistically need 2–3 FTE. Delivery risk stays with you.

≈ €270K to build · ≈ €130K/year to run · ≈ 10 months to stable · year one ≈ €290K

Both are midpoints, priced at 2 FTE (light) and 2.5 FTE (full) fully loaded, plus tooling and infrastructure. Our figures, our assumptions. Swap in your own loaded cost per engineer and the ratio holds.

What the demo doesn't show

Here's the work that sits between a prototype and something you'd put in front of your support desk, your installer network and your customers.

Structure, not just chunks. This is the one that surprises people.

Claas Rühling's team at Solvis put it plainly after trying it first: pooling the documents together did not work. Answer quality only improved as the data became structured.

The reason is specific to your business. Near-identical product variants are where generic retrieval fails, because the wrong answer looks exactly like the right one. Getting that right means a validated graph of concepts, part numbers, relationships and cross-lingual synonyms, every node confidence-scored and approved by someone who actually knows the products. Production graphs run to tens of thousands of nodes.

The curation tool your experts will actually use, rather than a spreadsheet, is a product in itself.

Ingestion that survives your real SharePoint. Not a tidy folder of PDFs. Assembly videos, service bulletins in Word, spreadsheets, photos, the same manual duplicated across three sites, folders IT won't let you index. And deletion that removes the derived data too, not just the file, which is what a GDPR erasure request actually requires.

Verification the person asking can do in the moment. Every answer cited to document and page, so a technician can check it before they act on it. That's what turns an AI answer from a black box into something an engineer, an auditor or a warranty claim can survive.

A way to know what it got wrong. Every system produces bad answers. The question is whether yours turns them into a tracked queue with an owner and a count of how often it's been asked.

Three different failures need three different fixes: the knowledge was missing, the knowledge was there and the assistant handled it badly, or the evidence was too thin to conclude anything from. Most dashboards report the first, mislabel the second as the first, and present the third as fact.

A test suite for your answers, not just a rating button. Thumbs up and thumbs down matter. A rating, and especially the comment someone leaves with a thumbs down, is the fastest signal that something is wrong, and it feeds straight into the queue above. But ratings arrive after the answer has already gone out.

So there's a second layer underneath. Every file you ingest generates a set of example questions, and that set doubles as an eval set for that document: known questions, known source pages, expected answers.

Those run as scored assertions: is the answer grounded in the page it cites, does it pick the right product variant, does it decline to guess when the documentation genuinely doesn't say. Each run is tracked as an experiment and compared against the previous one.

That's what tells you whether a prompt change, a model upgrade or a different chunking strategy made the answers better rather than merely different. It's also the part that almost never appears in a DIY estimate, and without it every model upgrade is a coin flip you can't score.

Permissions across three audiences. Staff, installers and end customers reading from one knowledge base, each seeing only what they should, without maintaining three copies that quietly drift apart.

Compliance. ISO 27001, GDPR, EU AI Act readiness, EU hosting. Build it yourself and each one becomes your project, your audit and your liability.

Cost accounting. Finance will eventually ask what a resolved question costs.

The pattern across all of these is the same: the last stretch takes longer than everything before it, and most of what the system costs is spent after it goes live, not before.

The numbers, side by side

Track A — light DIYTrack B — full DIYChapterScopeKnowledge layer onlyWhole system, end to endPlugged into your assistant, or the whole thingInitial build€110K€270K€1,500Ongoing / year€45K€130K≈ €20,712Time to live≈ 5 months≈ 10 months≈ 3 weeksYear one≈ €135K≈ €290K≈ €22,212

That's 6×–13× less in year one. And the ongoing figure is a rate card rather than a headcount plan. It doesn't quietly grow into another FTE.

The year-one number is usage, not a licence. It assumes a generously sized install: internal staff, 50 new installers onboarding a year, around 200 active installers in the field, 20% of support calls deflected, and an anonymous advisor on your website. Roughly 2,950 answers a month, of which 1,500 are included and the rest bill at the standard overage rate. Use less, pay less. There are no seats to true up at renewal.

Every month of building is a month of paying for the problem

Build it or buy it, a working knowledge layer is worth the same to you once it's running. The only thing that changes is the date it starts paying.

Priced on the same model as the build, the knowledge layer is worth roughly €53K a year once it's live. That makes every month without it worth about €4,400.

A build that takes five to ten months therefore costs €17K–€39K in value that's simply gone, on top of the build itself. Not deferred. Gone.

It doesn't show up as a line in the project budget, either. It shows up as staff time, installer onboarding and support escalations you keep paying for while the internal project is still in progress.

Where the risk sits

In field support, a wrong answer isn't a poor customer experience. It's a safety issue and a warranty exposure — a technician acting on a procedure for the wrong variant, on someone's heating system, in winter.

Buying moves that risk off your team. ISO 27001 certified, GDPR compliant, EU AI Act ready, EU hosted, every answer traceable to its source, and model-agnostic, so your knowledge and IP stay yours and you're not tied to one model vendor.

Build it, and all four of those become your responsibility to establish, document and re-establish, every year.

When you should build

We'd rather you build than buy badly. So, honestly, here's when building is the right answer:

• Your scope really is small and stable. One product line, one language, documentation that barely changes, and no third-party installers to answer, only your own technicians. Something homegrown may serve you well.
• You have AI engineers with spare capacity and a mandate to keep them on this for three years. Not one engineer, once, for a quarter.
• You have a hard requirement no platform meets: an air-gapped environment, or an internal graph you're obliged to extend.

If none of those describe you, this isn't a decision about whether your team is capable. It's a decision about where their next year goes.

Questions worth asking before you commit

1. Who maintains this when the engineer who built it moves on?
2. How does it handle two variants whose manuals differ by one paragraph?
3. Who approves that an answer about a part number is correct, and in what tool?
4. What happens to a question we can't answer? Who picks it up?
5. How do we know a model upgrade improved the answers instead of quietly breaking some of them?
6. How do we serve staff, installers and end customers from one source without maintaining three?
7. Who owns ISO 27001, EU AI Act readiness and erasure requests?
8. What's the total cost in year three, not year one?
9. What could these engineers be building instead?

If more than three of those don't have an owner, you're scoping a product, not a project.

What buying looks like in practice

Solvis, a 300-person German heating manufacturer, now has 234 files in Chapter. Those files have handled thousands of technical questions without them reaching a specialist, and given hundreds of hours back to fieldwork. Their own view is that up to 50% deflection becomes realistic as the system matures; that's their forecast rather than a result, and we'd rather quote it that way.

At Qvantum, a heat pump manufacturer selling in eight countries, filter replacement alone accounts for 38% of everything asked. One question, thousands of repetitions, every one of them previously a call somebody had to take.

Think of it less as software and more as a new team member who has read every manual, every service bulletin and every training video, doesn't forget any of it in December, and cites the page number for everything it says.

It also has to turn up where the work happens: inside the CRM while the customer is still on the line, on the installer portal, on your public site.

"When our installers encounter installation questions or error codes in the field, they need instant access to accurate, Solvis-specific procedures, not generic heating advice."— Claas Rühling, Head of Technology & Production, Solvis

"Since we have two systems (CRM and performance system), it's great that Chapter AI provides a single source of information."— Erik Schoenmakers, Manager After Sales, Qvantum

In the end, it's your call

Building a knowledge layer for your products is achievable. Plenty of good engineering teams could do it. The question is whether owning a retrieval pipeline, a curation tool, a gap workflow and a compliance posture is the best use of your engineering time for the next three years.

If it isn't, you don't have to start big. Connect one product line and the documentation you already have in SharePoint, and see what your installers actually ask in the first month.

The question worth answering first, whichever way you go: what did your support desk get asked most last month, and how many of those questions genuinely needed a human?

We've already built it, so you don't have to.

See it running on your own documentation →‍