I thought building an AI stylist would be about prompts.

It wasn't.

When I started VibeFit, I assumed most of my time would go into prompt engineering.

Instead, I spent far more time designing workflows, validating AI responses, building retrieval pipelines and thinking about system reliability.

That completely changed the way I think about AI engineering.

Today, VibeFit is much more than an application that recommends outfits. It's an end-to-end AI system that understands a user's wardrobe, stores it as semantic knowledge and retrieves only the relevant clothing before asking an LLM to generate recommendations.

This article is a walkthrough of how I designed that system and the engineering decisions that shaped it.

What is VibeFit?

VibeFit is an AI-powered wardrobe assistant.

Users upload images of their clothing, and the system automatically understands each item using Gemini Vision. It extracts structured metadata such as category, color, fabric, season and occasion, generates semantic embeddings and stores everything in PostgreSQL using pgvector.

Later, when a user asks something like:

"What should I wear for a client meeting?"

the application doesn't send the entire wardrobe to Gemini.

Instead, it retrieves only the most relevant garments using semantic search and lets Gemini reason over that much smaller context.

That one architectural decision significantly improved recommendation quality while reducing hallucinations and token usage.

System Architecture

The application consists of two independent AI pipelines.

1. Ingestion Pipeline

Runs once for every uploaded clothing item.

The goal of this pipeline is simple.

Convert an uploaded image into structured, searchable knowledge.

2. Retrieval Pipeline

Runs whenever a recommendation is requested.

Instead of asking the LLM to search hundreds of clothing items, the retrieval system performs that work first.

Gemini only focuses on reasoning.

Engineering Decisions That Made the Biggest Difference Migrating from n8n to LangGraph

The first version of VibeFit was built in n8n.

It helped me validate the product quickly, but as the workflow became more complex, I started needing shared state, retries and conditional routing.

That's when I migrated the orchestration to LangGraph.

Instead of designing connected nodes, I started designing state transitions. Every node became responsible for a single task, while the graph handled execution.

It made the workflow much easier to maintain and extend.

Structured Outputs Are Only Half the Story

One lesson I learned early is that valid JSON doesn't always mean valid data.

Gemini generates structured metadata using a predefined schema, but that alone isn't enough.

After parsing the response, I validate it against my own business rules before storing anything in the database.

The AI generates data.

The application decides whether that data can be trusted.

Why I Didn't Generate Embeddings from Images

Most people assume image search starts with image embeddings.

In VibeFit, I take a different approach.

Gemini first converts the image into structured metadata. That metadata is transformed into a descriptive sentence, and only then do I generate embeddings.

Users search with intent, not pixels.

Representing the clothing semantically produced much better retrieval quality than relying only on visual similarity.

PostgreSQL + pgvector Instead of Pinecone

Introducing another database would have added complexity without solving a real problem.

Every clothing item already had relational data like category, image URL and ownership. Keeping metadata and embeddings together inside PostgreSQL made the architecture simpler while still providing fast semantic search.

For the current scale, pgvector was the right tradeoff.

What This Project Taught Me

Before building VibeFit, I thought AI engineering was mostly about choosing models and writing prompts.

Today, I think it's mostly software engineering.

The quality of the system depends on validation, retrieval, orchestration and reliability far more than it depends on clever prompts.

A good AI application isn't the one with the smartest model.

It's the one that gives the model exactly the information it needs and nothing more.

That shift in thinking changed the way I approach every AI project.

What's Next?

There are several improvements I'd like to make as the project evolves.

Introduce a message queue for asynchronous processing. Add hybrid search and reranking. Version prompts and evaluate retrieval quality. Improve observability with tracing and workflow metrics. Introduce confidence scoring and recommendation validation.

The current architecture solves today's problems, but it's designed in a way that can evolve as the application grows.

Resources

🚀 Live Demo: https://vibe-fit-blond.vercel.app/

💻 GitHub: https://github.com/Ankita-Nandkumar-Patil/vibefit

🎥 Loom Walkthrough: https://www.loom.com/share/552e8099b6594e9685ce440ce8194865

🌐 Detailed Architecture: https://ankitapatil.dev/project-listing/vibe-fit

Final Thoughts

Building VibeFit taught me something I didn't expect.

The LLM is probably the least interesting part of the application.

The interesting engineering happens everywhere around it.

Designing reliable workflows, validating probabilistic outputs, building semantic retrieval and making different components work together is what turns an AI demo into an AI system.

That's the part of AI engineering I enjoy the most.

Here is the technical breakdown of how I’m running Gemma 4 on a constrained system to own my entire development lifecycle.

The Stack: Why Gemma 4?

I chose Gemma 4 as the primary driver for its logic-to-weight ratio. While Qwen 3 is a solid backup for multilingual reasoning, Gemma 4 hits the sweet spot for React/Next.js code generation and complex system architecture.

• Privacy: Zero data leakage.

• Latency: Sub-millisecond response times.

• Context: No more worrying about token costs while debugging heavy repos.

Hardware vs. Tooling: Ollama or LM Studio?

The choice of engine depends entirely on your system's "personality."

Since I prioritize a minimalist, CLI-driven workflow, I went with Ollama. It keeps my system resources lean while serving the model as a local endpoint.

The Workflow: Aider + Local LLM

Aider is the bridge that makes local AI feel like a superpower. It’s an autonomous terminal tool that treats your local model like a senior pair programmer.

1. Orchestration: Point Aider to your local Ollama port.

2. Execution: Ask for feature updates directly in the terminal.

3. Result: Gemma 4 processes the intent, and Aider applies the git-aware edits to your code.

The 8GB RAM Constraint: Quantization is Key

Running a 2026-tier model on 8GB of RAM is an exercise in optimization. To keep the machine from swapping to disk, I used 4-bit quantization. This reduces the memory footprint by over 60% with negligible loss in coding accuracy.

The Technical Implementation

Fire up the Engine (Ollama)

Once the app is installed, pull the specific model version. I suggest starting with the 4-bit quantized version to save your RAM.

PowerShell

#Pull the model to your local library

ollama pull gemma4:4b

#Run and verify the model is active

ollama run gemma4:4b

The Aider Integration

Aider needs to know where your local "brain" is living. Since Ollama serves models on port 11434 by default, we point Aider there.

PowerShell

#Install Aider in your project environment

pip install aider-chat

#Launch Aider pointing to your local Gemma instance

aider --model ollama/gemma4

Memory Management (The 8GB Survival Script)

If your system is struggling, you can check exactly what is eating your memory before you start. I use a quick one-liner to find and kill heavy processes that aren't needed for the current build.

PowerShell

#Check for the top 5 memory hogs

ps | sort –p ws | select –last 5

Pro-tip: Kill your Docker containers and heavy browser caches before starting a long inference session. Every megabyte counts when you're running the brain and the dev server on the same chip.

I have been working on a project that will match the vibe and not the stress. As a product engineer I set one rule for VibeFit: if user have to type "Yellow", "Cotton", or "Summer" , I've failed. In 2026 we don't build CRUD apps for users to deal with same stress on screen that they already bear off screen, instead we build intent-based engines.

Orchestrating the invisible:

Most devs go for monolith Express server to handle AI logic. But in AI driven product, your backend is the logic glue, it's not just a gatekeeper for a DB.

I chose n8n orchestration, and here's the engineering reality:

• Observability over black box code: We've been developing the apps by checking logs and debuggers, and it do take time. When Gemini return a JSON object wrapped in markdown, I don't want to go through the logs, I want to see exactly where the pipe leaked on a visual canvas.

• Decoupling the Stylist: My Next.Js frontend should not care about how Gemini-2.5 Flash tags a photo. So I offloaded this to keep the Main Thread Lean, focusing on premium UX.

fig: The VibeFit Ingestion Pipeline: Turning raw pixels into structured semantic data.

The classic Latency Tax:
Most AI products break (right at the UX), when you upload a photo, and the app shows a spinner for 8 seconds while the AI is thinking. For VibeFit I decided to treat this AI Thinking as a background task, and named it Shadow Ingestion.

How exactly Shadow Ingestion works:

1. The handshake: User uploads the image and UI returns a "Success" state in <200ms.

2. The Background task: An n8n webhook takes the image, hits Gemini 2.5 Flash for visual tagging, and OpenAI for a 1536-dimension embedding.

3. The Reveal: As soon as background processing is done, the database updates, and the item is shown into the wardrobe via a Supabase real-time subscription.

The user thinks its magic. The reality is just asynchronous orchestration hygiene.

The bottom line: AI product is only as good as its data glue. With manual ingestion, your app is already dead, no matter how better the ui/ux is. By automating the extraction of vibes and not just categories, I've built the foundation for a true RAG experience.

Next in the series: The Math of Style: Why I chose pgvector for 1536-dimension similarity matching.

Most devs look at their React code or their Tailwind classes. They’re looking in the wrong place.

The problem isn't your UI library. The problem is that you’re Microtask-smothering your browser.

The 2026 Conundrum: The "Infinite" VIP Line

In the "classic" web, we had a few promises here and there. In 2026, we have Streams.

Every time your AI agent emits a token, or your local vector DB returns a similarity match, you’re likely firing a Promise.resolve() or an await. In JavaScript land, these are Microtasks.

Here’s the dirty secret: The Event Loop is a pushover. It sees a Microtask and says, "Come right in, VIP!" The problem? If your AI is streaming 60 tokens per second and you’re updating state for every single one, that "VIP line" never ends.

The browser wants to paint the next frame (the Macrotask). It’s literally begging to show the user the scroll animation. But the Event Loop says, "Sorry, I have 400 more microtasks to finish first."

Why setTimeout is Obsolete

For years, we "fixed" this by throwing a setTimeout(fn, 0) into the loop. It worked, but it was a blunt instrument. It forced the continuation to the back of the entire macrotask queue, losing its priority context.

In 2026, we use the Prioritized Task Scheduling API.

await scheduler.yield() is the surgical way to breathe. Unlike setTimeout, it yields to the browser to let it paint, but then it picks your task back up with the same priority it had before. You get the fluidity of a paint-cycle without the overhead of re-queuing from scratch.

Defending the INP (Interaction to Next Paint)

If you’re building a Product, you aren't just "writing code"—you're managing Interaction to Next Paint (INP).

If your AI loop consumes the thread for more than 50ms, your INP is going to blow past the 200ms "Good" threshold. You might think your app is fast because the tokens are appearing, but your user thinks it's broken because they can't click "Settings" while the AI is talking.

Main Thread Hygiene is the new performance frontier.

JavaScript

// Don't just loop. Orchestrate.
async function processAIStream(stream) {
  let lastYield = performance.now();

  for await (const token of stream) {
    updateUI(token);

    // If we've been working too long (50ms+), 
    // give the browser a chance to paint and handle user clicks.
    if (performance.now() - lastYield > 50) {
      // The 2026 approach: Yield while maintaining priority
      if (typeof scheduler !== 'undefined' && scheduler.yield) {
        await scheduler.yield();
      } else {
        // Fallback for older environments
        await new Promise(resolve => setTimeout(resolve, 0));
      }
      lastYield = performance.now();
    }
  }
}

The Bottom Line

In an era where AI can write the logic for you, your value as an engineer isn't in writing the loop—it's in orchestrating the execution. If you can't keep your INP under 200ms while running a local LLM or a heavy stream, you aren't building a 2026 product; you’re building a legacy site with a modern coat of paint.

Stop treating the Event Loop like a black box. Start yielding.

Deployments were slow. Uploads were painful. And the easy excuse was:
“Big app. Happens.”

Nah.

So I opened the bundle and started pulling it apart.

This post walks through:

• How I analyze a production build when something feels off

• What usually hides inside large React bundles

• The architectural fixes that brought it down from 68MB to 21MB

Because this isn’t about shaving numbers for fun.
It’s about faster deploys, better caching, quicker rollbacks — and not panicking on release day.

If you're shipping frontend to production, this stuff matters.

Step 1 — Quick Win: Kill Source Maps in Production

First check: production was generating source maps.

Turned that off.

68MB → 25MB instantly.

Good win.
But that still left 25MB of actual application code.

So the real question became:

What exactly are we shipping to users?

Step 2 — What Are We Actually Shipping?

A production bundle is basically a giant, minified blob.

Manually scanning files isn’t realistic.
So I generated build stats and ran them through a Webpack bundle analyzer.

The treemap visualization made it very obvious where the weight was coming from.

In a clean, role-based SaaS architecture:

• The main bundle should contain only core app logic

• Feature libraries should load with their routes

• Heavy libraries (charts, PDF tools, editors, etc.) should not sit in the entry chunk unless truly global

The visualization made one thing clear — that separation wasn’t strict.

And that’s where the real fixes started.

Step 3 — Keep Route-Level Dependencies Out of the Main Bundle

While reviewing the treemap, one thing stood out.

Highcharts was inside the main bundle.

That didn’t make sense.

Charts were used only inside dashboards.
Dashboards were lazy-loaded per role.

After tracing imports, I found this in the root entry file:

import Highcharts from "highcharts";

Highcharts.setOptions({
  chart: {
    style: {
      fontFamily: "'Poppins', sans-serif",
    },
  },
});

That one import was enough.

Even though routes were lazy-loaded, the dependency wasn’t.

So every single user — even those who never opened a dashboard — was downloading a charting library.

Fix

I moved the chart configuration into a dedicated chart module and imported it only inside chart-related components.

Rebuilt.

25MB → 21MB.

More importantly:

• Highcharts was removed from the main bundle

• It now loads only when a dashboard loads

• Route-based code splitting started behaving correctly

This wasn’t just about shaving 4MB.

It was about making sure users download only what they actually use.

Step 4 — Don’t Ship Two Libraries for One Problem

During dependency audit, both moment and dayjs were present.

Classic enterprise pattern.

Features get added. Libraries stick around.

But duplicate libraries mean:

• Bigger bundle

• More cognitive load

• More maintenance surface area

Before removing anything, I evaluated:

• Actual feature usage in the codebase

• Edge cases (timezones, parsing, formatting)

• Bundle size impact using tools like Bundlephobia

dayjs covered our requirements with a smaller footprint.

So I standardized on dayjs, replaced remaining moment usage, and removed it.

Result:

• Leaner dependency graph

• Smaller production build

• Cleaner architectural boundary

Optimization isn’t always about clever tricks.

Sometimes it’s about deliberate decisions.

Step 5 — Static Assets Matter Too

JavaScript isn’t the only thing that grows silently.

Over time, the /public folder had accumulated unused images and static assets — old design iterations, deprecated illustrations, leftover icons.

These don’t show up in JS bundle analyzers, but they:

• Increase deployment size

• Slow down uploads

• Add unnecessary storage and CDN overhead

A quick audit removed unused files and cleaned up the directory structure.

Performance isn’t just about code.

It’s about everything being shipped.

What I Look For in Enterprise Bundle Optimization

From this experience, these are the patterns I now actively check:

1. Entry Point Imports

Anything imported in index.tsx or root files becomes part of the main bundle.

Global configuration imports must be intentional.

2. Feature Isolation

Route-based apps should reflect in bundle structure.

If dashboards are lazy-loaded, their heavy dependencies must be lazy-loaded too.

3. Duplicate Libraries

Multiple libraries solving the same problem should be evaluated and standardized.

4. Heavy Libraries

Charts, PDF tools, editors, icon packs — common bloat sources.

They should be lazy-loaded, dynamically imported, or replaced with lighter alternatives.

5. Raw Code vs Dependency

Sometimes small utilities are better implemented in-house instead of importing an entire package.

Dependency discipline matters in enterprise systems.

Final Results

Key Learnings

• Bundle size reflects architecture decisions.

• Lazy loading works only when dependencies are isolated correctly.

• Root-level imports can silently defeat code splitting.

• Regular dependency audits are essential in growing codebases.

• Optimization isn’t about removing libraries — it’s about structuring intentionally.

This experience changed how I think about performance in React systems.

Instead of optimizing at the end, bundle structure is now treated as part of architecture design from day one.