DEV Community: Neeraj Ciju

Building VtoB: Turning YouTube Videos into Technical Blog Posts with a Multi-Stage AI Pipeline

Neeraj Ciju — Sun, 16 Aug 2026 14:35:47 +0000

Meta Description: How I built VtoB, a full-stack AI application that converts YouTube videos into structured, SEO-ready Markdown articles using LangGraph, Gemini, Groq, and FastAPI.

Writing a good technical article from a long YouTube video is a surprisingly repetitive workflow:

watch → take notes → organize → write → edit → optimize.

I built VtoB to automate that workflow.

The idea is simple: paste a YouTube URL and get a structured Markdown article generated through a multi-stage AI pipeline.

Demo Video

Key Takeaways

Multi-stage generation: VtoB separates transcription, planning, writing, and SEO refinement into independent pipeline stages.
LangGraph orchestration: The backend uses a StateGraph to pass shared state between processing nodes.
Model specialization: Gemini 3.1 Flash-Lite handles structure and refinement, while Llama 3.3 70B handles long-form drafting.
Full-stack workflow: A Next.js frontend communicates with a FastAPI backend and renders the final Markdown with copy and download actions.

Architecture

The system has two main layers:

Next.js 16 Frontend
        |
        | POST /generate
        v
FastAPI Backend
        |
        v
LangGraph StateGraph
        |
        +--> Fetch Transcript
        |
        +--> Generate Outline
        |
        +--> Write Draft
        |
        +--> SEO Refine
        |
        v
Final Markdown

The frontend uses Next.js 16.3.1, React 19, TypeScript, Tailwind CSS 4, Motion, GSAP, OGL, and react-markdown. The backend is built with FastAPI, LangGraph, LangChain, Gemini, Groq, Pydantic, and youtube-transcript-api. ([GitHub][2])

[INSERT: ARCHITECTURE SCREENSHOT]

Why LangGraph?

The main design decision was to avoid treating the entire task as one giant LLM prompt.

Instead, VtoB models the workflow as a graph with four explicit nodes:

START
  |
  v
Fetch Transcript
  |
  v
Generate Outline
  |
  v
Write Draft
  |
  v
SEO Refine
  |
  v
END

The graph is compiled with LangGraph's StateGraph, and each node reads from and writes to a shared BlogState. ([GitHub][1])

The state contains:

class BlogState(TypedDict):
    video_url: str
    video_id: str
    transcript: Optional[str]
    outline: Optional[str]
    blog_draft: Optional[str]
    seo_blog: Optional[str]

This makes each stage independently understandable and easier to modify.

Stage 1: Extracting the Transcript

The first node extracts the YouTube video ID from either a normal YouTube URL or a youtu.be URL.

api = YouTubeTranscriptApi()
transcript_list = api.fetch(video_id)

transcript_text = " ".join(
    [item.text for item in transcript_list]
)

The transcript is then stored in the graph state for the next stage. An empty transcript raises an error instead of allowing the pipeline to continue with invalid input. ([GitHub][3])

Stage 2: Turning a Transcript into an Outline

A transcript is not automatically a good article.

Spoken content contains repetition, tangents, and loosely connected ideas, so VtoB first sends the transcript to Gemini 3.1 Flash-Lite for structural planning.

The prompt specifically asks the model to:

Reorganize the spoken content into a coherent narrative
Target technical developers
Create Markdown heading hierarchy
Attach factual notes to each section

This means the writing model doesn't have to figure out the article structure and the prose simultaneously. ([GitHub][1])

Raw Transcript
      |
      v
Gemini 3.1 Flash-Lite
      |
      v
Structured Outline

Stage 3: Writing the Article

Once the structure exists, VtoB sends the outline plus a transcript excerpt to Llama 3.3 70B through Groq.

The implementation deliberately limits the transcript context to the first 8,000 characters as a token-safety buffer.

transcript_excerpt = state["transcript"][:8000]

The writer is instructed to produce GitHub-Flavored Markdown, maintain proper heading structure, use Markdown code blocks, and avoid referring to the source material as a "video" inside the generated article. ([GitHub][1])

Transcript
    |
    +----> Outline
    |
    v
Llama 3.3 70B
    |
    v
Technical Draft

The important architectural idea here is model specialization:

Gemini plans. Llama writes.

Stage 4: SEO Refinement

The final node takes the generated draft and sends it back to Gemini 3.1 Flash-Lite for formatting and SEO refinement.

The formatter enforces things such as:

# Title

> Meta Description

## Key Takeaways

## Section
### Subsection

It also ensures consistent paragraph spacing and Markdown structure. ([GitHub][1])

This gives the pipeline a final quality-control stage rather than returning the first generated draft directly.

The API

The entire pipeline is exposed through a single endpoint:

POST /generate
Content-Type: application/json

with:

{
  "video_url": "https://www.youtube.com/watch?v=..."
}

The backend returns the intermediate and final artifacts:

{
  "video_id": "...",
  "transcript": "...",
  "outline": "...",
  "blog_draft": "...",
  "seo_blog": "..."
}

That is useful during development because the system exposes more than just the final answer. You can inspect each stage independently and see where generation quality changes. ([GitHub][1])

Building the Frontend

The frontend keeps the interaction deliberately simple.

The user enters a YouTube URL and is redirected to the generation page with the URL passed as a query parameter.

The generation page then calls:

fetch("http://127.0.0.1:8000/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ video_url: videoUrl }),
});

The UI also generates the YouTube thumbnail directly from the extracted video ID and displays the final response as rendered Markdown. ([GitHub][3])

[INSERT: FRONTEND SCREENSHOT]

Exporting the Result

The generated article isn't just displayed on screen.

The frontend supports:

Copying the final Markdown to the clipboard
Downloading the article as a .md file
Rendering the Markdown directly in the browser

The downloaded filename is generated from the article title, making the output immediately usable in another editor or publishing workflow. ([GitHub][3])

Tech Stack

Layer	Technology
Frontend	Next.js 16, React 19, TypeScript
Styling	Tailwind CSS 4
UI / Animation	Motion, GSAP, OGL
Markdown	react-markdown
Backend	FastAPI
Orchestration	LangGraph
LLM — Structure	Gemini 3.1 Flash-Lite
LLM — Writing	Llama 3.3 70B via Groq
Transcript	youtube-transcript-api
Validation	Pydantic

The current backend dependency set confirms FastAPI, LangChain, LangGraph, Gemini integration, Groq integration, Pydantic, and youtube-transcript-api.

What I Learned

The interesting part of this project wasn't generating text with an LLM.

It was designing the pipeline around the LLM.

A single prompt can generate an article, but separating the workflow into:

Extraction
   ↓
Planning
   ↓
Generation
   ↓
Refinement

makes the system easier to reason about, debug, and extend.

For example, the outline model can be replaced without touching the writing node. The SEO stage can be modified independently. The frontend can inspect intermediate outputs without changing the graph itself.

That separation is what makes VtoB feel more like an actual application than a wrapper around an LLM API.

What's Next?

Some natural extensions would be:

Support for videos without available captions using an audio transcription model
Better long-video handling through transcript chunking and hierarchical summarization
Persistent job tracking for asynchronous generation
User accounts and article history
Direct publishing integrations for platforms such as Dev.to
Evaluation of generated articles against the source transcript for factual consistency

Conclusion

VtoB started with a simple idea: turn a YouTube URL into a usable technical article.

The implementation ended up being a small exercise in AI system design:

YouTube
   ↓
Transcript
   ↓
Gemini
   ↓
Outline
   ↓
Llama
   ↓
Draft
   ↓
Gemini
   ↓
SEO Markdown

The biggest takeaway for me was that useful AI applications are rarely just about the model.

They are about how you structure the work around the model.

Source Code

GitHub: https://github.com/iPrq/VlogToBlog

Building Aegis: An AI-Powered Healthcare Companion

Neeraj Ciju — Sun, 16 Aug 2026 08:25:30 +0000

Aegis is a healthcare companion designed to help senior citizens with medication, safety, and accessing information.

The project combines AI, computer vision, Wi-Fi sensing, real-time communication, and mobile development into a single application.

Architecture

Aegis is built with Next.js, React, TypeScript, and Tailwind CSS, packaged for Android using Capacitor.

The backend is built with Python and FastAPI, exposing REST and WebSocket APIs for the different AI and ML services.

Next.js + React
       |
   Capacitor
       |
    Android
       |
    FastAPI
       |
 ┌─────┼──────────┐
 |     |          |
Gemini Groq    CSI + ANN
 |     |          |
Medical Chat   Fall Detection

AI-Powered Prescription Scanner

One of the main features is the medical document scanner.

A user can photograph a prescription and send it to the backend. Gemini 2.5 Flash analyzes the image and converts it into structured information such as:

Medication name and dosage
Medication schedule
Instructions
Locations for procedures
Safety restrictions

Instead of displaying a raw AI response, this information is converted into structured data that the frontend can use.

Prescription Image
       ↓
Gemini 2.5 Flash
       ↓
Structured JSON
       ↓
Medication + Safety Information

Context-Aware Medical Chat

The extracted prescription can then be used as context for a chatbot.

The backend uses Llama 3.3 70B through Groq to answer questions using the available prescription context.

Prescription
     ↓
Structured Context
     ↓
User Question
     ↓
Llama 3.3 70B
     ↓
Context-Aware Answer

This makes the chatbot specific to the user's uploaded medical information instead of functioning as a completely generic assistant.

Camera-Less Fall Detection

The most experimental part of Aegis is its fall-detection system.

Instead of relying on cameras, the system uses Wi-Fi Channel State Information (CSI) to detect changes caused by movement.

The backend processes CSI data from 20 subcarriers and extracts statistical and signal-processing features such as variance, standard deviation, signal energy, skewness, and kurtosis.

These features are passed through a scaler and an ANN classifier.

Wi-Fi CSI
   ↓
Signal Window
   ↓
Feature Extraction
   ↓
Scaler
   ↓
ANN
   ↓
FALL / NO_FALL

The result is streamed to the frontend using WebSockets, allowing the application to monitor the prediction in real time.

When a fall is detected, Aegis can trigger an emergency notification to a configured caretaker.

AI-Powered Web Intelligence

Aegis also includes a browser extension that can extract webpage content and send it to the backend.

The backend generates a summary using Llama 3.3 70B. That summary can then be used as context for a chatbot.

Webpage
   ↓
Browser Extension
   ↓
AI Summary
   ↓
Context
   ↓
Chat

This allows users to ask questions about the webpage rather than manually searching through it.

Accessibility

Since the application is designed with senior citizens in mind, the UI focuses on:

Large touch targets
High-contrast text
Simple navigation
Voice output
Multilingual support

Aegis also includes AI-powered text-to-speech and translation functionality.

Tech Stack

Component	Technology
Frontend	Next.js, React, TypeScript, Tailwind
Mobile	Capacitor
Backend	Python, FastAPI
Vision AI	Gemini 2.5 Flash
LLM	Llama 3.3 70B via Groq
Fall Detection	Wi-Fi CSI + ANN
Real-time	WebSockets
TTS	Orpheus via Groq

What I Learned

The main challenge wasn't integrating individual AI models. It was connecting them into useful workflows.

Aegis combines:

Vision → Structured Data → Chat
Wi-Fi → ML → Real-Time Alert
Webpage → AI Summary → Contextual Chat

The project taught me that building an AI application is less about adding as many models as possible and more about connecting intelligence to a meaningful user workflow.

The source code is available on GitHub:

https://github.com/iPrq/Aegis-App

ReClaim — Scalable, Campus-Centric Property Recovery via High-Dimensional Visual Search

Neeraj Ciju — Sun, 16 Aug 2026 07:41:27 +0000

Lost-and-found systems on campuses are difficult to scale. Lost items are usually described with vague text, while found items often sit in administrative offices with little to no structured metadata.

ReClaim tackles this problem by turning lost-and-found into a computer-vision-powered visual search system built specifically for campus communities.

Instead of relying solely on descriptions like "black water bottle lost near the library," users can upload photos of an item and let an AI-powered visual search pipeline identify visually similar items across the campus.

The goal is simple:

Upload → Search visually → Find a match → Reclaim your property.

How It Works

ReClaim combines a mobile-first reporting experience with a vision inference pipeline and campus-scoped vector search.

┌─────────────────────────┐
│     Image Capture       │
│       3:4 Crop          │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│    FastAPI Backend      │
│     Python + PyTorch    │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│    CLIP Vision Model    │
│   Image → Embedding     │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│  Cosine Similarity      │
│   Vector Comparison     │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│   Match Thresholding    │
│     > 90% Similarity    │
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Firestore + Notification│
│      Match Found        │
└─────────────────────────┘

Technical Architecture

Mobile Frontend

Built using:

Next js + Capacitor
TypeScript
Tailwind CSS
Custom camera modules

The camera workflow enforces a 3:4 aspect-ratio crop, creating standardized visual inputs before they reach the inference pipeline.

Users can upload up to 6 photos per item, allowing the system to capture different perspectives, textures, colors, and identifying characteristics.

AI Inference Service

The backend is powered by:

Python
FastAPI
PyTorch
CLIP (Contrastive Language-Image Pre-training)

Images are processed through the CLIP vision encoder to generate dense visual embeddings.

These embeddings capture high-level visual characteristics such as:

Shape and geometry
Color distribution
Texture
Object appearance
Visual similarity

Rather than storing only human-written descriptions, ReClaim creates a machine-readable representation of the item's visual identity.

AI-Powered Visual Matching Pipeline

1. Image Preprocessing

When a user reports an item, the uploaded images are normalized through the camera pipeline.

The standardized 3:4 crop helps reduce irrelevant background information and creates more consistent model inputs.

Users can provide multiple images to improve the representation of the object.

2. Dense Embedding Extraction

Each image is passed through the CLIP vision transformer.

Input Image
     │
     ▼
CLIP Vision Encoder
     │
     ▼
Visual Features
     │
     ▼
Dense Embedding Vector

The resulting embedding represents the visual characteristics of the object in a high-dimensional numerical space.

For our implementation, the generated representation is treated as a 512-dimensional embedding vector.

3. Similarity Search

When a new lost or found item is submitted, its embedding is compared against active items within the same campus.

The backend calculates cosine similarity between the target embedding and candidate embeddings.

Target Item
     │
     ▼
Embedding A ─────────┐
                     │
                     ▼
              Cosine Similarity
                     ▲
                     │
Embedding B ─────────┘
     │
     ▼
Similarity Score

High-scoring candidates are surfaced as potential matches.

A configurable similarity threshold is used to filter low-confidence results, with the current workflow targeting matches above 90% similarity.

Campus-Scoped Search

One of ReClaim's key design decisions is campus-level isolation.

Instead of searching a massive global database, queries are restricted to the user's verified campus.

For example:

User
 │
 ▼
RV University
 │
 ├── Lost Items
 ├── Found Items
 └── Reclaimed Items

This significantly reduces the search space while making the results more relevant.

A lost laptop at one university should not be compared against thousands of unrelated laptops reported across an entire city.

Firestore Data Architecture

ReClaim uses Firebase as its backend platform.

The system leverages:

Firestore for document storage
Firebase Authentication for campus OAuth / SSO
Firebase App Distribution for Android testing and release cycles

The core Firestore structure is organized around campuses:

/campuses/{campusId}/items/{itemId}

  ├── itemId: String
  ├── reporterId: String
  ├── status: LOST | FOUND | RECLAIMED
  ├── name: String
  ├── description: String
  ├── locationFound: String
  ├── dropoffDestination: String
  ├── imageURLs: Array[String]
  └── embeddings: Array[Float]

Potential matches are stored separately:

/campuses/{campusId}/matches/{matchId}

  ├── targetItemId: String
  ├── candidateItemId: String
  ├── similarityScore: Float
  └── timestamp: Timestamp

This separation allows the system to maintain the original item records while independently tracking generated match relationships.

Dark-Mode UX

Despite the complexity of the AI backend, ReClaim is designed around a simple principle:

The user shouldn't need to understand the AI.

The interface is optimized for fast reporting and high-visibility interaction.

Location Scoping

A verified campus badge such as:

RV University • Main Campus

makes the search boundary explicit to the user.

🎮 Action Router

The home screen immediately separates the two primary workflows:

"Lost Something?"

and

"Found Something?"

The retro pixel-art cards create a distinctive visual identity while making the application's primary actions immediately recognizable.

Report Workflow

Users can provide:

Item name
Description
Photos
Location
Drop-off information

Found-item reports can also specify a physical destination such as:

Admin Block Reception

This connects the digital discovery system with the physical lost-and-found process.

Match Feed

Potential matches are presented as image cards containing:

Item photos
Lost / Found status
Similarity confidence
Relevant metadata
Match information

This allows users to visually inspect potential matches instead of manually searching through hundreds of text-based reports.

Authentication & Campus Trust

ReClaim is designed around verified campus communities.

Authentication through Firebase allows the platform to associate reports with authenticated users while maintaining campus-level boundaries.

This creates a more trustworthy environment than a completely open lost-and-found marketplace.

Why Visual Search?

Traditional lost-and-found systems depend heavily on metadata.

For example:

"Black bottle"
"Lost near library"
"Found in Block B"

The problem is that users rarely describe objects consistently.

Two users might describe the same object as:

"Black Hydro Flask"
"Black water bottle"
"Metal bottle"
"Black flask with sticker"

A visual embedding provides another layer of information.

Instead of asking:

"Did someone use the exact same words?"

ReClaim asks:

"Does this object look like the one someone reported?"

Key Technical Challenges

1. Visual Ambiguity

Many campus objects look extremely similar.

Two black water bottles may have nearly identical shapes but belong to different people.

Because of this, similarity scores should be treated as candidate matches rather than absolute proof.

2. Background Noise

Photos can contain desks, floors, people, walls, and other irrelevant visual information.

The standardized 3:4 cropping workflow helps make the object itself more prominent within the model input.

3. Multiple Perspectives

A single photograph may not capture enough information to distinguish an object.

Supporting up to 6 photos per report allows ReClaim to build a stronger visual representation from multiple viewpoints.

4. Search Scalability

As the number of reports grows, comparing every new image against every stored embedding becomes increasingly expensive.

The current architecture establishes the foundation for eventually introducing dedicated vector-search infrastructure and approximate nearest-neighbor indexing for much larger campuses.

Future Improvements

ReClaim's current architecture can be extended in several directions:

Approximate Nearest Neighbor (ANN) vector search
Dedicated vector databases such as FAISS or Qdrant
Multimodal text + image retrieval
OCR for serial numbers and labels
Object detection before embedding generation
Duplicate report detection
Push notifications for newly discovered matches
Cross-campus federation
Admin dashboards for lost-and-found offices
Human verification before confirming a reclamation
Confidence calibration using real campus data

A particularly interesting future direction is multimodal retrieval, where both the uploaded image and the user's textual description contribute to the final ranking.

What Makes ReClaim Different?

ReClaim isn't simply another lost-and-found form.

It combines:

Computer Vision + Vector Embeddings + Campus Authentication + Real-World Item Recovery

into a single workflow.

The system connects the entire process:

Physical Object
      ↓
Photo
      ↓
AI Embedding
      ↓
Campus-Scoped Search
      ↓
Potential Match
      ↓
User Verification
      ↓
Physical Reclamation

The ultimate goal is to make lost-and-found systems searchable, scalable, and intelligent.

Built For Campus Communities

ReClaim is designed around a simple observation:

Lost-and-found desks already have the objects. The problem is finding the right person.

By turning physical objects into searchable visual representations, ReClaim aims to bridge that gap.

Instead of manually browsing lists of vague descriptions, students can simply show the system what they're looking for.

See it. Search it. Reclaim it.

🔧 Tech Stack

Layer	Technology
Mobile	React Native, Expo, TypeScript
Styling	Tailwind CSS
Backend	Python, FastAPI
AI / ML	PyTorch, CLIP
Authentication	Firebase Auth
Database	Firestore
Distribution	Firebase App Distribution
Search	Dense Vector Embeddings + Cosine Similarity

ReClaim

A campus-centric visual search engine for lost and found property.

Don't describe what you lost. Show us.

I Built an Agentic AI Stock Research Terminal with LangChain

Neeraj Ciju — Sat, 08 Aug 2026 09:01:54 +0000

What if you could type a stock ticker and get more than just its current price?

I wanted to build something that could combine real financial data, fundamental valuation, and recent market information into one place.

So I built StockAny AI — an AI-powered equity research and valuation terminal.

👉 GitHub: https://github.com/iPrq/Stock-Market-Analyser

The idea is simple:

Enter a ticker → fetch financial data → calculate intrinsic value → research recent developments → generate an investment thesis.

And the interesting part is that the AI isn't responsible for doing everything.

The financial calculations happen in the backend, while Gemini is used to interpret the data and research recent developments.

What does StockAny AI actually do?

For any stock ticker, the application performs four main steps:

Fetches live financial data
Calculates an estimated intrinsic value using a DCF model
Calculates the margin of safety
Uses Gemini + web search to generate an investment thesis

The final result gives you things like:

Current stock price
Estimated intrinsic value
Margin of safety
BUY / HOLD / SELL recommendation
AI-generated investment thesis
Bull case
Bear case
Recent developments and catalysts
Sources used for the research

The goal wasn't to build another stock-price dashboard.

I wanted it to feel more like a mini equity research terminal.

The Architecture

The application is split into two major parts:

                 ┌─────────────────────┐
                 │    Next.js Frontend │
                 │   React 19 + TS     │
                 └──────────┬──────────┘
                            │
                     POST /api/analyze
                            │
                            ▼
                 ┌─────────────────────┐
                 │    FastAPI Backend  │
                 │      Python         │
                 └──────────┬──────────┘
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼
      Financial Data                 DCF Valuation
        FMP API                     Intrinsic Value
             │                             │
             └──────────────┬──────────────┘
                            ▼
                  ┌──────────────────┐
                  │ Gemini 3.1 Flash │
                  │      Lite        │
                  └────────┬─────────┘
                           │
                           ▼
                    Tavily Web Search
                           │
                           ▼
                  Structured Analysis
                           │
                           ▼
                    Next.js Results

The frontend is built with Next.js 16, React 19 and Tailwind CSS v4, while the backend uses Python, FastAPI and Uvicorn.

Why not just ask an LLM?

This was one of the most important design decisions.

If you simply ask an LLM:

"Is NVIDIA a good investment?"

you'll get an answer, but there are several problems.

The model shouldn't be responsible for inventing financial numbers or performing the entire valuation itself.

Instead, StockAny separates the responsibilities.

The backend handles the numbers

Financial Modeling Prep provides data such as:

Stock price
Market capitalization
P/E ratio
Free cash flow
Shares outstanding
Sector information

The backend then uses this data for the actual valuation.

Gemini handles interpretation

Gemini is given the financial context and uses Tavily to research recent information such as:

Earnings
Company developments
Competitive threats
Catalysts
Recent news

This creates a much more useful separation:

Financial APIs
      ↓
Reliable numerical data
      ↓
DCF calculation
      ↓
Financial context
      ↓
Gemini + web research
      ↓
Human-readable investment thesis

Building the DCF Model

The core of the valuation system is a two-stage Discounted Cash Flow model.

The first stage projects free cash flow for five years.

The default assumptions are:

Growth rate:       8%
Discount rate:     9%
Terminal growth:  2.5%
Projection period: 5 years

The projected cash flows are discounted back to their present value.

Then we calculate a terminal value based on perpetual growth.

Conceptually:

              FCF₁     FCF₂     FCF₃     FCF₄     FCF₅
               │        │        │        │        │
               ▼        ▼        ▼        ▼        ▼
             Discount each cash flow to present value
                              │
                              ▼
                     Terminal Value
                              │
                              ▼
                  Discount terminal value
                              │
                              ▼
                ┌───────────────────────┐
                │ Enterprise/Equity     │
                │ Value Estimate        │
                └───────────┬───────────┘
                            ▼
                     Shares Outstanding
                            │
                            ▼
                   Intrinsic Value/Share

The intrinsic value per share is then compared with the current market price.

Margin of Safety

One of the most useful outputs is the margin of safety.

The calculation is:

Margin of Safety =
(Intrinsic Value - Current Price)
--------------------------------- × 100
          Current Price

For example, if a stock is trading at $100 and the calculated intrinsic value is $130:

(130 - 100) / 100 × 100
= 30%

The application can then visually show the gap between the current market price and the estimated intrinsic value.

This gives the AI something quantitative to reason about instead of simply asking it to make a prediction.

Adding Web Research with Tavily

Financial numbers alone aren't enough.

A company's valuation can look attractive while something important has changed recently.

For example:

A major competitor launches a new product
Earnings guidance changes
A company loses an important customer
Regulation affects an industry
Management announces a major acquisition

So I added Tavily Search to the pipeline.

The AI can search for recent information about the company before generating its thesis.

The resulting workflow becomes:

Financial fundamentals
        +
DCF valuation
        +
Recent web information
        ↓
    Gemini
        ↓
Investment thesis

This is also why the output includes source links.

The goal isn't to have an AI confidently hallucinate an explanation.

The goal is to give it real inputs and let it synthesize them.

Structured AI Output

Instead of asking Gemini to return a giant block of text, the backend expects structured information.

Something conceptually like:

{
  "recommendation": "BUY",
  "thesis": "...",
  "bull_case": "...",
  "bear_case": "...",
  "sources": []
}

This makes the frontend much easier to build.

The UI can independently render:

┌─────────────────────────────┐
│          BUY                │
│                             │
│ Current Price     $100      │
│ Intrinsic Value   $130      │
│ Margin of Safety  +30%      │
└─────────────────────────────┘

Investment Thesis
─────────────────────────────
...

Bull Case
─────────────────────────────
...

Bear Case
─────────────────────────────
...

Sources
─────────────────────────────
...

This is much more flexible than trying to parse arbitrary AI-generated text on the frontend.

Tech Stack

The project currently uses:

Frontend

Next.js 16
React 19
TypeScript
Tailwind CSS v4

Backend

Python
FastAPI
Uvicorn

AI

Gemini 2.5 Flash Lite
LangChain

Data & Research

Financial Modeling Prep
Tavily Search

The project also uses Inter for typography and a video background for the landing page.

Project Structure

The repository is organized roughly like this:

Stock-Market-Analyser/
│
├── app/
│   ├── main.py
│   ├── requirements.txt
│   └── pyproject.toml
│
└── stockany/
    ├── app/
    │   ├── page.tsx
    │   ├── layout.tsx
    │   └── globals.css
    │
    ├── public/
    │   └── *.mp4
    │
    ├── next.config.ts
    └── package.json

The FastAPI backend contains the API routes, LangChain tooling and DCF logic, while the Next.js application handles the user interface and results page.

Running It Locally

You'll need API keys for:

Financial Modeling Prep
Google AI Studio / Gemini
Tavily

Create:

app/.env

and add:

FMP_API_KEY=your_fmp_key_here
GOOGLE_API_KEY=your_gemini_key_here
TAVILY_API_KEY=your_tavily_key_here

Then start the backend:

cd app

pip install -r requirements.txt

uvicorn main:app --reload

The FastAPI server will run on:

http://localhost:8000

Then start the frontend:

cd stockany

npm install
npm run dev

and open:

http://localhost:3000

The complete setup instructions are available in the repository.

What I Learned

The biggest lesson from this project was that AI applications don't necessarily need to let the LLM do everything.

A much better approach is often:

Traditional software
        +
APIs
        +
Deterministic calculations
        +
LLM reasoning
        +
Web research

The DCF calculation is deterministic.

Financial data comes from an API.

Web research comes from a search system.

The LLM sits on top of those components and turns the information into something humans can understand.

That architecture makes the application considerably more grounded than simply prompting an LLM for a stock prediction.

What's Next?

There are several things I'd like to improve:

Historical valuation

Instead of only looking at the current valuation, I'd like to compare the stock against its historical multiples.

More valuation models

Adding:

P/E valuation
EV/EBITDA
Price-to-Free-Cash-Flow
Comparable company analysis

would make the valuation more robust.

Better AI reasoning

The next step would be giving the model access to more structured financial statements and letting it explicitly explain which assumptions drive the valuation.

Portfolio analysis

Eventually, I'd like to allow users to enter multiple tickers and compare them side-by-side.

Final Thoughts

StockAny AI started as an experiment in combining financial analysis with agentic AI, but it ended up teaching me something more important about building AI products.

The interesting part isn't just calling an LLM API.

It's designing a system where the LLM has access to the right tools, the right data, and the right constraints.

For this project, that meant combining:

FMP → financial data

DCF → valuation

Tavily → recent information

Gemini → reasoning and synthesis

FastAPI → backend orchestration

Next.js → user experience

The result is a small but complete example of how traditional software and generative AI can work together.

If you want to check out the implementation:

👉 GitHub: https://github.com/iPrq/Stock-Market-Analyser
👉 Youtube: https://youtu.be/XbrxvaP-FYk

I'd love to hear what you'd add to the project next.

Disclaimer: StockAny AI is an educational and informational project. Its outputs are not financial advice, and investment decisions should always involve independent research.