DEV Community: Mannat Trivedi

I Thought We Were Building a Chatbot. We Were Building Something Else.

Mannat Trivedi — Sun, 30 Aug 2026 07:50:03 +0000

The last few days, I have been thinking a lot about a project I built for SIH last year.

I remember feeling that there was still something in it. The project was done, the competition was over, but I never really felt that Meena had reached where she could go.

Maybe it was curiosity. Maybe it was the fact that AI had changed so much since we first built it.

Either way, I came back to it.

And once I did, I realised I didn't just want to improve the old project.

I wanted to rethink it.

The first thing we went back to was the design.

There is something slightly strange happening with AI products today. Everything is becoming beautifully polished, but at the same time, everything is starting to look familiar.

Similar gradients. Similar cards. Similar illustrations. Similar futuristic language.

Somewhere between making products clean and making them usable, we sometimes forget to make them feel like they belong somewhere.

So we started asking a different question.

What should Meena feel like?

We went back to our roots.

Not because we wanted to make an "Indian-themed AI", but because we wanted the product to have a story of its own. And our roots naturally took us towards Indian visual culture.

We started looking at colours that we have grown up seeing without really thinking about them.

Kesari.

The colour of saffron, associated with courage, sacrifice and spirituality. A colour that has existed in our visual language for centuries.

Sindoori.

That deep vermilion associated with auspiciousness, celebration and rituals.

And then neela, moving towards indigo and the deep blues that have their own history in Indian art, textiles and craft.

None of these colours were chosen because they looked "Indian" on a moodboard.

We spent time looking at where these colours came from, what they represented and how they could coexist in a modern interface.

Eventually, they came together as a gradient.

Not just a gradient for the sake of looking good, but a visual transition between things that already exist in our culture. Something warm, familiar and energetic, without making Meena feel old-fashioned.

Then came the question of who we were actually making this for.

Students.

And that made us look at our own college experience again.

The places we spend time in. The hostel. The chai. The little references that only make sense when you have actually lived there. The conversations that have nothing to do with an official college website but are a very real part of college life.

That is why the interface has things like Mata Mandir ki chai, hostel references and little pieces of campus life.

They are not there just to fill empty space.

They are there because we wanted Meena to feel like she knows the environment she is entering.

Friendly. Familiar. A little playful.

Something closer to a campus companion than a government portal with an AI box attached to it.

And somewhere in all of this, the circular mark became important too.

The logo is deliberately simple. A circle that feels complete, soft and approachable. We started thinking of it almost like a signature of trust. Something you recognise before you even read the name.

Because if Meena is supposed to become someone you come back to, the identity cannot just be decoration.

It has to become familiar.

But then we reached the uncomfortable part.

A beautiful product isn't enough.

The interface could look exactly how we wanted it to look and still fail the first time someone asked it a question it couldn't answer.

So we went back to the architecture.

The earlier Meena had a fairly straightforward embedding and retrieval pipeline. A document goes in, it gets embedded, we retrieve relevant chunks and give them to the model.

And it worked.

Actually, it worked pretty well.

But the more we tested it, the more we noticed a problem.

Relevant isn't always relevant enough.

A vector search can find something that is semantically close to the query, but the closest chunk isn't necessarily the best piece of evidence for the answer.

So we added another layer.

Reranking.

Jina became part of that pipeline because we wanted another stage between retrieval and the model. Instead of blindly passing the first few results forward, we could retrieve a wider set and then rank what actually deserved to reach the LLM.

That helped with something else too.

Context is expensive.

Every irrelevant chunk we send to a model is not just noise. It is tokens, latency and cost.

Then we looked back at the embeddings themselves.

We had experimented with lighter embedding approaches, including MiniLM, but as the requirements grew, they weren't giving us the representation quality we wanted.

So we moved towards Gemini embeddings.

One of the reasons that interested us was the multimodal direction and the research behind the embedding models. Meena isn't only going to live inside plain text. A campus is full of PDFs, images, notices and different forms of information.

The architecture needed to leave room for that.

Then we made another jump.

We gave Meena tools.

A knowledge base is useful, but the real world does not stop changing because your vector database hasn't been updated.

So we added web search.

Tavily became part of the tool layer, allowing Meena to go beyond what was already inside her knowledge base when necessary. The idea was simple: if the information is not available locally, she should have a way to look for it and ground the answer in something current.

But this is where building an AI agent became very different from building a RAG chatbot.

Once you give a model tools, you also give it the ability to make decisions about those tools.

Search.

Read.

Search again.

Try another source.

And sometimes...

Search again.

We ran into tool-calling chains and loops that looked completely reasonable from the model's perspective and completely ridiculous from ours.

This became one of the more interesting engineering problems in Meena.

We couldn't just tell the model, "please stop calling tools."

We needed the system around it to understand what was happening.

So we started putting boundaries around tool use. Maximum tool turns, fallbacks, different handling for different kinds of tools and a proper final synthesis step when the exploration had reached its limit.

The goal wasn't to make Meena magically perfect.

It was to make her fail gracefully.

If she found part of the answer, we wanted her to be able to use it.

If she couldn't find something, we didn't want her inventing it.

And if the model got stuck in a tool-calling loop, the application should be able to recover rather than simply falling over.

That last part exposed another problem.

We couldn't properly fix what we couldn't see.

With an LLM application, a normal application log saying "request failed" isn't particularly helpful.

We wanted to know what actually happened.

Which model call happened first?

What did it retrieve?

Which tool did the model choose?

What did the tool return?

Why did it call another tool?

How many turns had happened before the failure?

So we built our own lightweight observability layer rather than immediately reaching for a heavy framework.

It tracks the flow of the agent, the tool calls, retrieval behaviour and failures so that when something goes wrong, we can actually follow the path that led there.

That turned out to be one of those things that sounds boring until you need it.

And then, after all of this, we came back to the original question.

Why would someone use Meena every day?

Because if the answer is simply "she can find information about college," then honestly, that isn't enough anymore.

Google can find information.

AI search can find information.

Modern models can summarise information remarkably well.

But there is something those systems don't automatically have.

Your context.

Ask Meena:

"Kal college jaun ki nahi?"

That isn't really a search query.

The answer depends on who is asking.

Your timetable.

Your hostel.

What you are working towards.

What you have already told her.

The documents you have shared.

The things that matter to you.

That is why we are now working on user context and personalisation.

The idea is that your Meena should eventually be different from my Meena.

The underlying campus knowledge can be shared. The tools can be shared. The architecture can be shared.

But the context around the person using it should not have to be.

And that is probably where this project has changed the most for me.

We started with a campus assistant.

Then we built a better retrieval system.

Then we gave it tools.

Then we had to build an agent around those tools.

Then we had to build observability just to understand the agent we had built.

And now we are trying to make it understand the person sitting on the other side of the screen.

I don't think Meena is finished.

Actually, I think that is the interesting part.

We are still building her.

Integrating React and Vite: How It Boosted My Development Speed

Mannat Trivedi — Fri, 03 Jan 2025 16:05:08 +0000

As a web developer, I am always looking for tools that can boost my productivity and enhance my workflow. Recently, I started using Vite with React to build my portfolio, and I’m blown away by how much it has improved my development speed. If you're still using Webpack or other bundlers, here's why you should consider switching to Vite and how it can make a difference in your project.

What is Vite?
Vite is a modern build tool that leverages the power of ES modules to provide fast, optimized development experiences. It's extremely fast and efficient in terms of bundling and file transformation. Unlike traditional bundlers like Webpack, Vite provides lightning-fast hot module replacement (HMR), minimizing delays and making development smoother.

Why I Switched to Vite?
Before I started using Vite, I was primarily using Webpack with React, and though it worked fine, the speed wasn’t great, especially during hot-reloading or making changes that required a full rebuild. But Vite promises quick startup times and updates without rebuilding the entire project every time. The best part? No configuration needed! Vite works out of the box with React. Just install it, start developing, and let it handle everything.

Building My Portfolio with React & Vite
I decided to build my personal portfolio using React to showcase my projects, skills, and blog posts. It’s a responsive, modern website that represents me as a developer. The stack for my portfolio is very simple:

React for the front-end to build interactive UI components
Vite for blazing-fast bundling and development experience
I’ll explain how using Vite significantly improved my workflow in this project.

Getting Started with Vite & React
To get started, I simply created a new project using the following commands:

npm create vite@latest my-portfolio --template react
cd my-portfolio
npm install
npm run dev

As you can see, Vite made it extremely easy to set up a new React project, and the development server started instantly with zero configuration. From here, I was able to focus on building features, not spending time dealing with bundler setup.

Hot Module Replacement (HMR)
One of the best features of Vite is Hot Module Replacement (HMR). When I was making real-time changes to my portfolio, the components updated without refreshing the entire page, preserving the app’s state.

For example, when I edited a section of my portfolio (like changing a color or adding a new project), the changes immediately reflected on the page without requiring a full reload. This not only saved me time but also made my workflow much smoother, as there was zero downtime.

Fast Build and Instant Feedback
React + Vite allowed me to get instant feedback while developing. With Webpack, the initial build or bundling could take several seconds, and when you’re tweaking UI elements, every millisecond counts. Vite gave me a response in no time – this meant I was working faster and staying in the creative flow.

I noticed the reduction in build time especially when using libraries or CSS frameworks like Tailwind CSS. Unlike the typical bundling setup, Vite makes use of native ES modules, making it extremely fast in compiling changes without the heavy bundling process.

Faster Production Builds
Another benefit I experienced was in the production builds. When I needed to deploy my portfolio, Vite provided optimized builds that were not only smaller but also faster to load. Whether it was minification or lazy loading, Vite handled all optimizations with ease. I simply ran:

npm run build
And then deployed the static files – simple as that!

Example: My Portfolio
You can see the fruits of my hard work on my personal portfolio: My Portfolio. Built with React and Vite, it's responsive and dynamic, featuring multiple sections, smooth scrolling, and mobile-friendly UI. It provides a good overview of the projects I’ve worked on and allows visitors to interact with various components seamlessly.

How to Get Started with Vite & React
If you’re new to React or Vite and want to get started, here’s how:

Create your project:

npm create vite@latest my-react-app --template react
cd my-react-app
npm install

Start the development server:

npm run dev

Link a CDN: Vite will handle your CSS and JavaScript dependencies for you, but if you’re using external libraries (like fonts), you can include a CDN link in the head of your index.html.

Begin writing your app: Vite will automatically reload and give you instant feedback with HMR.

Conclusion
Using Vite in combination with React has definitely improved my development speed. The quick builds, no configuration, and fast hot-reload feature allow me to focus on writing meaningful code and designing rather than troubleshooting build tools.

I highly recommend trying out Vite if you’re looking to make your React projects faster, smoother, and more enjoyable. Trust me, once you start, you’ll never go back!

Why I Switched to Tailwind CSS and Never Going Back!

Mannat Trivedi — Fri, 03 Jan 2025 14:30:30 +0000

Learning web development has been an incredible journey for me. From HTML basics to structuring intricate layouts with CSS, it's been a rewarding experience. But the story took an exciting turn when I stumbled upon Tailwind CSS—a utility-first CSS framework that changed the game for me.

Discovering Tailwind CSS: A Game Changer

When I first encountered Tailwind CSS, I wasn’t sure if it would fit my workflow. It sounded different—utility classes instead of predefined components? However, as I dug deeper, it clicked! Instead of hopping between CSS files and HTML, Tailwind lets you directly style elements using concise utility classes, keeping everything inline and simple. It’s like writing clean, declarative style directly into the markup.

Here are a few reasons I fell in love with Tailwind CSS:

Efficiency: No more searching for or writing custom CSS from scratch. Tailwind’s utility classes are ready to go!
Customization: Tailwind lets you fully customize your design system without breaking a sweat.
Responsiveness: Building a mobile-first design? Tailwind simplifies responsive layouts with its intuitive breakpoints.
Integrated Workflow: Fonts, spacing, colors—all predefined. I said goodbye to downloading separate font files!

My First Tailwind Project: A Twitter (X) Clone

To see if the hype was real, I made my first project with Tailwind CSS: a responsive Twitter/X clone. I couldn’t believe how seamlessly the design came together. Tailwind made everything feel effortless, from crafting the layout to ensuring responsiveness on various devices.
🚀 Check it out here: Twitter Clone

Using Tailwind with React and Vite
Integrating Tailwind into React projects was another pleasant surprise! Pairing Tailwind with frameworks like React (and using Vite for blazing-fast builds) made styling components feel like second nature. Its ecosystem and documentation made it simple to get up and running, even as a beginner.

Want to Try Tailwind?
Getting started is easy:

Via CDN: Perfect for quickly experimenting. Just add this to your <head>:
html

<link href="https://cdn.jsdelivr.net/npm/tailwindcss@2.2.19/dist/tailwind.min.css" rel="stylesheet">

With a Build Tool: Follow the official Tailwind CSS docs for integrating it into your build pipeline.

If you haven’t tried Tailwind CSS yet, you’re missing out! For me, it's been transformative in how I approach and implement designs. Whether you’re starting a small project or diving into full-stack development, give Tailwind CSS a shot—it might just become your favorite tool! 🚀