A Quick Recap

In one of my previous blog posts, Until AI Do Us Part, I discussed the business case. Read it to understand the domain we operated in, and to get some insight into the scope of the project. In another blog post, Retrieve Fast, Save Time, I delved into more technical details on how the tech stack and setup of this RAG chatbot would take form. I will be getting into more technical details later in this post, but if you would like a primer, I encourage you to skim it.

So here is the deal: My classmate and I set out to build a RAG chatbot for a real client. The caveat was that it did not have to be deployed, and our primary goal was simply the learning experience along the way. Our teacher only gave us a few pointers on vibe-coding fundamentals; beyond that, we were left to our own devices. This meant our teacher had no say in the final product we wanted to build. It was entirely up to us.

What about the why? We knew it had to be an MVP due to the tight time constraints of the project. As a personal requirement, I wanted to build something that was more than just a gimmick. I wanted a system that could actually provide real, tangible value.

So this is what we built: A chatbot that can upload files in almost any format (.xlsx, .pdf, .csv, .docx, and so on) directly from the UI. It has an AI that helps label and document the files, sorting them into General or Q&A channels for the Dify.ai pipeline. It retrieves information with high accuracy, listing up to four sources because we set the Top-K parameter to 4. It displays a portion of any given document source on the right side of the window, providing contextual highlights via regex mapping. Finally, every time the AI responds, another background AI call is initiated to analyze the current chat window context and suggest four relevant follow-up questions, making the button pulse gold when the suggestions are ready. Krone Gods Portal Interface (Krone Gods RAG UI - Screenshot, retrieved 2026-05-27)

How It Works

Our system relies on three essential API channels working in absolute harmony:

Dify Datasets (Knowledge Base) API: Allows staff to drag-and-drop files of any kind containing, for example, inventory spreadsheets of linens, glasses, and furniture. This API call makes it possible to bypass the Dify.ai platform and create an intuitive UI for persisting data into the Dify RAG pipeline.

Krone Gods Drag and Drop Upload Interface (The estate management document upload panel, allowing administrators to drag-and-drop spreadsheets and documents directly into the RAG pipeline - Screenshot, retrieved 2026-05-27)

Dify Chat Messages API: Sends the user's question, performs a semantic lookup on the dataset vectors, gathers the matching rows, and passes them to the LLM to generate a natural response.
OpenRouter API (qwen/qwen3.6-flash): Serves as a fast gateway to the open-source qwen3.6-flash model. We use this to synthesize interactive follow-up questions in the background without blocking the main chat response.

Krone Gods Dynamic Follow-Up Question Suggestions (Dynamic follow-up questions generated asynchronously in the background by Qwen-3.6-Flash based on the active conversation context - Screenshot, retrieved 2026-05-27)

Krone Gods Active Chat Interface (The Krone Gods chat UI in action, showing a detailed multilingual query response from the Dify Chat Messages API alongside highlighted source references - Screenshot, retrieved 2026-05-27)

A logistics tool is only as good as its reliability. When a staff member queries the system, the Dify Chat API returns the final plain-language response along with the exact source text blocks used to generate it.

Think of our interface as a digital butler standing between the estate owners and the raw AI networks. Because our app runs completely inside the browser without a separate backend server, the frontend code has to do all the heavy lifting. It acts as a wrapper that forces these three separate API channels to behave like a single team.

Instead of forcing a busy manager to navigate complex settings or fix messy formatting, the website acts like a central air traffic controller. The moment you upload a file or type a question, the code instantly intercepts your action. It quietly extracts the required text, packages it into clean data, and sends it to the exact right database or model. The user gets a clean, frictionless experience while the interface manages the chaos of juggling multiple APIs in the background.

Dify Technical Details

I have now talked a bit about the UI harness and the API calls from it. Although I have mentioned Dify in all posts related to RAG, I would like to dive deeper into what it actually does, what problem it solves, and how we have actually set it up.

Essentially, Dify is a development platform for creating custom chatbots with specialized knowledge. It gives you a drag-and-drop interface where you can no-code the entire chatbot pipeline, right from the first user prompt down to the final LLM answer. It gives you options such as providing a system prompt, one or more places to retrieve information from, an initial greeting message, plugins, and so on. Take a look below to see what I mean.

Dify.ai Chatbot Pipeline Configuration (The drag-and-drop workflow visual builder inside Dify.ai, showing how system prompts, knowledge retrievals, and LLM nodes connect to synthesize responses - Screenshot, retrieved 2026-05-27)

So, Dify provides us with the workflow in an intuitive manner. It provides us with a vector database, meaning that chunks of data have been clumped together based on semantic meaning. Finally, it also provides us with a harness for 'the brain' LLM (including the system prompt and additional features you can toggle on or off, as discussed earlier).

To make this experience easier from a developer standpoint, we used OpenRouter. It's a service that provides you with over 400 AI models that you can access using a single API key. This makes it a one-click process to switch to a different model provider based on business parameters such as speed, pricing, privacy, and so on.

OpenRouter Models Hub Interface (The OpenRouter model library inside Dify, offering unified API access to a wide array of proprietary and open-source models - Screenshot, retrieved 2026-05-27)

Here is a look at how the retrieval pipeline is configured to keep our context accurate:

Dify.ai Dataset Retrieval Settings (The indexing and search configuration panel in Dify.ai, detailing the Hybrid Search weighted parameters and Top-K context setup - Screenshot, retrieved 2026-05-27)

To guarantee the highest possible data precision, we opted for the High Quality indexing method, pairing it with OpenAI’s text-embedding-3-large embedding model to generate high-entropy vector representations of our data. For the actual query execution, a Hybrid Search setting handles the heavy lifting by running semantic vector searches and traditional full-text searches simultaneously. Instead of routing through an external Rerank model, we handle the synthesis using a custom Weighted Score. This is configured with a 0.6 weight for Semantic depth and a 0.4 weight for Keyword matches, ensuring the system values conceptual meaning while keeping a strong anchor to exact terminology. Finally, the Top K is set to pull exactly 4 data chunks into the prompt context window, with the Score Threshold left completely open to prevent any subtle but necessary context from being filtered out prematurely.

Limitations

The Client-Side Security Bottleneck

Because our application architecture communicates directly with external APIs right from the browser, all our secret environment keys are exposed inside the client bundle. Anyone opening a standard browser developer console can pull our active Dify and OpenRouter authentication tokens straight from the network traffic.

Moving this tool to a production environment would require a complete network rewrite to route our queries through a secure serverless proxy, keeping our API credentials safely server-side.

The Data Discipline Void

Our focus on an ultra-minimal workspace also means our database architecture is completely additive and highly dependent on human data discipline. The custom interface contains no file deletion dashboard or automated spreadsheet formatting engines to clean up broken layouts before ingestion.

If a user accidentally uploads a duplicate sheet or a supplier file with poorly structured columns, the specialized row-by-row processor will index the inventory counts incorrectly. Because the custom UI lacks a delete button, fixing an uploaded error forces an administrator to manually log into the central Dify cloud platform to prune the dataset chunks by hand.

The Trust and Vibe-Coding Trade-off

Building an application under a rapid prototyping model means that we relied heavily on vibe-coding with AI agents. To let these agents work quickly across the codebase, we frequently exposed our active configuration files to external systems, resulting in large blocks of generated code that have never been thoroughly reviewed by human eyes.

Beyond the unverified codebase, introducing an actual deployment brings massive GDPR compliance headaches. If this tool were to go live, handing over sensitive supplier contracts, proprietary pricing buffers, and private customer information to third-party endpoints like Dify or OpenRouter presents a huge risk.

In the end, the real operational bottleneck for an enterprise app isn't the rapid pace of vibe-coding, but rather the structural challenge of trusting outsourced resources and opaque AI model providers with confidential data.

Data Integrity In A Real World Scenario

The Legal and Compliance Reality

When you look past the immediate speed of a rapid prototype, deploying a tool like this into production completely changes the game. Data integrity is no longer just about preventing a language model from hallucinating inventory counts.

It becomes a strict legal mandate to protect the private inquiries, financial terms, and custom contracts belonging to the customer's customer. Relying on convenient out-of-the-box dependencies like Dify and OpenRouter introduces serious abstraction layers. Under European GDPR rules, every layer is a hidden data junction that complicates compliance and increases exposure risks.

The Geopolitical Stack Split

This technical framework drops our stack right into the geopolitical crossfire between the United States and China. To deliver answers, our browser harness coordinates a delicate mix of Western models like OpenAI’s large embeddings alongside Eastern open-weights models like Qwen-3.6-Flash.

If this tool went live, a business would face a classic case of choosing the devil you know. Operators are forced to decide whether to leave their sensitive operational intelligence inside US cloud monitoring frameworks or funnel queries through cheap, hyper-efficient Eastern infrastructure.

The Path to Data Sovereignty

Ultimately, these structural privacy challenges are far too massive for any one developer to tackle in a client-side codebase. Escaping this cycle of digital dependence is not a coding problem.

True data sovereignty requires dedicated political will at the national level and an investor ecosystem willing to finance local, secure infrastructure. Until regional alternatives exist, small businesses remain structurally dependent on outsourced AI utilities, proving that scaling past a prototype is an infrastructural hurdle rather than a technical one.

Reflections For The Future

While it has been fun to just sit back, relax and vibe-code away, it's important to look back. It feels easy to ask OpenAI's new image model to generate an image of a mock-up design interface. Because it is easy, it is convincing enough that you might actually choose to implement the design. Don't believe me? Take a look yourself:

ChatGPT Generated UI Draft (An early interactive UI draft generated by ChatGPT during our visual planning phase to explore layout structures - Screenshot, retrieved 2026-05-27)

Sure, it also feels amazingly easy and blazingly fast to prompt a feature request and see it get implemented within minutes by the new Antigravity 2.0 powered by Gemini 3.5 Flash. It is incredibly easy, and it is very fast.

So where does that leave us? We certainly can't snap our fingers and make the current state of AI models worse at coding. Nor can we as developers slow down the rapid progress being made in the AI space as of 2026 and the rest of this decade. However, we don't have to frame this as something negative, but rather see it as an evolution of the craft and the entire developer domain.

It is no longer the coding skill that defines us, but rather our ability to understand the customer, understand the customer's customers, and break down a big ask into smaller tasks. Our job is to scope and adjust as the business case evolves. We should definitely still understand what makes a good design, but we no longer have to imagine it from thin air.

Vibe-coding, custom RAG bots, databases, and backends for your MVP; all of this costs actual money, so of course it has to be budgeted. The gimmick of generating four questions every time the RAG bot responds is a big waste. If it were deployed to a larger market, it would get really expensive, really fast. It is a significant waste of money and compute resources for something that doesn't necessarily provide a lot of value.

I'll leave you with this anecdote. Perhaps you remember some years back, Air Fryers were all the rage. Visiting a friend's house, they offered me some food, and when I mentioned how amazing it tasted, they laughed: "Thanks, man. Yeah, I just got this Air Fryer the other day, I don't even really know how to cook."

Essentially, if you talked about anything food-related, someone would bring up the Air Fryer. Sure enough, as they got more accessible and cheaper, you had this little square box on the kitchen counter in every single home.

No one ever talked about how hard it was to clean, or how small it was. What if you had many guests come over? Maybe you had multiple Air Fryers running concurrently, each making their own dish, like a team of AI agents working in parallel.

My point is this: yes, Air Fryers are amazing, and they made cooking easy and available for everyone. But they have limitations, and sometimes you might even just use your regular oven. In any case, a cheap Air Fryer without paying for high-quality raw materials is just a cheap meal, and yes, sometimes that's good enough.

Cookie Ingredient

Blog