A European team AI chat provider
Team AI chat moved onto current open source, every custom feature kept
A European provider of team AI chat ran its admin dashboard and multi-user chat on an outdated open source fork tied to one AI provider. We compared the code before quoting, moved every custom feature first, then built on a current base in the client's own cloud.
B2B SoftwareMulti-model team AI chatAI added to a live product
- Base
- Outdated open source fork moved to a current release
- Kept
- Admin dashboard and multi-user live chat
- Models
- Many providers behind one separate gateway
- Runs in
- Dev and production in the client's own cloud
The challenge
The product's admin dashboard and multi-user chat sat on an old fork of an open source chat framework. Upstream had moved on, and the product spoke to only one AI provider.
What we did
We compared the fork with upstream before quoting, moved every custom feature onto a current release, took model routing out into its own service and shipped it in the client's cloud.
The outcome
The client kept every custom feature on a base it can keep upgrading, gained a gateway open to more AI providers and got automated deploys to dev and production.
The starting point
The client offers a team AI chat web app built on a fork of an open source chat framework that looks and works much like ChatGPT. Companies use it as one shared AI workspace with an admin dashboard for users, usage, model choice and company settings, and beta testers were already on it.
What had to change
The client's custom features sat on an outdated base while upstream had changed a great deal. The team could not take upstream fixes or new features without porting its own work, and it needed hosting, automated deployment and more models than its one provider.
What could not break
- Every custom feature survives the move: admin dashboard, multi-user chat, model choice
- All work stays in the client's own cloud accounts and repository
- The redesign follows the client's own designers and their files
- Answers stream to the browser and larger uploads go through in production
The calls we made
We treated it as a migration first and a feature project second, because every new feature added to an outdated fork would make the next upgrade harder.
- 01
Read the code before quoting
We compared the client's fork against its base and against the latest upstream release, and walked the founder through the changes on video, so he saw the real scope before choosing us.
Ruled outA quote from a feature list alone, which would have hidden how far upstream had moved.
- 02
Migrate first, then add features
Bringing the custom work onto a current release first meant each new feature was built once, on a base the client can keep upgrading.
Ruled outAdding hosting and new features on the old fork and upgrading later.
- 03
Take model routing out of the app
Model routing was built into the app and spoke to only one provider, while upstream recommends a separate service. Running the gateway on its own opened the product to many model providers.
Ruled outKeeping the embedded gateway, which tied the product to one provider and worked against upstream.
- 04
On the client's cloud from day one
The current release ran on the client's own cloud for review before the statement of work was signed, and dev and production followed in the same account.
Ruled outBuilding on our own servers and moving to the client's cloud at handover.
- 05
Design from the client's own designers
We sent two quick design directions, then the client chose to keep its own designers, so we built the new front end from their designs instead of a parallel design track.
Ruled outTwo design teams working on one interface at the same time.
How the system fits together
What we built
The migrated product
The client's fork moved onto a current upstream release with its admin dashboard (user management, usage overview, model selection, company settings) and live multi-user chats intact.
Many models, one gateway
Model routing runs as its own service in front of the original provider and others, and a prompt helper suggests better prompts.
Workspace features
Cloud storage integrations, an email opt-out in the admin dashboard and an automatic email flow with dynamic templates, triggered by actions and criteria the client defined.
Redesign from the client's designs
A new front end built from the client's own designs, clean and minimal and close to ChatGPT, with light and dark modes.
Production hosting
Dev and production environments in a cloud account the client owns, set up for streamed answers and larger uploads, with automated deployment.
How it works
Open a chat
Team members work in one shared workspace, alone or in multi-user chats that update live.
Set the rules
The company admin manages users, sees usage and chooses which models the team can use.
Route the request
Each request goes through the separate gateway to a provider the admin allowed.
Stream the answer
The answer streams straight to the browser, so replies appear as they are written.
Follow up by email
The automatic email flow sends messages from dynamic templates, such as usage summaries.
A closer look
What changed
The client came out with every custom feature on a current open source base it can keep upgrading, a gateway that opens the product to more AI providers, and dev and production with automated deploys in its own cloud. The project closed as complete, with documentation as the final handover.
Under the hood
- Datics role
- AI added to a live product
- Model gateway
- A separate routing service in front of the original AI provider and others, so adding a model does not mean changing the app.
- Live chat
- Multi-user chats and answers that stream to the browser as they are written.
- Integrations
- Cloud storage for files, and automatic emails from dynamic templates.
- Deployment
- A client-owned cloud account with separate dev and production environments and automated deploys, moved to a European region at the client's request.
Also in the stack
How it shipped
Code comparison and scope
We compared the fork with its base and the latest upstream release, walked the founder through the changes and split the work into three milestones.
Migration and core features
A current release running on the client's cloud for review, then the admin dashboard, multi-user chat, the separate model gateway, prompt help, email and cloud storage.
Redesign and admin updates
The new front end from the client's designs and updates to the admin dashboard.
Hosting, deploys and email flow
Dev and production environments, automated deploys and the automatic email flow, followed by operations work such as a move to a European region at the client's request.
In the client's own accounts
We worked in the client's repository and in a cloud account dedicated to the product, and moved the servers to a European region when the client asked.
Reviewed live, then twice a week
The current release ran on the client's cloud for review before the statement of work was signed, and later work was walked through with the founder twice a week.
Scope that grew with the product
The client added requests beyond the original statement of work as the product took shape, and we scoped each one on its own before it joined the plan.
What this unlocked
With the product on a current base, the client scoped new AI features on top of it with us: a financial advisor widget using retrieval and a voice-capable sales agent chatbot.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.