DEV Community: Aman Thakur

🚀 Stop Rebuilding Chat Widgets: Add a Fully Customizable Chatbot to Any Website in Minutes

Aman Thakur — Tue, 28 Jul 2026 10:57:34 +0000

We've all seen those chatbot widgets on websites.

Whether it's customer support, FAQs, AI assistants, or lead generation, almost every modern website has one.

The problem?

Integrating a chatbot is usually more complicated than it should be.

You have to create floating widgets.
Handle UI and animations.
Manage sessions.
Make it responsive.
Configure themes.
Connect it with your backend.

I wanted something much simpler.

So I built @hey-amanthakur/chat-bot.

Why I Built It

While working on projects, I repeatedly found myself rebuilding the same chatbot UI.

Every project required:

Floating launcher button
Chat window
Message rendering
Responsive design
Theme customization
Backend integration

Instead of copying code between projects, I decided to package everything into a reusable npm library.

✨ Features

🚀 Plug-and-play integration
🎨 Fully customizable appearance
📱 Mobile responsive out of the box
⚡ Lightweight with minimal setup
🔌 Connect to any backend or AI model
🧩 Works with React, Next.js, Vue or Vanilla JavaScript
💬 Floating chat widget with modern UI
🌙 Theme support
📦 Install from npm in seconds
🛠️ Developer-friendly API 🎯 Production-ready

Most "AI chatbot" products for small businesses are SaaS platforms: sign up, wait for approval, pay monthly, get locked into their dashboard. I wanted something a developer could just npm install, point at a business's info, and drop into a client's website the same afternoon.

So I built @hey-amanthakur/chat-bot — an embeddable chatbot widget + backend that answers questions using only a business's own services, hours, and FAQs. No database, no dashboard, no vendor lock-in.

The problem

If you build websites for local businesses (dentists, salons, clinics, studios), you've probably been asked for a "chat with us" feature. Your options are usually:

A generic support-widget SaaS that costs $30-100/mo and doesn't know anything about the business
Building a custom bot from scratch with a vector DB, embeddings, and a whole backend
Ignoring it and hoping the contact form is enough I wanted a middle path: a small server you run yourself (or deploy anywhere), configured with plain JS objects, that any client site can embed with a single <script> tag.

Quick start

Install it:

npm install @hey-amanthakur/chat-bot

Configure and start the server:

import { ChatBot } from '@hey-amanthakur/chat-bot';

ChatBot.start({
  port: 3000,
  openrouterKey: 'sk-or-v1-xxxxx',
  clients: {
    'my-business': {
      name: 'My Business',
      greeting: 'Hi! How can I help you today?',
      services: [
        { name: 'Consultation', price: '$50', description: 'Initial consultation' },
      ],
      hours: [
        { day: 'Monday', open: '9:00 AM', close: '5:00 PM' },
      ],
      faqs: [
        { question: 'Do you accept insurance?', answer: 'Yes, we accept most major plans.' },
      ],
    },
  },
});

Drop the widget into the client's HTML:

<script
  src="http://localhost:3000/widgets/chat-widget.min.js"
  data-client-id="my-business"
  data-color="#2563eb"
  data-icon="🦷"
  data-header="Talk to us"
  data-position="bottom-right"
></script>

That's it — a styled chat bubble shows up, and visitors can ask about pricing, hours, or anything in the FAQ.

Why OpenRouter instead of hardcoding OpenAI

The bot uses OpenRouter under the hood, which means you're not locked into one model. Swap model: 'openai/gpt-4o' for any supported model per client — some clients might be fine on a free/cheap model, others might want something stronger.

Multiple clients on one server

This was important for my use case: I build sites for multiple small businesses, and I didn't want to spin up a separate server for each one. One ChatBot.start() call can serve several clients, each with its own isolated knowledge base and chat context:

ChatBot.start({
  port: 3000,
  openrouterKey: 'sk-or-v1-xxxxx',
  clients: {
    'dr-smith-dental': {
      name: 'Dr. Smith Dental',
      model: 'openai/gpt-4o',
      services: [{ name: 'Teeth Cleaning', price: '$120', description: 'Professional cleaning' }],
    },
    'style-studio-salon': {
      name: 'Style Studio Salon',
      services: [{ name: 'Haircut', price: '$45', description: 'Professional haircut' }],
    },
  },
});

Each site just points its widget script at its own data-client-id, and the bot only ever answers using that client's data — it won't leak Dr. Smith's pricing into Style Studio's chat window.

How a message actually flows

Widget loads → chat bubble renders on the page
Visitor types a message → POST /api/chat with clientId + message
Server loads that client's config (in-memory, no DB)
A lightweight lead-detection check runs on the message
- If it looks like a lead (someone asking to book, get a quote, etc.) → the bot nudges toward contact info
- Otherwise → the message goes to OpenRouter along with the client's services/hours/FAQs as context
The model replies using only that context
Response renders in the widget with basic formatting ## Security basics, out of the box

Since this thing is meant to be embedded on real client sites, I didn't want to ship it without the obvious guardrails:

The OpenRouter API key never reaches the browser — it stays server-side
Rate limiting on every endpoint (20/min for chat, 10/min for lead submission)
Input validation — 2000 char cap per message, 10KB body limit
Configurable CORS per deployment via allowedOrigins ## Customizing the widget

The widget itself is just data-* attributes, so you can reskin it per client without touching code:

Attribute	Default	What it does
`data-color`	`#2563eb`	Bubble, header, and user message color
`data-icon`	chat bubble SVG	Emoji, image URL, or raw SVG string
`data-header`	`Chat with us`	Header title
`data-position`	`bottom-right`	Any corner of the screen
`data-greeting`	—	Overrides the configured greeting

If you'd rather not use a script tag (say, in a React or Vue app), there's also an ES module version:

import ChatWidget from '@hey-amanthakur/chat-bot/widget.esm';

new ChatWidget({
  clientId: 'my-business',
  apiUrl: 'http://localhost:3000',
  primaryColor: '#e11d48',
  icon: '💬',
  headerTitle: 'Support Chat',
  position: 'top-right',
});

Tech stack

Server: NestJS
Widget: Vanilla TypeScript, bundled with Rollup (no framework dependency for the embed)
LLM: OpenRouter (model-agnostic)
Build: Turborepo monorepo
Tests: 73 unit tests + 15 E2E tests ## Try it

npm install @hey-amanthakur/chat-bot

📦 npm package
🐙 GitHub repo
📄 MIT licensed If you build sites for small/local businesses and want a chatbot you can actually own instead of renting from a SaaS, give it a try. Issues, stars, and feedback are all very welcome — this is still early, and I'd love to know what you build with it.

The Software Engineering Job Market Has Changed. Most Candidates Haven't.

Aman Thakur — Wed, 15 Jul 2026 16:46:45 +0000

A few months ago, I started noticing a pattern.

Every day, I would come across posts from talented developers saying:

"I've applied to 500+ jobs."

"I'm getting rejected without interviews."

"I've built multiple projects, but nobody is responding."

The common assumption is that the market is bad.

While that's partially true, I don't think that's the complete story.

The software engineering landscape has fundamentally changed, and many candidates are still preparing for a market that no longer exists.

The New Reality

There was a time when learning a framework, building a few portfolio projects, and solving interview questions consistently could land you interviews.

Today, almost every applicant has:

React, Angular, Vue, or Next.js experience.
Node.js, Java, Python, or Go on their resume.
Several GitHub repositories.
A deployed portfolio.
AI-assisted projects.
ChatGPT helping with resumes and interview preparation.

The baseline has risen.

Having these skills is no longer a competitive advantage.

They're simply the expectation.

AI Didn't Replace Engineers. It Changed What Companies Value.

One of the biggest misconceptions today is that AI is replacing software engineers.

That's not what I'm seeing.

AI has dramatically reduced the effort required for routine implementation.

Need a REST API?

Generate it.

Need authentication?

Generate it.

Need boilerplate code?

Generate it.

Need tests?

AI can produce a reasonable first draft.

The repetitive parts of software development have become significantly faster.

But software engineering has never been only about writing code.

The difficult parts remain the same:

Designing scalable systems.
Making architectural trade-offs.
Understanding business requirements.
Debugging production issues.
Optimizing performance.
Ensuring security.
Making engineering decisions under uncertainty.

These are still human problems.

And they're becoming even more valuable.

Projects Alone Don't Stand Out Anymore

This might be unpopular.

Building projects is still important.

But building another Todo app, Netflix clone, ChatGPT wrapper, or e-commerce application is unlikely to make you memorable.

Why?

Because today almost anyone can build those with AI assistance.

The question recruiters are increasingly asking isn't:

"Can this person build a project?"

Instead, it's:

"Can this person solve problems we actually have?"

A project becomes interesting when it demonstrates:

Real users.
Real engineering challenges.
Performance optimizations.
Scalability decisions.
Monitoring.
Deployment.
Security considerations.
Lessons learned.

The implementation matters less than the thinking behind it.

The Resume Problem

Another challenge isn't technical.

It's visibility.

A single job posting can receive hundreds or even thousands of applications within days.

That means many qualified candidates never even receive a phone screen.

It's not always because they aren't good enough.

Sometimes their resume simply wasn't seen.

Sometimes they lacked a referral.

Sometimes timing worked against them.

This is frustrating—but it's the reality of a saturated hiring market.

Cold DMs Rarely Work

Many candidates try to solve this by sending messages like:

"Hi, can you refer me?"

Unfortunately, most of these messages never receive a response.

Not because people are rude.

Because they receive dozens of similar requests every week.

Networking isn't about collecting referrals.

It's about building relationships before you need help.

Contribute to discussions.

Share what you're learning.

Help others.

Write technical content.

Participate in open source.

People are far more willing to refer someone they recognize than someone they've never interacted with.

What Makes Engineers Stand Out in 2026?

If coding has become easier, then what actually differentiates engineers?

From what I've observed, companies increasingly value people who can:

Design systems instead of just implementing them.
Explain technical decisions clearly.
Work across product and engineering.
Debug complex issues.
Understand trade-offs.
Learn quickly.
Use AI effectively without depending entirely on it.
Take ownership from idea to production.

Coding remains essential.

But coding alone is no longer enough.

Advice for Developers Looking for Jobs

If you're currently applying and not getting responses, don't immediately assume you're not good enough.

Instead, ask yourself:

Am I solving problems or just building tutorials?
Can I explain why I designed something a certain way?
Do I understand system design?
Can I communicate my decisions?
Am I using AI as a productivity tool rather than letting it think for me?
Does my resume show impact rather than technologies?

The answers to these questions often matter more than adding another framework to your resume.

Final Thoughts

The job market is undeniably tougher than it was a few years ago.

But I don't believe software engineering is dying.

It's evolving.

The role is shifting away from simply writing code toward designing systems, making informed decisions, collaborating effectively, and solving meaningful problems.

AI is accelerating development.

It isn't eliminating the need for thoughtful engineers.

The developers who adapt to this shift won't just survive—they'll become significantly more valuable.

What changes have you noticed in the hiring process over the last couple of years?

I'd love to hear perspectives from both candidates and hiring managers.

From a CMS in a College Dorm to Full Stack Engineering: My First Two Years in Tech

Aman Thakur — Sun, 12 Jul 2026 04:40:32 +0000

I still remember the first time I saw a production bug crash right in front of a client, live, during a demo. My hands went cold. That was in 2021, during my internship at Deep Info Lab, and it taught me more about engineering in five minutes than any semester of college had.

This is the story of how I got from there to here — not a highlight reel, but the actual path, mistakes included.

Where it started: a CMS and a lot of late nights

I built my first real production feature as an intern — a Content Management System using Django Rest Framework and React. It sounds simple written out like that. It wasn't. I was learning JWT authentication, request routing, and Nginx configuration at the same time as I was supposed to be shipping the thing.

What I remember most isn't the tech stack, though. It's the moment our CEO personally acknowledged the work. That's when something clicked for me: good engineering isn't about knowing every tool going in. It's about being willing to sit with the discomfort of not knowing, and figuring it out anyway, on a deadline, with people depending on you.

Learning that frontend and backend aren't separate worlds

At floc, I stepped into Flutter and Firebase to build a real-time social discovery app. It was my first time owning something end-to-end — design, auth, testing, deployment. I set up CI/CD with Docker and GitHub Actions for the first time, mostly by trial, error, and an unreasonable number of tabs open on Stack Overflow.

Looking back, this was the internship where I stopped thinking of myself as "a frontend person" or "a backend person." I was just someone trying to make something work end to end. That mental shift mattered more than any specific skill I picked up.

The projects that actually taught me to think in systems

Smarter.Codes had me building data analytics interfaces — dashboards that had to make sense of messy business data at a glance. Smarter.Codes had me shipping across three different production products simultaneously: Hybrid.Chat, NayakAI, and TalkingDB. Different codebases, different constraints, same underlying question every time: how do you build something that won't fall apart in six months?

This is where I really started caring about architecture. I refactored backend logic chains that had grown so nested nobody wanted to touch them. I built an NLP pipeline that had to parse multi-turn conversations and pull structured meaning out of them. None of it was glamorous. All of it taught me that the unglamorous work — the refactor nobody asked for, the test suite nobody wanted to write — is usually the work that actually matters a year later.

Where I am now

Today, at eQ Technologic, I spend my time on things that would have felt out of reach two years ago: leading refactors across legacy modules, building internal tooling that other engineers rely on, sitting in sprint planning and actually having opinions worth sharing. I've gone from being the person asking "how do I even start this" to being someone junior engineers sometimes ask that question to.

I'm not writing this because I think I've figured it all out. I'm writing it because two years ago, I would have loved to read something like this — not a highlight reel, just an honest account of what the climb actually looks like.

What I'd tell someone starting out

A few things I wish someone had told me directly, instead of me learning them the hard way:

The unglamorous work is often the most valuable work. Nobody hands out awards for a clean refactor, but everyone feels the pain when it doesn't happen.
Ownership matters more than expertise. I learned more from owning a feature I didn't fully understand than from being handed tasks in a domain I already knew.
Ask for the "why," not just the "how." Understanding why a system is built a certain way will teach you system design faster than any course will.
Ship on a deadline, then go back and make it better. Perfection before shipping is usually just fear wearing a productivity costume. I'm currently exploring SDE 2 opportunities where I can keep building on this — deeper system design, more ownership, more mentoring. If any part of this journey resonates with you, or you're earlier in yours and want to compare notes, I'd love to hear from you.

I'm Aman Thakur, a Full Stack Software Engineer working with React.js, Node.js, and NestJS. You can find me on LinkedIn or GitHub.