Why I keep my side of a vendor integration small
Adding an AI chatbot to a client's new website taught me to draw a clear line between our code and theirs, and to keep our side small.
5 min read
On a website rebuild for a national mortgage lender, one of my jobs was to add the company's AI chat assistant to the new site. Visitors use it to ask questions, and it can prepare documents for them to download. It had to load reliably, look right, and stay out of the way of everything else on the page.
The assistant came with more than a chat window. The team that runs it had built extra features around it: remembering a visitor's conversation as they move between pages, closing the chat after 30 minutes without activity, turning documents into downloads, and locking forms inside the chat once they have been answered, so nobody submits the same details twice. All of that lived in about 450 lines of their own JavaScript, the programming language behind interactive features in a web browser.
I was one of the front-end developers on a team drawn from several agencies, and getting all of this running on the new site was my task. The interesting part wasn't making the chat appear. It was deciding where the line between our code and theirs should sit.
The real decision was where their code should live
There were two ways to do it. We could bring the chat team's code into our own project and look after it ourselves, or we could load it straight from where they already hosted it.
The first option looks safer. Everything sits in one place, and you can see every line. But it quietly makes their code your responsibility. Every fix or feature they add has to be copied across by someone on your side, and if a conversation goes wrong, nobody can say quickly whether the fault is in their code or in your version of it. That is not a question you want to be asking while a customer is waiting.
The chat team already hosted their code online, next to the chat's stylesheet, as a file any website could load. So I loaded it from there, and wrote only the part that was genuinely ours.
Our side did four things, in a strict order
Check that the site has been given the chat's three web addresses: the assistant itself, its stylesheet and the chat team's file. If any is missing, show no chat at all rather than a broken one.
Load the chat provider's library, the core code that draws the chat window.
Only once that has finished, load the chat team's own file, because it depends on the library being there first.
Once both are ready, start the chat with the details for our site.
The order matters. Two files that depend on each other can finish downloading in either order, and if the second one runs first, it fails. Waiting for each step removes that guesswork.
Once the chat is running, our code has a small job. It remembers which conversation a visitor is in, using their browser's storage, and passes what happens in the chat, such as a new message or a document ready to download, to the chat team's code to handle. Our part came to about 80 lines. Everything else stayed with the people who know it best, and their improvements reach the site without anyone on our side touching it.
Protecting the site, and the chat, from each other
A website has several versions: one for testing and one that visitors see. Rather than writing the chat's web addresses into the code, I put them into settings, so each version could point to the right place. Leaving a setting empty switches the chat off cleanly in that version, which is useful while it is still being tested.
Chat tools also arrive with their own styling, and outside styles can quietly override a site's design. I loaded the chat's styles into what browsers call a layer, a way of telling the browser that one set of styles should always give way to another. Whatever the chat's styles say, the site's own design wins.
One thing I would change: the chat provider's library was loaded from a "latest version" link. That means a new release from the provider could change how the chat behaves on the site without anyone on the team deciding to update it. It is the one place where I left the line between us less clear than it should have been.
When someone else maintains the code, I connect to it rather than take it over, and I keep my side as small as the job allows.
What I do differently now
I load vendor code from where it is maintained: when a provider or another team hosts a file, the site loads it from them, so their fixes arrive without a new release of the website.
I agree where the line sits: I make it clear which parts are ours and which belong to the provider, so when something breaks, everyone knows who to call.
I make features fail cleanly: anything that depends on something else waits for it, and missing settings switch a feature off instead of leaving it half-working.
I pin versions and protect the design: I name an exact version of any outside library and update it on purpose, and outside styles always rank below the site's own.
For the technical side of this project, including the calculator and customer-review features I built, see [LINK: case study name].
