DEV Community: Swarna

I Built 3 AI Products with Spring Boot — Here’s What I Learned

Swarna — Fri, 14 Aug 2026 15:32:45 +0000

I got tired of building the same CRUD applications.

So instead of creating another simple Employee Management System or To-Do application, I decided to build something that felt closer to a real product.

Over the last few weeks, I built three AI-powered applications using Spring Boot:

🤖 AI Code Reviewer for GitHub Pull Requests
📄 AI Resume Analyzer
💬 Self-Hosted AI Support Widget

Each project started with a simple idea:

Can I build something useful with the backend technologies I already know instead of just building projects for a tutorial?

The answer turned out to be yes.

But the most valuable part wasn't actually finishing the applications.

It was everything I learned while building them.

Why I Chose Spring Boot

I've been working with Java and Spring Boot, so I wanted to see how far I could take the stack when combined with AI.

When people talk about AI applications, the conversation often revolves around Python, machine learning models, notebooks, and data science.

But there is another side to AI:

The application layer.

You still need:

REST APIs
Authentication
Database integration
External API communication
Request validation
Error handling
File processing
Business logic
Logging
Configuration
Deployment

And that's where Spring Boot becomes extremely useful.

The AI model might generate the intelligence, but the backend is what turns that intelligence into an actual product.

Product 1: AI Code Reviewer for GitHub Pull Requests

The first product I built was an AI-powered code reviewer for GitHub Pull Requests.

The idea was simple:

Instead of manually going through every changed file in a Pull Request, why not let an AI analyze the changes and provide useful feedback?

The basic flow
GitHub Pull Request
↓
Fetch PR information
↓
Get changed code
↓
Prepare review prompt
↓
AI analysis
↓
Generate review
↓
Return useful feedback

The AI isn't just being asked:

"Is this code good?"

The goal is to make the review more useful by looking for things developers actually care about.

For example:

Potential bugs
Code quality problems
Security concerns
Performance issues
Maintainability
Bad practices
Possible improvements
What I Learned From This Project

The biggest lesson was:

AI output is only as good as the context you give it.

Initially, it is tempting to simply send a piece of code to an AI model and ask:

"Review this code."

But real code doesn't exist in isolation.

A method might depend on another class.

A variable might have a specific business meaning.

A change might only make sense when you look at the entire Pull Request.

So building an AI application isn't simply about calling an AI API.

It's about collecting the right context and presenting it in the right way.

That was one of my first major lessons.

Product 2: AI Resume Analyzer

The second product was an AI Resume Analyzer built with Spring Boot.

The idea came from something very familiar to anyone who has applied for jobs:

You spend hours creating a resume...

Then send it to a company...

And never know why it didn't get shortlisted.

So I wanted to build a tool that could analyze a resume and provide useful feedback.

The basic idea
Resume
↓
Upload
↓
Backend processing
↓
Extract resume content
↓
AI analysis
↓
Generate feedback
↓
Return analysis

The application can analyze areas such as:

Skills
Experience
Keywords
Resume structure
Job relevance
Missing information
Potential improvements

The interesting part was that this project introduced a completely different backend problem compared with the GitHub reviewer.

Now the application had to deal with documents and unstructured information.

What I Learned From This Project

This project taught me something important:

Building an AI application is often more about data preparation than the AI call itself.

You can't just throw a document at an AI model and expect perfect results.

The application needs to:

Receive the file
Process the content
Extract useful information
Organize that information
Send the right context to the AI
Process the response
Present the result in a useful format

The backend therefore becomes the bridge between the user's raw input and the AI model.

That made me appreciate Spring Boot even more.

Product 3: Self-Hosted AI Support Widget

This is the project I'm currently most excited about.

I built a self-hosted AI support widget using Spring Boot.

The idea was to create an AI-powered support experience without forcing someone to depend on an expensive monthly SaaS subscription.

The important word here is:

Self-hosted.

Instead of thinking:

"I need to subscribe to another SaaS product."

The idea becomes:

"I can run this myself."

The basic concept
User
↓
Support Widget
↓
Spring Boot Backend
↓
AI Service
↓
Response
↓
Support Widget

The backend handles the communication between the widget and the AI service.

That means the frontend doesn't need to contain all the business logic.

Spring Boot becomes the central layer responsible for the application's behavior.

Why I Like This Project

This project felt different from my previous applications because I wasn't just thinking about whether an API worked.

I started thinking about:

How would another developer use this?
How can the application be self-hosted?
What should the API look like?
How should errors be handled?
How should configuration work?
How can the application be extended later?
How can I make this feel like an actual product?

That's when I realized something:

There is a big difference between building an application and building a product.
What These 3 Projects Taught Me

After building all three, I noticed that the AI itself was not the hardest part.

Calling an AI API is relatively straightforward.

The difficult part is everything around it.

AI Doesn't Replace Backend Engineering

This was probably my biggest takeaway.

AI can generate an answer.

But someone still has to build the system around it.

You still need to think about:

Authentication
↓
API Design
↓
Validation
↓
Business Logic
↓
Database
↓
External Services
↓
AI Integration
↓
Error Handling
↓
Deployment

That's backend engineering.

And AI becomes another service that the backend integrates with.

Prompt Engineering Is Only One Piece

Before building these projects, I thought a lot about prompts.

After building them, I realized that prompt engineering is only one part of the problem.

A better mental model is:

Good Input
+
Good Context
+
Good Prompt
+
Good Backend Logic
=
Better AI Application

If the application sends poor or incomplete context, even a great model can produce a poor result.

Product Thinking Matters

When you're following a tutorial, the goal is usually:

Make the application work.

When you're building your own product, the questions change.

You start asking:

Who is going to use this?
What problem does it solve?
Why would someone use this instead of another tool?
What happens when something fails?
How can I make it easier to use?
What features should I add later?

Those questions changed the way I approach development.

Don't Build Features Just Because You Can

One of the easiest mistakes when building side projects is adding too many features.

You start with:

"I'll build an AI code reviewer."

Then suddenly you're planning:

Authentication
Teams
Billing
Analytics
Notifications
Dashboards
Admin panels
Multiple AI providers
Ten different integrations

And the original product never gets finished.

I've learned to ask:

Does this feature solve the core problem?

If the answer is no, it can wait.

A Working Product Is More Valuable Than a Huge Project

I would rather have:

3 small working products

than:

1 huge unfinished application.

These projects also taught me that a project doesn't need 50 features to demonstrate engineering ability.

A relatively small application can demonstrate:

API design
Backend architecture
External integrations
AI integration
File processing
Error handling
Business logic
Deployment
Product thinking

That's already a lot.

The Tech Stack

Across these projects, my focus was primarily on the backend ecosystem I'm comfortable with.

Backend
Java
Spring Boot
REST APIs
Spring-based backend architecture
AI
AI APIs / LLM integration
Prompt design
Context preparation
AI-generated responses
Integrations
GitHub APIs
File/document processing
External services
Development
Maven
Git/GitHub
API testing
Logging
Configuration management

The exact implementation differs between the projects, but the common idea is the same:

Use Spring Boot as the application layer that connects users, business logic, external services, and AI.

What I Would Do Differently Next Time

If I started these projects again, I would spend more time on architecture before writing the first line of code.

I'd ask:

What is the core problem?
↓
What is the minimum useful product?
↓
What APIs do I need?
↓
What data do I need?
↓
Where does AI actually add value?
↓
How should the components communicate?
↓
How will I deploy it?

This prevents a project from turning into a collection of random features.

What's Next?

I'm not planning to stop at these three.

The next step is to take what I learned from these projects and build more practical backend tools around Java, Spring Boot, AI, and databases.

I'm particularly interested in projects that solve problems developers actually face.

Because my goal isn't simply:

"Build another AI project."

My goal is:

Build useful software and learn the engineering behind it.

Final Takeaway

Building these three products changed the way I look at AI development.

I started with:

"How do I integrate AI into a Spring Boot application?"

And ended up thinking much more about:

"How do I build a useful product where AI is actually part of the solution?"

That's a much more interesting question.

The AI model is only one component.

The real engineering challenge is everything around it.

And that's exactly the part I want to keep exploring.

The 3 Products

🤖 AI Code Reviewer for GitHub Pull Requests
Analyze Pull Request changes and generate AI-powered code review feedback.

📄 AI Resume Analyzer
Analyze resumes and provide AI-powered feedback and improvement suggestions.

💬 Self-Hosted AI Support Widget
Build an AI-powered support experience that can be self-hosted without relying entirely on a monthly SaaS platform.

If you're also a Java/Spring Boot developer experimenting with AI, I'd love to hear what you're building.

What would you build with Spring Boot + AI?

Drop it in the comments 👇

🔗 Projects

GitHub: [https://github.com/Sweety717/]

Project 1 — AI Code Reviewer: [https://swarnalata25.gumroad.com/l/codeguard-ai]

Project 2 — AI Resume Analyzer: [https://swarnalata25.gumroad.com/l/resumeiq-ai]

Project 3 — Self-Hosted AI Support Widget: [https://swarnalata25.gumroad.com/l/supportai-springboot]

I Built My Own AI Code Reviewer for GitHub Pull Requests

Swarna — Tue, 11 Aug 2026 10:33:47 +0000

# I Built My Own AI Code Reviewer for GitHub Pull Requests

Code reviews are important.

But let's be honest — they can also become repetitive.

Someone opens a pull request.

A reviewer has to go through dozens of changed files.

Then comes the usual checklist:

Is there an obvious bug?
Is there a security issue?
Is this database query going to cause a performance problem?
Is there duplicated or unnecessary code?
Is there a better way to implement this?
Did we introduce something that will break later?

And when the PR is large, reviewing everything carefully becomes difficult.

So I decided to build something for this problem.

Meet CodeGuard AI — a self-hosted AI code reviewer for GitHub Pull Requests.

The idea is simple:

Give it a GitHub PR → let AI inspect the diff → get a structured code review directly on GitHub.

And because I wanted this to be a developer-owned tool, it is designed to run on your own infrastructure and use your own AI provider.

## What is CodeGuard AI?

CodeGuard AI is a Spring Boot application that automatically reviews GitHub Pull Requests using an AI model.

It can analyze a PR for things like:

🐛 Bugs
🔐 Security issues
⚡ Performance problems
📐 Best-practice violations
🗄️ Database-related issues
💡 Improvement suggestions

Instead of returning a huge block of AI-generated text, the review is structured around findings.

For example:

CRITICAL
SecurityConfig.java

Disabled CSRF on Session-Cookie Authentication

CSRF protection is disabled while the application
uses session cookies for authentication.

Suggested fix:
Enable CSRF protection using a CookieCsrfTokenRepository
or switch to stateless header-based authentication.
The goal isn't to replace human reviewers.

The goal is to give them a useful first pass before they spend time going through the PR themselves.

Why I built it

There are already many AI coding tools.

AI can write code.

AI can explain code.

AI can generate tests.

So I was interested in a slightly different question:

What happens if AI becomes the first reviewer instead of the programmer?

A pull request already contains something extremely valuable for an AI model:
the change itself.

You don't necessarily need to understand the entire application to start finding potential problems.

You can start with:
PR
↓
Changed files
↓
Diff
↓
AI analysis
↓
Structured findings
↓
Developer
That became the core idea behind CodeGuard AI.

How CodeGuard AI works
The architecture is intentionally simple.
GitHub
│
│ Pull Request
▼
┌─────────────────────┐
│ GitHub Webhook │
│ Receiver │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ PR / Diff Fetcher │
│ GitHub API │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Code Review Service │
└──────────┬──────────┘
│
▼
┌─────────────────────────┐
│ AI Provider Abstraction │
└──────┬──────┬──────┬───┘
│ │ │
OpenAI Gemini Ollama
│ │ │
└──────┴──────┘
│
▼
┌─────────────────────┐
│ Structured Review │
│ Findings │
└──────────┬──────────┘
│
┌──────┴───────┐
▼ ▼
Dashboard GitHub PR

The application is built with:

Java 17
Spring Boot
Spring Security
GitHub REST API
REST APIs
HTML/CSS/Vanilla JavaScript
OpenAI / Gemini / Ollama integrations
Maven

Step 1: GitHub sends the Pull Request
CodeGuard AI exposes a GitHub webhook endpoint.
For example:
POST /webhook/github
When a pull request is opened, reopened, or updated, GitHub sends an event to CodeGuard AI.
The webhook signature is verified using HMAC-SHA256 before processing the request.
This is important because you don't want arbitrary requests triggering your review pipeline.
Step 2: Fetch the Pull Request
Once the webhook is verified, CodeGuard AI uses the GitHub API to retrieve information about the PR.

This includes things such as:

Repository
Pull request number
Author
Changed files
Diff
Added lines
Deleted lines

The important part is the diff.

Instead of blindly sending an entire repository to an AI model, the reviewer focuses on the code that actually changed.

Step 3: Send the changes to the AI
The diff is then passed to the configured AI provider with a structured review prompt.
CodeGuard AI supports multiple providers:
OpenAI
Google Gemini
Ollama

The provider can be selected through configuration.
For example
ai.provider=openai
or:
ai.provider=gemini
or:
ai.provider=ollama
This provider abstraction was an important design decision.
I didn't want the entire application tightly coupled to a single AI vendor.

Step 4: Generate structured findings
The AI isn't simply asked:
"Review this code."
Instead, the review is structured around useful information.
A finding contains concepts such as:
Severity
Category
File
Location
Problem
Suggested Fix

For example:
Severity: HIGH

Category: SECURITY

File:
src/main/java/com/example/config/SecurityConfig.java
Problem:
CSRF protection is disabled while session cookies
are used for authentication.
Suggested Fix:
Enable CSRF protection or switch to stateless
authentication.
This makes the result much easier to consume in a dashboard or GitHub comment.
Step 5: Post the review back to GitHub
One of the things I wanted from the beginning was:
Don't make developers open another dashboard just to read the review.
So CodeGuard AI can post the generated review directly to the Pull Request.
The result looks something like:
🤖 CodeGuard AI Review

✅ SAFE TO MERGE

Quality score: 9/10
Risk: Low
Confidence: 95%

No issues found.

What's good:

Clean implementation
Backward-compatible configuration
Clear separation of concerns If problems are found, the review instead highlights them with severity and suggested fixes. The dashboard

The dashboard provides a second way to run and inspect reviews.

You can manually enter:

owner/repository
PR number

and run a review.

This is useful before setting up the webhook because you can test the entire pipeline manually:

GitHub
↓
Fetch PR
↓
Analyze diff
↓
AI
↓
Generate review
↓
Post comment

No webhook is required for the initial test.

Review history

I also wanted the application to remember previous reviews.

The dashboard therefore keeps review history containing information such as:

Repository
PR number
Review score
Risk
Number of findings
Files reviewed
Lines changed
Review timestamp

This makes it possible to see how a codebase is progressing over time.

For example:

Review #1 6/10 3 issues
Review #2 7/10 2 issues
Review #3 9/10 0 issues

The dashboard can also visualize review trends.

One interesting feature: merge recommendation

I added a simple high-level verdict to make the review easier to understand.

For example:

┌──────────────────────────────┐
│ ✅ SAFE TO MERGE │
└──────────────────────────────┘

Quality Score: 9/10
AI Confidence: 95%
Critical Issues: 0
Suggestions: 0

Or, when the PR has serious issues:

┌──────────────────────────────┐
│ ⚠️ REVIEW REQUIRED │
└──────────────────────────────┘

Quality Score: 6/10
Risk: Medium
Critical Issues: 1

This isn't intended to replace a team's merge policy.

It's simply a quick signal for the developer.

Why self-hosted?

This was probably the most important product decision.

There are already hosted AI code-review products.

So why build another one?

Because some developers and teams don't want their source code going through another hosted SaaS platform.

With a self-hosted architecture:

Your GitHub
↓
Your CodeGuard instance
↓
Your AI provider

You control the infrastructure and credentials.

You can use:

OpenAI
Google Gemini
Ollama

And with Ollama, you can even run a local model.

The application doesn't require a CodeGuard-managed AI subscription.

Private repositories

CodeGuard AI isn't limited to public repositories.

The GitHub Personal Access Token used by the application determines which repositories it can access.

For example, a fine-grained token can be configured with the required permissions for the repositories that need to be reviewed.

This makes the same architecture usable for private projects and internal repositories.

Handling large Pull Requests

There is an obvious problem with AI-based code review:

What happens when a PR contains hundreds of files?

Sending an enormous diff to an AI model isn't practical.

CodeGuard AI therefore truncates large per-file diffs to keep the review within a reasonable token budget.

That means extremely large PRs may receive a partial review rather than causing the entire review process to fail.

This is one area I want to improve further.

What I deliberately didn't build yet

One thing I intentionally kept out of the first version is inline GitHub review comments.

Currently, CodeGuard AI posts a structured summary comment to the Pull Request.

Inline comments are more complicated because GitHub's review API requires calculating the appropriate diff positions.

So a future version could potentially do this:

src/main/java/UserService.java:42

🔴 HIGH

Potential authorization bypass.

Suggested fix:
Verify that the authenticated user owns
the requested resource before updating it.

That would make the tool much closer to a traditional human code review.

What I learned building it

The interesting part of this project wasn't actually calling an AI API.

That part is relatively straightforward.

The harder part is building the system around it.

A useful AI developer tool needs:

Reliable input

The model is only as useful as the code context you provide.

Structured output

A giant paragraph isn't particularly useful during a code review.

Provider abstraction

AI providers change quickly, so coupling the application to one provider isn't ideal.

Security

GitHub tokens, webhook secrets and AI API keys need to be handled carefully.

Failure handling

GitHub API failures, AI timeouts, invalid model responses and huge diffs all need to be considered.

A useful UI

Developers shouldn't have to dig through logs to understand what happened.
**
Current feature set**

The current version includes:

✅ GitHub Pull Request integration
✅ GitHub webhook support
✅ HMAC webhook verification
✅ Manual PR review
✅ AI-powered bug detection
✅ Security analysis
✅ Performance analysis
✅ Best-practice analysis
✅ Risk assessment
✅ Quality scoring
✅ AI confidence score
✅ Structured findings
✅ Suggested fixes
✅ GitHub review comments
✅ Review history
✅ Review trend visualization
✅ Markdown export
✅ PDF export
✅ OpenAI support
✅ Google Gemini support
✅ Ollama support
✅ Light/dark mode
✅ Self-hosted deployment

What's next?
There are several things I want to explore next.

Inline review comments

Instead of one summary comment, report findings directly on changed lines.

GitHub App support

The current version uses a Personal Access Token because it keeps the self-hosted setup simple.

A GitHub App would be a better architecture for multi-repository and multi-organization deployments.

Better repository configuration

Allow teams to define their own review rules.

For example:

security:
enabled: true

performance:
enabled: true

tests:
required: true

style:
enabled: false
Custom review prompts

Different teams care about different things.

A Spring Boot backend team may care heavily about:

N+1 queries
transaction boundaries
authentication
authorization
database indexes
API design

A frontend team may care about completely different things.

CI/CD integration

Another direction is running CodeGuard AI directly inside CI pipelines.

Final thoughts

I started CodeGuard AI with a simple idea:

AI shouldn't only help us write code. It can also help us question the code we just wrote.

The goal isn't to replace experienced engineers.

A good human reviewer can understand business context, architecture and trade-offs that an AI model may completely miss.

But an AI reviewer can be a useful first layer.

It can catch obvious issues.

It can point out suspicious code.

It can identify things worth discussing.

And it can do that before the human reviewer spends 30 minutes reconstructing what changed.

That's what I'm trying to build with CodeGuard AI.

Try it / explore the project

CodeGuard AI is built as a self-hosted Spring Boot application with the complete source code included.

If you want to run your own instance, you can configure it with your own OpenAI, Gemini, or Ollama setup.

CodeGuard AI — Self-Hosted GitHub AI Code Reviewer

# CodeGuard AI### Self-hosted AI code review for GitHub Pull Requests — built with Spring Boot.CodeGuard AI automatically reviews your GitHub Pull Requests using AI and identifies potential bugs, security issues, performance problems, and best-practice violations.Instead of paying for another monthly SaaS subscription, run CodeGuard AI on your own infrastructure using your own AI provider credentials.## 🚀 What You Get- 🤖 AI-powered GitHub Pull Request reviews- 🐛 Bug and logic issue detection- 🔐 Security issue detection- ⚡ Performance analysis- ✅ Best-practice checks- 📊 Quality score and risk assessment- 🎯 AI confidence score- 💬 Automatic review comments posted directly to GitHub- 🔄 Automatic reviews through GitHub webhooks- 📝 Manual PR review from the dashboard- 📚 Review history- 📈 Review trend tracking- 📄 Export reviews to Markdown and PDF- 🌙 Light and dark mode- 🔌 Multiple AI providers## 🔌 Supported AI ProvidersChoose the provider that works best for you:- OpenAI- Google Gemini- Ollama (local AI)Your AI provider can be changed through configuration without changing the core review architecture.## 🛠️ Technology Stack- Java 17+- Spring Boot- Spring Security- GitHub REST API- AI provider integrations- REST APIs- HTML / CSS / Vanilla JavaScript- Maven## 🔐 Self-Hosted & PrivateCodeGuard AI is designed to run in your own environment.Your GitHub credentials and AI API keys stay under your control.It can be used with repositories your GitHub token has permission to access, including private repositories when the token has the required permissions.## 📦 What's IncludedThe download includes:- Complete Spring Boot source code- Installation Guide- User Manual- API Documentation- Architecture Diagram- Database Schema- SQL database script- Postman Collection- Environment Configuration Guide- Sample Repository Guide- Changelog- License## ⚡ How It WorksGitHub Pull Request↓GitHub Webhook↓CodeGuard AI↓Fetch PR Changes↓AI Analysis↓Security / Bug / Performance Review↓Quality & Risk Assessment↓GitHub Review Comment## 🎯 Who Is This For?CodeGuard AI is ideal for:- Java / Spring Boot developers- Backend developers- Solo developers- Small development teams- Freelancers- Developers building internal developer tools- Anyone who wants an AI-assisted code review system they can run themselves## 💡 Why Buy the Source Code?This isn't just a demo UI.You get the complete backend implementation and supporting documentation so you can:- Run it locally- Deploy it on your own server- Customize the review logic- Change the AI provider- Modify the dashboard- Extend the GitHub integration- Build additional features on top of it## ⚠️ Requirements- Java 17+- Maven 3.8+- GitHub Personal Access Token- OpenAI, Gemini, or Ollama- A GitHub repository/PR accessible by your configured tokenDetailed setup instructions are included in the download.---### Build on top of it. Customize it. Self-host it.One-time purchase. No CodeGuard AI subscription required.

<div class="color-secondary fs-s flex items-center"> <img alt="favicon" class="c-embed__favicon m-0 mr-2 radius-0" src="https://public-files.gumroad.com/v56byb8cpoecdju06otk8bb7y66g" loading="lazy" /> swarnalata25.gumroad.com </div> </div> </div>

I'd especially love feedback on:

What should an AI code reviewer detect?
Would you use a self-hosted reviewer?
Which AI provider would you prefer?
Are inline GitHub comments more useful than a single summary?
What would make this useful for your team?

Thanks for reading! 🚀

I Built an AI Resume Analyzer in Spring Boot Instead of Another CRUD Project

Swarna — Sat, 08 Aug 2026 05:17:44 +0000

I Built an AI Resume Analyzer in Spring Boot Instead of Another CRUD Project

After finishing my previous AI Support Widget project, I wanted to build something that solved a different real-world problem.

Most developers have built a Todo app, an Employee Management System, or another CRUD project.

I wanted to build something people could actually use.

So I spent the last few weeks building an AI-powered Resume Analyzer using Spring Boot.

## The idea

Whenever I apply for jobs, I usually wonder:

Is my resume ATS friendly?
Which keywords am I missing?
Which resume version is better?
How can I improve my chances before applying?

There are plenty of online tools, but I wanted a self-hosted application that I fully controlled.

## Tech Stack

Java 17
Spring Boot 3
Spring Security
Spring Data JPA
Thymeleaf
MySQL
OpenAI API

## What it does

Instead of simply uploading a resume and getting one score, the application provides multiple AI-powered features.

### ATS Resume Analysis

The application analyzes a resume against a job description and generates:

ATS score
Resume strengths
Weaknesses
Missing keywords
Resume improvement suggestions

### AI Resume Rewrite

Instead of manually editing bullet points, the application rewrites the resume while preserving the candidate's actual experience.

The goal isn't to invent achievements.

It's to improve clarity and ATS readability.

### Resume Comparison

One feature I personally found useful was comparing two versions of the same resume.

Sometimes changing only a few bullet points increased the ATS score significantly.

### Resume Versioning

Rather than replacing previous analyses, every analysis is saved.

This allows users to compare improvements over time.

### AI Interview Preparation

After analyzing the resume, the application can generate interview questions based on:

Resume
Skills
Experience
Job Description

This makes the tool useful even after the ATS analysis is complete.

### Dashboard

The application also includes a dashboard showing:

Previous analyses
Average ATS score
Highest score
Resume history
Trends over time

## Challenges

One interesting challenge was balancing AI output with predictable scoring.

Large Language Models are creative, but ATS scoring should feel consistent.

I ended up combining deterministic scoring with AI-generated explanations so that users receive both a measurable score and useful feedback.

## What I intentionally didn't build

One thing I deliberately left out was payment gateway integration.

The application already supports usage limits and user plans, but checkout integration (Stripe/Razorpay) is something I'd rather let developers integrate based on their own business needs.

## Lessons Learned

Building AI products isn't just about calling an LLM.

Most of the work is actually:

Prompt engineering
Designing good workflows
Managing user data
Producing useful outputs
Creating a smooth user experience

Those parts took far longer than integrating the OpenAI API itself.

## Final Thoughts

This project taught me much more than another CRUD application ever could.

I'm now building a collection of AI-powered Spring Boot applications focused on solving real business problems instead of tutorial-style examples.

If you're building AI products with Java or Spring Boot, I'd love to hear what you're working on.

### Source Code

I packaged this project as a complete Spring Boot source code product with documentation, database scripts, API collection, installation guide, and production-ready architecture.

If you'd like to build on top of it instead of starting from scratch, you can check it out here:

👉 https://swarnalata25.gumroad.com/l/resumeiq-ai

I'd also love your feedback on what features you'd add next.

I Built a Self-Hosted AI Support Widget with Spring Boot (No Monthly SaaS Fees)

Swarna — Fri, 07 Aug 2026 15:19:16 +0000

Every new SaaS seems to embed ChatGPT these days.

Most AI support solutions rely on third-party platforms, monthly subscriptions, and vendor lock-in. While they're great products, I wanted something different.

I wanted complete ownership.

I wanted to deploy everything on my own server, use my own OpenAI API key, customize every part of the experience, and embed the widget into any website with a single script tag.

So I built my own self-hosted AI support widget using Spring Boot and Vanilla JavaScript.

Why I Built It

When building small products and websites, I realized that customer support quickly becomes a problem.

Users have questions about pricing, features, returns, or simply get stuck.

Most developers solve this by integrating services like Intercom, Crisp, or Tidio.

Those platforms are excellent, but they also mean:

Monthly subscription costs
Vendor lock-in
Customer conversations stored on third-party platforms
Limited customization
Another external dependency

I wanted something that developers could completely own.

The Goal

The goal was simple.

Build an AI-powered customer support widget that developers can deploy on their own server and integrate into any website in less than a minute.

The widget should:

Answer customer questions using AI
Learn from a custom knowledge base
Match the company's branding
Store conversation history
Allow human handoff
Be easy to deploy
Require only one script tag to embed

Technology Stack
Java 17
Spring Boot 3
Spring Security
Spring Data JPA
Thymeleaf
Vanilla JavaScript
H2 Database (MySQL supported)
OpenAI API

Architecture

The overall architecture is intentionally simple.
Visitor
│
▼
AI Chat Widget
(Vanilla JavaScript)
│
▼
Spring Boot REST API
│
▼
OpenAI API
│
▼
Database
(H2 / MySQL)
Keeping the frontend framework-free makes the widget lightweight and easy to embed into virtually any website.

One-Line Integration

Adding the widget to a website only requires a single script.
<script src="/widget/widget.js" data-api-base=""></script>
No React.

No Vue.

No npm packages.

Just one script.

Features I Built

The project includes:

✅ AI-powered customer support

✅ Spring Boot backend

✅ Secure admin authentication

✅ Custom knowledge base

✅ Conversation history

✅ Brand customization

✅ Human handoff with email notification

✅ OpenAI API configuration

✅ H2 support with MySQL production configuration

✅ One-line website integration

The Admin Dashboard

Instead of hardcoding prompts inside the application, administrators can configure everything from the dashboard.

They can update:

Company name
Greeting message
Brand color
OpenAI API key
Knowledge base
Notification email

Changes take effect immediately without restarting the application.

Why I Didn't Use RAG

One interesting design decision was intentionally not implementing Retrieval-Augmented Generation (RAG).

Instead, administrators maintain a simple knowledge base that is included in the AI's system prompt.

For small and medium-sized businesses, this approach keeps deployment extremely simple while still delivering accurate responses.

If the project grows, adding vector search later is straightforward.

Sometimes simplicity is the better engineering decision.

Human Handoff

AI can't answer everything.

Whenever visitors need human assistance, they can submit their email.

The system:

Stores the lead in the database
Sends an email notification (if SMTP is configured)
Lets administrators continue the conversation manually

This ensures users never hit a dead end.

Lessons Learned

Building the OpenAI integration wasn't actually the hardest part.

The real engineering challenges were:

Designing a flexible architecture
Authentication and authorization
Conversation persistence
Prompt management
Making the widget framework-independent
Creating an admin experience that non-developers can use

Those pieces ended up being much more interesting than simply calling an AI API.

Things I Intentionally Left Out

Every project needs boundaries.

I intentionally skipped:

Multi-tenancy
Stripe subscriptions
Vector databases
Multiple AI providers
Complex AI orchestration

The goal was to build a clean, understandable codebase that developers can deploy quickly and extend however they like.

What's Next?

I'm considering adding:

Streaming AI responses
Multiple AI providers
RAG support
File uploads
Conversation analytics
Multi-tenant architecture

Final Thoughts

This project reminded me that building AI products isn't just about connecting to an LLM.

The real engineering happens around it:

authentication
configuration
deployment
usability
persistence
developer experience

Those are the parts that transform an API call into a real product.

I'd love to hear how you're building AI applications with Java or Spring Boot, and what features you would add to a self-hosted support widget.

Interested in the Full Project?

I built this as a complete, production-ready Spring Boot project. If you'd like the full source code, setup guide, and deployment instructions, you can find it here:

👉(https://swarnalata25.gumroad.com/l/supportai-springboot)

I'm also building more self-hosted Java & Spring Boot products, so feedback and suggestions are always welcome.