DEV Community: Aditya Bhaskar

Latex OCR

Aditya Bhaskar — Fri, 23 Oct 2026 15:25:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

Built Latex OCR which converts Maths formula image into latex code

# LocalLead AI: Finding Business Opportunities with Open-Weight AI

Aditya Bhaskar — Wed, 14 Oct 2026 13:04:16 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Finding potential clients is one of the most time-consuming activities for freelancers and small software development agencies.

Before approaching a business, we often need to understand what it does, which services it offers, and whether there are opportunities to help improve its digital operations.

Normally, this means opening a website, navigating through several pages, reading the content, and manually preparing research notes.

I wanted to simplify that process using open-weight AI.

So I built LocalLead AI, a lightweight business research assistant that transforms public business websites into structured business intelligence and potential software development opportunities.

How it works:

Enter a business website URL.
The application crawls relevant pages, including links discovered through navigation menus and footers.
It extracts and cleans website content.
Qwen3-4B summarizes the business information.
The model identifies possible software and automation opportunities.
The application generates a structured lead report with supporting source URLs.
Users can download the extracted information, summaries, and final report as JSON files.

For example, if a clinic's website states that appointments are handled over the phone, LocalLead AI might suggest an online appointment management system.

These recommendations are treated as potential opportunities, not confirmed customer requirements.

Who would pay for it?

LocalLead AI is designed for:

Freelancers looking for potential clients.
Software development agencies researching businesses.
Consultants identifying possible automation opportunities.
Small sales teams performing initial prospect research.

The potential business model is simple: offer affordable research reports or a subscription that helps users reduce repetitive manual research.

The prototype has not yet been commercially validated, but it targets a real and recurring workflow.

Demo

I built an interactive Gradio interface with a minimal dark theme.

Users enter a website URL and receive a structured analysis containing:

Business overview
Business category
Potential software opportunities
Supporting sources
Confidence indicators
Lead priority
Downloadable JSON reports

Demo: [Add Gradio demo URL or recorded walkthrough]

The application currently runs inside a Kaggle Notebook using an NVIDIA Tesla T4 GPU.

Because Kaggle sessions are temporary, I recommend watching the recorded demo if the live application is unavailable.

Code

GitHub Repository: [https://github.com/adityagit-creator/AIWebSearch]

The implementation uses Python and standard open-source libraries.

One of my goals was to avoid unnecessary infrastructure and keep the project easy to understand and modify.

The application does not require a separate vector database, autonomous browser framework, or complex agent orchestration layer.

How I Built It

1. Starting with a browser agent idea

My initial inspiration came from the Browser MCP Agent in the Awesome LLM Apps repository.

A general-purpose browser agent is powerful, but I realized that this specific use case did not require a fully autonomous browsing environment.

For an initial business research workflow, a lightweight crawler could handle much of the information collection.

I therefore built a specialized pipeline instead of copying the original agent architecture.

2. Extracting website information

I used Python Requests and BeautifulSoup to retrieve and parse public webpages.

The crawler starts from a business website and discovers additional internal pages.

Navigation menus and footer links are included because useful information may be found on About, Services, Products, and Contact pages.

The application removes unnecessary HTML elements, extracts readable text, and saves the collected information.

The initial version limits extraction to ten pages per website.

3. Choosing an AI model

Initially, I experimented with the Hugging Face Inference API.

However, several models were unavailable through my enabled inference providers, and I eventually exhausted my free inference credits.

Instead of relying on a paid API, I decided to run an open-weight model directly.

I selected Qwen3-4B and loaded it through Hugging Face Transformers and PyTorch in Kaggle.

My development environment provided two NVIDIA Tesla T4 GPUs, but the model was small enough to run on a single GPU.

This removed the need to pay a hosted LLM provider for individual inference requests during development.

4. Summarizing the website

Rather than passing all extracted pages into one large prompt, I created a two-stage analysis process.

Stage A — Page summarization

Qwen3-4B analyzes individual pages to identify:

Business identity
Products and services
Target customers
Existing digital features
Booking and contact methods
Operational information

The individual summaries are saved for later review.

Stage B — Opportunity generation

The model analyzes the collected summaries and produces a structured JSON report with possible software solutions, reasons for suggesting them, source URLs, and confidence labels.

This separation keeps the research process easier to inspect and debug.

5. Building the interface

I used Gradio to create an interactive web application without building a separate frontend.

The interface includes three primary sections:

Overview & Leads: A readable business research report.

Structured Data: The complete JSON analysis.

Export: Downloadable lead reports, page summaries, and extracted website content.

I also customized the UI with a near-black theme, subtle borders, and high-contrast typography.

Technology Stack

Component	Technology
Programming language	Python
AI model	Qwen3-4B
Model inference	PyTorch + Transformers
Compute	Kaggle GPU
Website crawling	Requests
HTML processing	BeautifulSoup
User interface	Gradio
Storage and export	JSON

Why Does Open Innovation Matter?

Open-weight AI is not just an optional component of LocalLead AI. It is the core technology that makes the application useful.

1. Avoiding dependency on proprietary inference APIs

During development, I encountered restrictions with hosted model availability and inference credits.

By switching to Qwen3-4B, I could continue building without purchasing additional API credits.

The model runs directly within my allocated Kaggle environment.

This doesn't make computation universally free, since Kaggle has usage limits and production infrastructure has costs. But it makes experimentation more accessible.

2. Control over the model

Using an open-weight model gives me more control over inference behavior.

I can adjust generation settings, modify prompts, inspect model outputs, and experiment with alternative model architectures.

For example, I can configure temperature and top-p to balance output consistency against variation in suggested business opportunities.

3. Model portability

The application is not permanently tied to one model provider.

The Qwen3-4B inference layer can be replaced with another compatible open-weight model without redesigning the entire website research workflow.

This creates flexibility for future deployment and experimentation.

4. Inspectable research

Rather than returning only a final AI answer, LocalLead AI saves the extracted website content, intermediate summaries, and structured report.

This gives users an opportunity to review the evidence behind the AI-generated recommendations.

A model can still make mistakes, and summaries can omit relevant details. Preserving the source content makes verification easier.

5. A practical path toward a side hustle

A small agency or freelancer may not need an expensive enterprise sales intelligence platform.

A narrowly focused tool that automates the repetitive first stage of prospect research could provide useful value at a lower operating cost.

Open-weight AI makes it possible to experiment with such a business without depending entirely on proprietary model pricing and availability.

Challenges and Lessons Learned

During development, I encountered several issues:

Hugging Face model availability: Some models listed in the catalog were not available through my configured inference providers.

Inference credits: I exhausted my hosted API allowance and moved to Kaggle-hosted model inference.

Transformers generation: I initially encountered an error when passing a BatchEncoding object directly to model.generate(). Passing the token tensors as named arguments fixed the issue.

GPU memory: I configured Qwen3-4B to run on a single Tesla T4 rather than unnecessarily distributing it across two GPUs.

Structured output: Generating valid JSON consistently requires careful prompts and output handling.

UI readability: I redesigned the Gradio export interface after discovering contrast issues with the default file component.

These experiences reinforced an important lesson: a useful AI application doesn't always need the biggest model or the most complicated framework.

Sometimes a focused workflow with a smaller model is enough.

Future Improvements

I plan to improve LocalLead AI by adding:

Prioritized crawling of About, Services, and Contact pages
Better handling of JavaScript-rendered websites
Stronger source verification
JSON schema validation
Batch analysis of multiple business websites
CSV export
More transparent lead ranking
Support for interchangeable open-weight models
Persistent lead history

Before broader public deployment, I also plan to strengthen URL validation, crawling safeguards, and protections against requests to internal network addresses.

Conclusion

LocalLead AI started with a simple question:

Can a lightweight open-weight AI application reduce the repetitive work involved in finding potential software clients?

The prototype demonstrates a practical approach: crawl public business information, summarize it using Qwen3-4B, and convert the results into structured research with potential software opportunities.

For me, the biggest benefit of open innovation is having the flexibility to keep building, experimenting, and improving the product without being locked into a single proprietary inference provider.

That's what makes LocalLead AI an interesting foundation for a potential side hustle.

Built with Python, Qwen3-4B, Kaggle, BeautifulSoup, and Gradio.

Hacktoberfest #OpenSource #AI #SideHustle

LLM sql bot for friend

Aditya Bhaskar — Mon, 05 Oct 2026 07:00:40 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built an LLM-powered Natural Language to SQL API using Google Gemma through Hugging Face.

The idea is simple: instead of requiring someone to know SQL, they can ask a database question using normal language.

For example:

Show me all female customers from Mumbai

The application converts that request into:

SELECT *
FROM customers
WHERE gender = 'Female'
AND location = 'Mumbai'

I built this with a friend or teammate in mind who may need to retrieve information from a database but does not necessarily know SQL syntax.

The goal is to make database interaction easier by allowing users to communicate with structured data using the same language they use every day.

The overall flow is:

Natural Language Question
        ↓
      FastAPI
        ↓
Gemma via Hugging Face
        ↓
   Generated SQL
        ↓
   SQL Validation
        ↓
      SQLite
        ↓
      Results

One important part of the project is that the generated SQL is not executed blindly.

Before executing a query, the backend validates it and only allows safe read operations.

Currently, operations such as:

INSERT
UPDATE
DELETE
DROP
ALTER
CREATE
TRUNCATE

are rejected.

Only SELECT queries are allowed.

Demo

The API accepts requests through:

POST /query

Example:

{
  "query": "show me all female customers from Mumbai"
}

Gemma generates SQL such as:

SELECT *
FROM customers
WHERE gender = 'Female'
AND location = 'Mumbai'

The SQL is validated and executed against the SQLite database.

A response looks similar to:

{
  "sql_query": "SELECT * FROM customers WHERE gender = 'Female' AND location = 'Mumbai'",
  "results": [
    {
      "customer_id": 2,
      "name": "Jane Smith",
      "gender": "Female",
      "location": "Mumbai"
    },
    {
      "customer_id": 6,
      "name": "Diana Evans",
      "gender": "Female",
      "location": "Mumbai"
    }
  ],
  "message": "Found 2 results",
  "execution_time": 0.82
}

Demo Link:

Add your deployed API or video demo here.

Code

The backend is built with Python and FastAPI.

The main LLM call uses Hugging Face's inference client with Gemma:

from huggingface_hub import InferenceClient

def get_hf_client():
    hf_token = os.getenv("HF_TOKEN")

    if not hf_token:
        raise ValueError("HF_TOKEN not configured")

    return InferenceClient(
        api_key=hf_token,
        provider="auto"
    )

The natural-language query is then sent to Gemma:

chat_completion = client.chat.completions.create(
    model="google/gemma-3-27b-it",
    messages=[
        {
            "role": "user",
            "content": prompt
        }
    ],
    temperature=0.1,
    max_tokens=512
)

The model's response is extracted and validated before anything reaches the database.

For example, I maintain a list of forbidden SQL operations:

forbidden_keywords = [
    "insert",
    "update",
    "delete",
    "drop",
    "alter",
    "create",
    "truncate",
    "replace",
    "attach",
    "detach"
]

The API also checks that the generated statement starts with:

SELECT

or:

WITH

This creates a safety layer between the LLM and the database.

GitHub Repository:

https://github.com/adityabhaskarme/LLM-Sql

How I Built It

The project uses the following stack:

Google Gemma — generates SQL from natural-language requests
Hugging Face Inference — provides access to the Gemma model
FastAPI — exposes the backend API
SQLite — stores and queries the sample customer database
Pydantic — validates API requests and responses
Python — powers the complete backend

The database currently contains a simple customers table:

customers

customer_id
name
gender
location

When a user submits a question, the application first gives Gemma information about the database schema.

For example:

Table: customers

Columns:
- customer_id
- name
- gender
- location

The prompt then instructs Gemma to return only a valid SQLite query.

After receiving the response, the application:

1. Extracts the generated SQL
2. Checks for forbidden operations
3. Rejects multiple SQL statements
4. Ensures it is a SELECT query
5. Executes the query against SQLite
6. Returns the results through FastAPI

This was also an interesting part of the project because using an LLM for SQL generation is not only about getting the model to generate correct SQL.

You also have to think about what happens when that generated output interacts with an actual database.

Why Does Open Innovation Matter?

Open innovation made this project much easier to experiment with.

Using an open-weight model like Gemma gives developers more flexibility in how AI is integrated into applications.

Instead of designing the entire project around one closed API, I can build the architecture around the model itself and choose how I want to run or serve it.

For example, the same project architecture could eventually use:

Hugging Face hosted inference

        or

Self-hosted Gemma

        or

Local inference

without redesigning the complete application.

Open models also make it easier to understand, experiment with, customize, and potentially fine-tune the model for a specific use case such as SQL generation.

For a project like this, I could eventually train or adapt the model specifically around:

A company's database schema
Internal terminology
Complex SQL queries
Domain-specific tables
Query examples
Database-specific syntax

That flexibility is one of the things I find most interesting about building with open AI models.

My Agent Session

I haven't added an agent session yet.

If I continue developing this project using DevRelay, I can add the session here later.

Prize Categories

I am entering this project for categories related to:

Open-source AI
Hugging Face / open-weight models
AI-powered developer tools
Hacktoberfest Weekend Challenge

What's Next?

The current version works with a simple single-table database, but there are several improvements I want to explore.

Next, I want to add:

Multiple-table support
Automatic schema discovery
SQL JOIN generation
More advanced SQL parsing
Stronger query validation
Better handling of ambiguous questions
Query explanation
Support for larger databases
Database-specific SQL generation
Self-hosted Gemma inference

Eventually, I would also like to move from:

User → LLM → SQL

toward a more intelligent database agent:

User
 ↓
Gemma
 ↓
Understand Database Schema
 ↓
Generate SQL
 ↓
Validate Query
 ↓
Execute Query
 ↓
Inspect Result
 ↓
Explain Result to User

This project started as a simple Natural Language to SQL experiment, but it has been a useful way to explore how open LLMs like Gemma can become practical interfaces between humans and structured data.

Thanks for reading! 🚀