Build or buy? What an AI knowledge layer actually costs

"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 let's look at what you're deciding.

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 a working prototype isn't a production system. The prototype answers questions from a pile of PDFs. The production system has to return the right procedure for the right product variant and cite the page it came from. It still has to 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 hardest 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, and the January or July peak in demand. That pressure is exactly what makes a reliable knowledge layer worth having. It's also why nobody has ten months of engineering time to spare to build one properly.

That's the real decision: whether your team has the time to build and maintain it. Not whether they could.

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

Most build-vs-buy advice assumes a software company with a support centre, one product and one language. You're an equipment manufacturer. Four things are different. All four add 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 different tolerances for a wrong answer. That's not one assistant with an FAQ. It's one knowledge base with three carefully tailored views.

‍

Your installer network depends on your support team when the manual doesn’t make the answer clear. You don’t control their training, but their questions still reach your desk. Chapter spent three years training installers before building software for them. That experience showed us the need for support beyond the classroom: help finding the right answer while the work is happening.

‍

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

‍

You operate across countries, with seasonal peaks. 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 this 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. 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 handles order status but struggles with product data because it's guessing from unstructured documents.

‍

So you build only the layer underneath it: structure hundreds of technical data points, add retrieval and hallucination checks, and keep the data 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 just sounds right.

‍

≈ €110K to build · ≈ €45K/year to run · ≈ 5 months to go 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, then owns all of it. Maintaining accuracy and governance realistically takes 2–3 FTE. Delivery risk stays with you.

‍

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

‍

Both estimates are midpoints, based on the fully loaded cost of 2 FTE for light DIY and 2.5 FTE for full DIY, plus tooling and infrastructure. Our figures, our assumptions. Swap in your own loaded cost per engineer for an even more fair comparison.

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 themselves: 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 needs a confidence score and approval from 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, as a GDPR erasure request requires.

‍

Verification the person asking can do in the moment. Every answer needs a citation to the document and page, so a technician can check it before acting. That's what turns an AI answer from a black box into something that can stand up to an engineer's scrutiny, an audit or a warranty claim.

‍

A way to know what it got wrong. Every system produces bad answers. The question is whether yours puts each failure in a tracked queue, with an owner and a count of how often the question has been asked.

‍

Three different failures need three different fixes: the knowledge was missing, the knowledge was there but the assistant handled it badly, or the evidence was too thin to support a conclusion. 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, especially the comment someone leaves with a thumbs down, is the fastest signal that something is wrong. 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. That set doubles as an evaluation set for the document: known questions, known source pages, expected answers.

‍

Those questions become scored tests. 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. Without it, you can't reliably measure whether a model upgrade helped or hurt.

‍

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

‍

‍How the year-one totals work

‍

‍The annual running costs show a full year of operation. The year-one totals include the build or setup plus the running costs allowed for that first year: approximately €25,000 for Light DIY, €20,000 for Full DIY and €20,712 for Chapter.

‍

The DIY totals therefore include partial-year running costs, while Chapter’s total includes a full year’s allowance. The DIY estimates assume 2 full-time employees for Light DIY and 2.5 for Full DIY, including employment costs, plus tooling and infrastructure.

‍

‍What does the Chapter estimate cover?An installation supporting internal staff, 50 new installers onboarding each year, around 200 active installers in the field, 20% of support calls deflected, and a public advisor on your website.

‍

That works out to roughly 2,950 answers a month. The first 1,500 are included; the remaining 1,450 are billed at the standard overage rate.

‍

Ongoing costs follow usage on a rate card. Lower usage means lower overage charges, with no per-seat fees to reconcile as your team or installer network grows. All costs and timelines shown are estimates.

‍

Including the initial build plus a full 12 months of running costs widens the gap further in favour of buying: approximately €155,000 for Light DIY and €400,000 for Full DIY, compared with €22,212 for Chapter. Beyond those costs, getting started sooner also has value: next, we’ll look at what Chapter’s roughly 3-week launch means compared with 5 months for Light DIY or 10 months to a stable Full DIY system.

Every month spent building is another month paying for the problem

Chapter goes live in two to four weeks. Building takes five to ten months. That gap has a cost: months of efficiency gains your team could already be benefiting from.

Our model assumes the same value once either option is live: roughly €53K a year, or €4,400 a month, in time savings and reduced support workload.

Across the two DIY scenarios, Chapter goes live around 6.5 months sooner on average. That means roughly €28K in benefits delayed by building, on top of the build cost.

You won’t find that figure in the project budget. You’ll find it in the hours your team still spends searching for answers, getting installers up to speed and handling support escalations while the build continues.

Where the risk sits

In field support, a wrong answer isn't like recommending the wrong movie. It's more like handing a technician the service manual for the wrong heating-system: the procedure may look relevant, but it applies to a different unit. That creates a safety risk and a warranty exposure, not just a poor customer experience. “Close enough” is fine for a movie recommendation. Not for a technician working on someone's heating system in winter.

Buying reduces the engineering and maintenance burden on your team. Chapter provides EU hosting, ISO 27001-certified security management and answers traceable to their sources. Our Trust Center details our security, privacy and compliance measures so your team can assess them against your requirements. You still own your technical content, access decisions and how the system is used.

‍

‍When you should build

‍

We'd rather you build than buy a platform that doesn't fit. Building is the right call in a few cases.

• Your scope is small and will stay small. One product family, one language, manuals revised once a year, only your own technicians asking. Forty PDFs and twelve engineers. Retrieval over one well-labelled folder handles that, until a second language, a variant that differs by one part number, or an installer network you never trained shows up.
• You already have a knowledge graph. Your products, parts, synonyms and procedures modelled as validated entities and relations, maintained by people whose job it is, with a release process when a model changes. That's the expensive part. A retrieval layer on top is a modest project. Most OEMs have PDFs, not a graph. If you have the graph, build.
• You have the engineers for three years, not a quarter. Someone re-ingests revised manuals and purges the old pages, updates every answer when a line moves to R290, re-runs the test set when your model provider retires a model, and finds last month's failed questions when fewer than one user in ten clicks a thumb. If you already run a model gateway and eval harness for other departments, that job is much cheaper. If those people exist and will still be there in 2029, build.
• You have a hard requirement no vendor can meet. A site network that never calls out. A contract that permits no third-party processor at all. A graph on your own schema the assistant must write back to. Fit on everything else doesn't count.

Wanting the assistant inside your own installer app or portal isn't on this list. An API does that, and you skip the three years of upkeep.

‍

If none of those describe you, your team can still build it. The question is whether you want their next three years spent keeping it current instead of on your products.

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. Using those files, the system has answered thousands of technical questions without passing them to a specialist, freeing up hundreds of hours for fieldwork. Think fewer interruptions at the technical desk, more time working on heating systems. Solvis forecasts that, as the system matures, up to 50% of questions could be answered without specialist involvement.

The practical value is getting a technician to the right procedure, with a source they can check, without interrupting a specialist. 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. Like a tool kept within reach rather than back at the depot, it needs to be available at the point of use.In the end, it's your call

Plenty of good engineering teams could build a knowledge layer for their products. The harder question is whether yours should spend the next three years maintaining one: structuring hundreds or thousands of technical data points, keeping product variants separate, re-ingesting revised manuals, filling knowledge gaps and checking that each change still produces reliable answers.

‍

The common questions are usually covered in the manuals. The complex ones consume your support team’s time: matching a procedure to the exact model, tracing compatibility across components or reconciling a service bulletin with an older installation guide. The system needs to connect that information, cite its sources and flag questions it cannot reliably answer.

‍

Building it yourself means maintaining those capabilities as your products and documentation change. Chapter provides and maintains that infrastructure, so your specialists can spend less time finding and cross-checking information and more time resolving complex cases.

‍

Whichever route you choose, ask one question first: which cases took your support team the most time last month, and how much of that time went into finding and cross-checking information before they could apply their expertise?

‍

‍See it running on your own documentation →