FLZR
Shoppers compare products side by side, answered from the seller's live database
FLZR, a Berlin sales services company, wanted shoppers' product questions answered at any hour from data it already keeps. Our assistant reads documents, CSV files and live database tables in one pass and answers with comparison cards, not paragraphs.
Retail & E-commerceAI sales assistantBuilt from zero
The challenge
Shoppers needed product answers and comparisons at any hour, while the product data sat in documents, web pages, CSV files and the client's own database.
What we did
An AI sales assistant whose LangGraph flow searches every source in parallel, merges the results and returns tables and comparison cards in a website widget.
The outcome
We delivered every item in the MVP scope, including product comparisons and voice input, deployed over SSL with a recorded product demo.
- MVP scope
- Every scoped item delivered and deployed
- Answers from
- Documents, web pages, CSV files and a live database
- Database access
- Only the tables or SQL views an admin selects
- Answer formats
- Streamed text, tables, feature and comparison cards
The starting point
FLZR is a Berlin company that runs point of sale sales services. It asked us to build a new product: an AI sales assistant that organizations embed on their own websites for shoppers. The client already kept its product data in its own databases, and the assistant had to read it there.
What had to change
Product questions needed answers at any hour, including live comparisons between products. The data was spread across documents, web pages, CSV files and the client's database, and a single answer had to combine them.
What could not break
- Answers come only from the documents, URLs, CSV files and database each chatbot is given
- The assistant reads only the database tables or SQL views an admin selects
- Long conversations keep their context without the cost growing with every message
- Adding new knowledge never slows a live conversation
- Voice input needs HTTPS, so frontend and backend run over SSL
The calls we made
We framed the assistant as a reader of the client's data where it already lives, scoped by the admin, with answers designed for a sales widget rather than a chat transcript.
- 01
Read every source in parallel, then merge
A LangGraph flow rephrases the question with the conversation so far, then searches document embeddings, runs CSV agents and queries the client's database at the same time, and an aggregator node merges the results into one answer.
- 02
Let admins choose what the assistant reads
An admin connects a MySQL or PostgreSQL database, the connection is validated first, and then the admin selects tables or writes an SQL query that defines a custom view. The assistant reads only that.
- 03
Comparisons as components, not paragraphs
Pydantic models make the model return tables, feature cards and comparison cards that the widget renders as they stream in, so a shopper sees products side by side.
- 04
Summarize long chats to hold the cost
Each conversation keeps its own memory by thread, and a summary node condenses the history, so context carries forward without the cost growing with every message.
- 05
Ingest in the background
Document uploads are processed in the background on Celery and RabbitMQ, outside the chat path, so adding knowledge never slows a live conversation.
How the system fits together
What we built
Source refresh alerts
Notifications remind organization admins to refresh a document, link or database a chatbot answers from.
Conversation engine
A Python FastAPI service runs a LangGraph flow that rephrases each question, keeps memory per conversation thread, condenses long histories in a summary node and streams the reply as it is written.
Multi source retrieval
Vector search over documents and web pages, CSV agents for tabular files and a validated connection to the tables or SQL views an admin selected run in parallel, and an aggregator node merges them into one answer.
Comparison answers
Pydantic models shape the reply into tables, feature cards and comparison cards, and database rows and CSV data are merged in one card, so a shopper sees products side by side with their key differences.
Website widget
An embed script puts the assistant on any website, with a pre chat form, quick prompts, voice input and a test chat inside the setup flow.
How it works
Ask
A shopper types or speaks a product question in the widget on the seller's website.
Rephrase
The flow rewrites the question using the conversation so far, kept in memory for that thread.
Retrieve
Documents, web pages, CSV files and the client's database are searched in parallel, then merged by an aggregator node.
Answer
The reply streams back as text, a table, a feature card or a comparison card.
Hand off
If the attached knowledge does not cover the question, the chat goes to a human sales agent.
A closer look
What changed
We delivered every item in the MVP scope, from product comparisons and voice input to chat with an agent, deployed over SSL with a recorded product demo. The client then reviewed it with us in a feedback session.
- Every scoped item delivered
- MVP scope
- Deployed over SSL, with a product demo video
- Delivery
Under the hood
- Datics role
- Product built by Datics
- AI service
- Python FastAPI with a LangGraph flow: query rephrasing, memory per thread, a summary node, parallel retrieval with an aggregator node, live streaming and structured output through Pydantic models.
- Data boundary
- Each chatbot answers only from the knowledge bases its organization admin attaches, and from a database only through the tables or SQL views the admin selected after the connection was validated.
- Processing
- Celery and RabbitMQ process document uploads in the background, an embeddings API feeds vector search, and AWS S3 stores media.
- Deployment
- Frontend and backend served over SSL, which voice input requires, on a temporary subdomain ready to move to the client's own, with a separate dev environment.
AI and models
Apps and APIs
Also in the stack
How it shipped
Scoping and design
A proposal and feature breakdown, wireframes for all four roles walked through with the client, Figma designs, user stories, a system flow chart and a session on database connectivity, then the client confirmed the build.
Platform sprints
Sprints built the schema and access control, chatbot and knowledge base management with database connections, the FastAPI AI service with background processing, and the inbox, with an early dev server deployment.
Shopper features and AI engineering
Quick prompts, product comparisons, voice input and chat with an agent came next, then work on the conversation flow, streaming, structured output and the embed widget, with regression testing and a recorded demo.
Regression sprint and delivery
A final sprint of regression fixes, delivery of the full MVP scope over SSL and a feedback session with the client.
Database connectivity settled early
Before the designs were final, we held a dedicated session with the client on connecting its own databases, then wrote the connection, validation and preview flow as user stories.
Every release evaluated
Every deployment was evaluated against the user stories, with negative queries tested and tracked as bugs, and we reviewed progress with the client weekly.
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.