DEV Community: Soumyajit Mukherjee

10 Corporate Culture Myths Every Developer and Professional Should Question

Soumyajit Mukherjee — Sun, 11 Oct 2026 07:36:53 +0000

Corporate culture isn't just an HR topic. It influences how developers collaborate, how teams handle production incidents, how managers evaluate performance, and how people grow throughout their careers.

Whether you're a fresher, a mid-level developer, a senior engineer, or a team lead, you've probably encountered some workplace assumptions that don't always hold up in reality.

Let's discuss ten of them.

1. Hard Work Always Gets Recognized

Writing more code, resolving more tickets, or staying late doesn't guarantee recognition.

Your impact matters, but so do communication, visibility, team priorities, and the way your organization evaluates performance.

Developer takeaway: Document important contributions, explain the problems you solved, and communicate measurable outcomes without exaggerating your role.

2. More Hours Mean More Productivity

A developer working late isn't necessarily more productive than someone who finishes focused work during regular hours.

Long hours can sometimes indicate unclear requirements, excessive meetings, technical debt, or unrealistic deadlines.

Developer takeaway: Measure progress through quality, reliability, maintainability, and outcomes—not commits, online status, or hours logged.

3. Seniority Automatically Means Better Decisions

A senior engineer has valuable experience, but experience doesn't make every architectural decision correct.

Technology changes, requirements evolve, and yesterday's best solution may not fit today's constraints.

Developer takeaway: Respect experience, ask for reasoning, evaluate trade-offs, and use evidence to guide technical decisions.

4. Company Loyalty Guarantees Career Security

A developer can contribute for years and still face restructuring or project cancellations.

That doesn't mean loyalty is pointless. It means your career shouldn't depend entirely on one employer.

Developer takeaway: Build transferable skills, maintain a portfolio where appropriate, understand modern tools, and cultivate professional relationships.

5. A Company's Reputation Guarantees a Healthy Team

A respected technology company can have excellent teams and challenging teams at the same time.

Your direct manager, team processes, workload, psychological safety, and engineering practices shape your daily experience.

Developer takeaway: When evaluating an opportunity, ask how code reviews work, how incidents are handled, and how priorities are decided.

6. Promotions Are Based Only on Technical Skill

Technical excellence is important, but career progression may also involve communication, mentoring, collaboration, decision-making, and business impact.

The expectations for a senior engineer can differ significantly from those for a junior developer.

Developer takeaway: Understand your organization's promotion criteria and develop the skills expected at the next level.

7. Asking Questions Makes You Look Like a Beginner

Nobody can know every framework, codebase, design pattern, or business requirement.

Avoiding questions can lead to incorrect implementations and unnecessary rework.

Developer takeaway: Investigate first, explain what you've tried, share relevant context, and ask a precise question.

Good questions are part of good engineering.

8. Healthy Teams Never Disagree

Technical disagreements are inevitable.

Should we introduce a new dependency? Is a microservices architecture justified? Should we refactor now or deliver the feature first?

A team without disagreement isn't automatically a healthy team.

Developer takeaway: Discuss evidence, constraints, risks, and trade-offs. Critique the solution rather than attacking the person proposing it.

9. Being Busy Means Being a Valuable Engineer

A full sprint board doesn't necessarily mean a team is delivering meaningful value.

Developers can spend days switching tasks, attending meetings, and responding to urgent requests without making substantial progress.

Developer takeaway: Prioritize completed outcomes, manageable work in progress, clear requirements, and sustainable delivery.

10. Career Success Requires Constant Overwork

Sometimes a release or production incident requires extra effort. That is different from treating permanent overtime as normal.

Long-term engineering quality depends on sustainable practices, learning, collaboration, and enough time to think clearly.

Developer takeaway: Improve estimation, communicate blockers early, automate repetitive work, and help your team identify recurring sources of overtime.

What Should Engineering Teams Value Instead?

Healthy engineering cultures make room for:

Clear expectations and constructive feedback.
Technical discussions based on evidence rather than hierarchy.
Blameless learning from incidents, alongside clear accountability.
Recognition for mentoring, documentation, maintenance, and collaboration.
Sustainable workloads and realistic delivery commitments.
Continuous learning at every career stage.

These practices aren't exclusive to technology companies. They're useful wherever people collaborate to solve complex problems.

Final Thoughts

Corporate culture isn't determined by the tools a company uses or the values displayed on its careers page.

It's reflected in everyday decisions: how code reviews happen, how managers respond to mistakes, how teams resolve disagreements, and whether employees can raise concerns.

You don't need to distrust every organization. You need to evaluate its behavior instead of relying exclusively on its promises.

Good engineering requires more than technical skills. It also requires a culture where people can learn, communicate, challenge assumptions, and do meaningful work sustainably.

Let's Discuss

What's the biggest corporate culture myth you've encountered in your career?

Have you experienced a workplace where being busy mattered more than delivering results—or where asking questions was discouraged?

I'd love to hear perspectives from developers, managers, freshers, and professionals outside the tech industry.

10 Habits That Help a Junior Developer Become a Professional Engineer

Soumyajit Mukherjee — Sun, 11 Oct 2026 06:40:27 +0000

Being a junior developer doesn't mean you're a bad developer. It means you're still developing your technical judgment and professional habits.

You might already know JavaScript, React, Node.js, Express, and MongoDB. You might have several projects on GitHub.

But professional software development requires more than knowing how to build features.

Here are 10 habits you can start practicing today.

1. Understand the requirement first

Before coding, answer these questions:

What problem does this feature solve?
What input does it accept?
What output should it produce?
What can go wrong?
What does success look like?

This reduces rework and helps you build the right thing.

2. Debug with evidence

When a bug appears, avoid changing multiple things at once.

Use a repeatable process:

Reproduce the issue.
Read the error message and logs.
Identify where the behavior changes unexpectedly.
Form a hypothesis.
Test the hypothesis.
Verify the fix and check for regressions.

This approach is more reliable than guessing.

3. Write readable code

Consider this JavaScript example:

const activeUsers = users.filter(
  user => user.isActive
);

The intention is easy to understand.

Good names, focused functions, consistent formatting, and limited duplication help your teammates understand your work.

Don't optimize for the fewest characters. Optimize for clarity.

4. Learn the fundamentals behind your stack

If you're a JavaScript developer, understand asynchronous operations, promises, closures, and error handling.

If you're building APIs, understand HTTP methods, status codes, authentication, and validation.

If you're working with databases, understand relationships, indexes, and query performance.

You don't need to master every topic immediately. Learn the fundamentals that explain the behavior of the tools you're using.

5. Consider failure scenarios

A successful request is only one possible outcome.

For a typical API, think about:

Invalid request data.
Unauthorized access.
Missing resources.
Database failures.
Rate limits.
Network timeouts.

Your error handling should help the application fail safely and make problems easier to diagnose.

Never expose passwords, API keys, stack traces, or other sensitive information in public responses.

6. Use Git as a collaboration tool

A professional Git workflow might look like this:

git switch -c feature/user-profile
git add .
git commit -m "Add user profile endpoint"
git push -u origin feature/user-profile

The commands are simple. The habits matter more.

Keep commits meaningful, avoid committing secrets, review your changes before pushing, and use pull requests to explain what changed and why.

7. Test important behavior

You don't have to begin with an enormous testing suite.

Start with the most important behavior in your application.

For a registration endpoint, test valid input, invalid input, duplicate email addresses, and unexpected server failures.

Tests make assumptions explicit and help prevent existing features from breaking when you make changes.

8. Communicate blockers early

When you get stuck, explain:

What you expected to happen.
What actually happened.
What you have already tried.
What evidence you found.
What you need help understanding.

This helps others assist you without repeating the same investigation.

Asking for help is not the problem. Asking without making any effort to understand the issue is a missed learning opportunity.

9. Learn to explain trade-offs

Suppose your application is getting slower.

You could add caching, optimize database queries, paginate results, or redesign part of the system.

Which option is appropriate?

It depends on the bottleneck, workload, consistency requirements, and complexity you're willing to maintain.

Professional engineers learn to justify decisions using requirements and evidence rather than choosing technologies because they are fashionable.

10. Treat feedback as part of development

Code reviews reveal alternative approaches, potential bugs, security concerns, and opportunities to simplify.

Don't treat every comment as criticism of your ability.

Ask why a suggestion matters, evaluate it, and apply the lesson to future work.

Over time, you will begin recognizing issues before someone else needs to point them out.

A 7-day challenge

Try this mini-plan with an existing project.

Day	Task
1	Refactor one confusing function
2	Investigate and document one bug
3	Add tests for an important workflow
4	Review API validation and error handling
5	Improve Git commits and README documentation
6	Explain one architectural trade-off
7	Review the changes and write down what you learned

The purpose isn't to complete a checklist perfectly. It's to build a repeatable improvement habit.

Final takeaway

The transition from junior developer to professional engineer isn't about knowing every framework or memorizing every design pattern.

It's about developing better judgment.

Understand problems. Debug systematically. Write readable code. Test important behavior. Communicate clearly. Take ownership. Stay curious.

You don't have to be an expert today. You have to be willing to work like an engineer while you learn.

Discussion

What's one engineering habit you wish you had developed earlier? Share it in the comments so other developers can learn from your experience.

Building a Production-Style AI Telegram Bot with Node.js, Gemini, Cron and Fallbacks

Soumyajit Mukherjee — Wed, 30 Sep 2026 08:56:39 +0000

I wanted to build a small AI project that was more than:

prompt → LLM → response

So I built an AI-powered Telegram motivation bot using Node.js, Google Gemini and the Telegram Bot API.

The interesting part isn't the motivational content itself.

The interesting part is everything around the AI model:

Scheduling
Personalization
Persistent user state
Streaks
Feedback
Telemetry
Retry logic
Model fallback
Caching
Local fallback content
Protected webhooks

This article breaks down the architecture.

Tech Stack

The core stack is:

Node.js
Express.js
Telegram Bot API
Google Gemini
node-cron
dotenv
Jest

The project uses ES modules and keeps the application separated into components such as bot commands, actions, services, data management and configuration.

High-Level Architecture

The system roughly looks like this:

                    ┌─────────────────┐
                    │ Telegram User   │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Telegram Bot    │
                    │ Command Layer   │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Motivation      │
                    │ Generation      │
                    │ Service         │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    ▼                 ▼
              ┌──────────┐      ┌───────────┐
              │ Gemini   │      │ Fallback  │
              │ API      │      │ System    │
              └──────────┘      └───────────┘
                    │
                    ▼
              ┌────────────┐
              │ Telemetry  │
              └────────────┘

1. Telegram Command Layer

The bot exposes multiple commands.

Some of the main ones are:

/motivate
/today
/history
/stats
/leaderboard
/settings
/subscribe
/unsubscribe
/schedule
/set_tone
/set_language
/suggest_quote_topic

For example:

/motivate

generates an on-demand motivational message.

A user can also request a topic-specific message:

/suggest_quote_topic job interviews

The command layer initializes the user, invokes the generation service and stores the resulting data.

2. AI Generation Service

The main generation logic lives in the motivation/brain service.

The service uses the Google Generative AI SDK.

One interesting design decision is the use of multiple persona archetypes.

const personas = {
    stoic: "...",
    warrior: "...",
    philosopher: "...",
    strategist: "...",
    mentor: "...",
    elder: "...",
    survivor: "...",
    observer: "...",
    wanderer: "..."
};

If the user selects a mixed/random mode, the application can choose an archetype dynamically.

3. Multiple Generation Modalities

The application also varies how the generated message should be expressed.

The current modalities include:

RAW_REALITY
DEEP_OBSERVATION
QUIET_COMPASSION
PRAGMATIC

This is useful because prompt variation doesn't necessarily require completely different application architectures.

A small controlled set of generation dimensions can create considerably more variety.

4. Output Constraints

The prompt also places constraints on the generated content.

For example, the generation service asks the model for:

A short response
A complete standalone sentence
No unnecessary formatting
No generic AI clichés
A grounded tone

The application then trims and validates the model output before returning it.

5. Retry and Model Fallback

This is one of the parts I found most useful from an engineering perspective.

The application maintains a model priority chain.

Conceptually:

const MODEL_PRIORITY_CHAIN = [
    "primary-model",
    "fallback-model"
];

The generation function loops through the configured models and retries failures.

It also detects certain model availability/deprecation errors and can move to the next model.

This is important because AI providers change models over time.

Hard-coding one model and assuming it will always exist isn't a great long-term strategy.

6. Memory Cache

The generation service also keeps a temporary in-memory cache.

The cache is keyed around parameters such as:

language
tone
schedule
A/B variant

This means the application has another way to avoid unnecessary AI calls when an appropriate recent response already exists.

The cache also becomes useful when dealing with API rate limits or temporary upstream failures.

7. Local Fallback

What happens if the AI system fails completely?

The application can retrieve fallback content from local data.

The conceptual hierarchy is:

Gemini
   ↓
Retry
   ↓
Model fallback
   ↓
Memory cache
   ↓
Local fallback

This is a useful pattern for any application that depends on an external API.

A graceful degradation strategy is usually better than returning an error every time an external service has a problem.

8. Automated Scheduling

The bot uses node-cron.

The current schedules include:

cron.schedule('0 8 * * *', ...)
cron.schedule('0 13 * * *', ...)
cron.schedule('0 18 * * *', ...)
cron.schedule('0 19 * * 0', ...)

These correspond to:

08:00 → Morning
13:00 → Midday
18:00 → Evening
Sunday 19:00 → Weekly

The schedules use:

Asia/Kolkata

as the timezone.

The application also has an automated cleanup job.

9. Per-User Scheduling

The cron system doesn't simply broadcast every message to everyone.

It checks each user's schedule configuration.

For example:

user.schedule[scheduleType] === true

Only users who have enabled a particular dispatch period are targeted.

That creates an important separation:

Global Scheduler
       ↓
User Preferences
       ↓
Eligible Subscribers
       ↓
AI Generation
       ↓
Telegram Delivery

10. Streak Tracking

After successful dispatch, the user's streak is updated.

The project also has milestone badges.

For example:

3 days   → Rising Star
7 days   → 7-Day Believer
14 days  → Unbreakable
30 days  → Iron Will
100 days → Century Member

This turns a simple messaging bot into a stateful application.

11. Feedback Buttons

Generated messages contain inline Telegram buttons:

👍    👎

The callback handler determines whether the user voted up or down.

The application then records:

chat ID
quote
vote
A/B variant

The buttons are subsequently removed to prevent repeated submissions for the same message.

This is a small feature, but it introduces an important concept:

AI output can be treated as an experiment rather than an immutable result.

12. A/B Variant

The project also has an A/B mechanism.

The user's chat ID is used to determine the variant.

One variant receives an additional generation instruction.

This creates a simple way to compare different prompting strategies.

In a more advanced implementation, this could be replaced with a proper experiment assignment system.

13. Telemetry

The application records telemetry around generated messages.

Some tracked information includes:

event
chatId
schedulePeriod
quoteText
source
responseTimeMs
apiSuccess

This makes it possible to answer questions such as:

How long is AI generation taking?
How often is the API succeeding?
How frequently is fallback content being used?
Which scheduling period generated an event?
Which model produced the response?

Without telemetry, these questions are much harder to answer.

14. Express API

The application also starts an Express server.

One endpoint exposes recent generated quotes:

GET /api/quotes/latest

There is also a protected broadcast endpoint:

POST /api/webhook/broadcast

The broadcast endpoint checks an API key supplied through a request header.

It can then initiate a broadcast to active users.

This creates an integration point for external systems.

15. Environment Variables

Secrets are kept outside the source code.

The application expects configuration such as:

PORT
TELEGRAM_BOT_API_TOKEN
GEMINI_API_KEY
TELEGRAM_CHAT_ID
WEBHOOK_SECRET
IS_TEST_MODE

This is particularly important for Telegram and AI projects because both bot tokens and API keys should never be committed to a public repository.

16. Local Test Mode

The application also has a test mode.

Instead of waiting for the scheduled cron execution, the system can execute the dispatch logic immediately.

That makes local development much easier.

A scheduled system without a test path can become frustrating to debug.

17. Why This Project Is More Than an AI Demo

The project started with a very simple feature:

Generate a motivational message.

But the resulting architecture looks more like:

             ┌───────────────┐
             │ Telegram      │
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │ Commands      │
             └───────┬───────┘
                     │
          ┌──────────▼──────────┐
          │ User State          │
          │ Preferences         │
          │ Schedule            │
          │ Streak              │
          └──────────┬──────────┘
                     │
             ┌───────▼───────┐
             │ AI Engine     │
             └───────┬───────┘
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
    Gemini        Cache        Fallback
       │             │             │
       └─────────────┼─────────────┘
                     ▼
                Telemetry
                     │
                     ▼
              Feedback Loop

And that's what makes the project useful as a learning exercise.

Lessons From Building It

The biggest lesson was that:

Calling an LLM is the easy part.

The engineering challenges appear around it.

You need to think about:

Reliability
Rate limits
Model retirement
Caching
User state
Scheduling
Feedback
Observability
Security
Testing
Graceful degradation

Those problems are not unique to motivational bots.

They appear in many AI applications.

Possible Improvements

If I continued developing this project, I'd consider adding:

Redis for distributed caching
PostgreSQL or MongoDB for persistent production storage
Docker
More comprehensive automated tests
Structured logging
Metrics dashboards
More sophisticated experimentation
User-specific scheduling/timezones
Better analytics
Additional messaging integrations

Conclusion

This project started as a small Telegram automation idea.

It ended up becoming an interesting exercise in combining:

Node.js + Telegram + Gemini + automation + state + telemetry + reliability.

If you're learning AI application development, don't stop at:

const result = await model.generateContent(prompt);

Ask what happens before and after that line.

That's where most of the interesting engineering begins.

Source Code

The complete project is available here:

https://github.com/starJeet000/Telegram-Daily-Motivation-Bot

If you build something similar, I'd be interested in seeing how you handle AI reliability, caching and feedback.

WTF Is Jev? A Developer-Friendly Introduction to AI Decision Models

Soumyajit Mukherjee — Tue, 29 Sep 2026 07:23:16 +0000

If you've recently been following AI developer news, you may have noticed a new name appearing everywhere:

Jev.

No, it's not another chatbot.

No, it's not primarily a coding assistant.

And no, its main purpose isn't to generate paragraphs of text.

Jev is an AI decision model from TypeSafe AI designed to make structured decisions that software can consume directly. TypeSafe introduced it as its first "System One Model" in September 2026.

Let's break it down.

1. What is Jev?

The easiest way to understand Jev is:

Context in → structured decision out

A traditional LLM might receive:

"I was charged twice for my subscription. Please help."

and generate:

"I'm sorry you're experiencing a duplicate charge..."

Jev is more interested in answering:

Which department should handle this?

Billing
Technical
Account
Other

The result can be structured so your application can immediately use it.

For example:

Billing: 91%
Technical: 6%
Account: 3%
Other: 0%

Your code then decides what to do.

2. Why is this different from an LLM?

LLMs are extremely flexible.

That's their strength.

But flexibility isn't always what software needs.

Suppose your backend needs to decide:

Should this request be reviewed?

YES / NO

Generating a paragraph and then parsing that paragraph isn't necessarily ideal.

With a structured decision model, the possible outputs are defined ahead of time.

Conceptually:

const result = await jev.ask({
    state: request,
    question: "Does this require human review?",
    options: ["yes", "no"]
});

Your application can then apply its own logic.

3. Jev's decision types

Jev's API exposes structured question types including choice, score, and yes/no-style judgments.

Choice

Choose from predefined options:

billing
technical
account
sales
other

Score

Assign a value on a defined scale:

1 → Low
2 → Medium
3 → High
4 → Critical

Yes/No-style judgment

Ask whether a condition is true.

For example:

Does this request appear suspicious?

4. Where can developers use Jev?

Support ticket routing

Ticket
  ↓
Jev
  ↓
Billing / Technical / Sales
  ↓
Support queue

Instead of manually writing hundreds of classification rules.

Fraud workflows

Potential classification:

Approve
Review
Hold

The payment system still controls the actual transaction.

AI model routing

This is one of the more interesting use cases.

Imagine having several AI models:

Fast model
Coding model
Reasoning model
Research model

You don't necessarily want every request going to the most expensive model.

A decision layer could help select the appropriate path.

Request
   ↓
Jev
   ↓
Which model?
   ↓
Specialized model

Content moderation

Classify content into categories such as:

Safe
Needs review
High risk

Your application can then apply its moderation policy.

Security workflows

For example:

Request
   ↓
Security signals
   ↓
Jev
   ↓
Normal / Suspicious / Critical
   ↓
Security rules

The model should not replace deterministic security controls.

Incident management

A monitoring system could classify incidents by severity:

Low
Medium
High
Critical

Then automatically route high-confidence cases to the appropriate workflow.

Email classification

Incoming email:

Support
Billing
Sales
Spam
Urgent
Newsletter

The decision can feed directly into your application.

5. Jev and AI agents

AI agents need to make lots of small decisions.

For example:

What should I do next?

→ Search the web
→ Read a file
→ Call an API
→ Ask the user
→ Stop

Instead of asking a large language model to perform every tiny decision, a decision model could potentially handle parts of the routing layer.

The architecture could look like:

             ┌── Search
Agent state ─┼── API
             ├── Browser
     ↓       ├── Human
    Jev      └── Stop

The agent's code still controls which actions are actually allowed.

6. Jev isn't a replacement for LLMs

This distinction matters.

You could use both.

For example:

User
 ↓
LLM
 ↓
Understand request
 ↓
Jev
 ↓
Classify / score / route
 ↓
Application code
 ↓
Action

An LLM could generate the response.

Jev could make the structured decision.

Traditional code could enforce the business rules.

That's potentially a much more modular AI architecture.

7. The confidence part matters

Jev's outputs include probabilities/confidence information.

That's useful because applications can define thresholds.

For example:

if (confidence >= 0.95) {
    automate();
} else {
    sendToHuman();
}

The exact threshold should be determined by testing on your own data.

Don't blindly assume that 0.95 means your application is 95% safe in every environment.

8. Type-safe doesn't mean truth-safe

This is probably the most important caveat.

Suppose the model is restricted to:

YES
NO

It cannot return:

Maybe-ish-but-probably-yes?

That's good for software integration.

But the model can still select the wrong option.

In other words:

Type safety ≠ correctness.

Your production architecture should still include:

Evaluation
Logging
Monitoring
Fallbacks
Human review
Deterministic rules
Threshold tuning

9. A useful mental model

Think of traditional code:

if (condition) {
    doSomething();
}

Now imagine that the condition is difficult to write with traditional rules.

Jev can potentially become the fuzzy judgment inside the condition:

                  ┌── YES → action
Application → Jev ┤
                  └── NO → alternative

That makes Jev feel less like a chatbot and more like an AI-powered decision function.

10. Jev vs LLM

Feature	LLM	Jev
Generate text	✅	❌
Chat	✅	❌
Write code	✅	❌
Classification	✅	✅
Scoring	✅	✅
Routing	✅	✅
Structured output	Can be constrained	Core design
Confidence	Model-dependent	Core output
Software decision layer	Possible	Primary purpose

11. When should you use Jev?

A decision model makes the most sense when:

You have:
✓ Lots of repeated decisions
✓ Clearly defined possible outcomes
✓ Some ambiguity that rules can't easily handle
✓ A need for structured outputs
✓ A workflow that can use confidence thresholds

It makes less sense when you need:

✗ Long-form writing
✗ Creative generation
✗ Code generation
✗ Image generation
✗ Open-ended conversation

Those are still jobs where generative models are more appropriate.

Final takeaway

Jev isn't interesting because it's "another AI model."

It's interesting because it represents a different way of integrating AI into software.

Instead of:

User → AI → Text

think:

Software
   ↓
State + Question
   ↓
Jev
   ↓
Structured Decision
   ↓
Application Code
   ↓
Action

The big idea is simple:

Don't ask an AI to write something when all your software needs is a decision.

That's the space Jev is trying to occupy.

And as AI applications become more complex, specialized decision models could become an interesting part of the developer toolbox.

What would you build with a decision model like Jev?

System Design Jargons Explained for Fresher Developers

Soumyajit Mukherjee — Fri, 25 Sep 2026 08:22:32 +0000

If you're a fresher or beginner developer, system design can look much harder than it actually is.

You may encounter terms like:

Load Balancer
API Gateway
Cache
CDN
Message Queue
Sharding
Horizontal Scaling
Vertical Scaling
Rate Limiting
Microservices

Let's translate them into simple language.

Load Balancer

A load balancer distributes incoming requests across multiple servers.

Users
  |
  v
Load Balancer
 /    |    \
S1    S2    S3

Think: traffic distributor.

Cache

A cache stores frequently requested data temporarily so it can be retrieved faster.

Application
    |
  Cache
    |
 Database

Think: frequently used data kept nearby.

API Gateway

An API Gateway acts as an entry point between clients and backend services.

Client
  |
API Gateway
 /   |   \
Auth Order Payment

Think: front door to backend services.

Message Queue

A message queue allows tasks to wait until a worker can process them.

Application → Queue → Worker

For example, instead of making a user wait while a video is processed, the application can put the processing task into a queue.

Think: waiting line for background tasks.

CDN

A Content Delivery Network can serve cached content from locations closer to users.

Think: content delivery closer to the user.

Horizontal Scaling

Add more machines.

Server 1
Server 2
Server 3

Think: scale out.

Vertical Scaling

Make one machine more powerful.

More CPU
More RAM
Better hardware

Think: scale up.

Database Sharding

Split database data across multiple database instances.

Database
   |
-----------------
|       |       |
S1      S2      S3

Think: divide a large dataset across machines.

Rate Limiting

Restrict how many requests a client can make within a period.

Example:

100 requests / minute

Think: traffic control.

Microservices

Break an application into smaller services.

Auth
Orders
Payments
Notifications

Each service can potentially be developed, deployed, and scaled independently.

Think: smaller independent backend services.

The Most Important Beginner Tip

Don't memorize definitions.

Instead, ask:

What problem does this solve?

For example:

Too many requests?
→ Load balancing

Repeated database queries?
→ Caching

Long-running background task?
→ Message queue

Too many API requests?
→ Rate limiting

Huge database?
→ Consider sharding

Need more capacity?
→ Horizontal/vertical scaling

That's the foundation of system design.

Final Thought

System design isn't about knowing impressive terminology.

It's about understanding:

Problem → Constraint → Solution → Trade-off

Learn that pattern and the jargon becomes much easier.

WebSockets: How Real-Time Applications Actually Work

Soumyajit Mukherjee — Fri, 25 Sep 2026 07:15:16 +0000

Traditional HTTP works extremely well for many applications.

But what happens when the server needs to send information to the browser immediately?

Consider:

Chat applications
Live dashboards
Multiplayer games
Trading interfaces
Delivery tracking

Polling is one solution.

WebSockets provide another.

Traditional HTTP

A client might repeatedly ask:

Any new messages?

Then:

Any new messages?

Again:

Any new messages?

This creates unnecessary requests.

WebSockets

With WebSockets, the client establishes a persistent connection.

Browser ←────────→ Server
        persistent
        connection

Either side can send messages.

Node.js Example

Using a WebSocket library, a server can broadcast messages:

socket.on("message", (message) => {
  broadcast(message);
});

The browser can listen:

socket.onmessage = (event) => {
  console.log(event.data);
};

Why WebSockets Are Useful

They provide low-latency bidirectional communication.

For example, when someone sends a chat message:

User A
  ↓
Server
  ↓
User B

User B doesn't need to repeatedly ask whether a message arrived.

Things to Consider

Persistent connections create additional operational concerns:

Connection management
Authentication
Reconnection
Scaling
Load balancing
Message ordering

When running multiple servers, messages may need to be distributed between instances.

Final Thoughts

WebSockets are powerful when your application genuinely needs real-time communication.

For normal CRUD applications, standard HTTP APIs are often simpler and sufficient.

Building a Serverless AI Tech-News Bot with Node.js, Gemini and GitHub Actions

Soumyajit Mukherjee — Mon, 21 Sep 2026 18:20:18 +0000

I wanted to build a project that combined several technologies into one practical automation pipeline:

Node.js
Web scraping
RSS
Offline NLP
Generative AI
Telegram
Discord
GitHub Actions
Vercel

The result is the Chaos Routine Bot, a serverless technology-news agent that runs every morning and generates an AI-assisted briefing.

GitHub repository:

https://github.com/starJeet000/Telegram-News-Scraper-Bot

Architecture

The high-level pipeline is:

             News Sources
                  │
                  ▼
          Random Source Selection
                  │
                  ▼
           Tech Relevance Filter
                  │
                  ▼
             Fetch HTML
                  │
                  ▼
       Readability + JSDOM
                  │
                  ▼
            Clean Article
                  │
                  ▼
          Compromise NLP
                  │
                  ▼
            Core Facts
                  │
                  ▼
          Gemini 2.5 Flash
                  │
          ┌───────┴────────┐
          ▼                ▼
       Telegram          Discord
          │
          └───────┬────────┘
                  ▼
        JSON + RSS + Dashboard
                  │
                  ▼
                Vercel

1. Collecting News

The scraper supports multiple technology sources.

The current source pool includes:

Hacker News
Reddit
Lobste.rs
Dev.to
InfoQ
BleepingComputer
Krebs on Security
TechCrunch AI
MIT Technology Review AI
ServeTheHome
Phoronix
TechXplore
ScienceDaily Nanotechnology
Ars Technica

The scraper randomly selects two sources for each execution.

For Reddit, it also randomly selects one subreddit from communities such as:

r/programming
r/netsec
r/artificial
r/webdev
r/sysadmin

2. Filtering Before Processing

The project doesn't blindly process every title.

The scraper has a negative keyword list and a technology whitelist.

For example, terms related to unrelated categories can cause a title to be rejected, while terms such as:

code
software
hardware
linux
api
security
cyber
gpu
cpu
cloud
llm
kernel
framework

help identify technology-related content.

The filtering happens before the article reaches the extraction and AI stages.

3. Extracting Clean Article Content

A raw webpage contains far more than the article.

The project uses:

import { JSDOM } from 'jsdom';
import { Readability } from '@mozilla/readability';

The HTML is loaded into JSDOM and then processed through Mozilla Readability.

This produces a cleaner article representation.

4. Offline NLP

After extracting the article text, the project uses Compromise.

The current implementation takes the first three sentences from the processed article:

const docNLP = nlp(article.textContent);
const sentences = docNLP.sentences().out('array').slice(0, 3);

Those sentences become the factual input for the AI stage.

This is an important architectural choice.

Instead of sending the entire article to an LLM, the pipeline first creates a compact representation.

5. Gemini Synthesis

Gemini 2.5 Flash is used to generate the final briefing.

The project gives the model a specific persona: an exhausted senior software engineer drinking their fourth cup of coffee.

The prompt asks Gemini to create a few short, sarcastic paragraphs around the collected technology stories.

This produces a consistent editorial style without requiring the scraper itself to generate prose.

6. Graceful AI Fallback

The application checks whether a Gemini API key exists.

If it doesn't, it returns the offline summaries instead.

The Gemini request is also wrapped in error handling.

If the request fails, the application again falls back to the offline NLP output.

So the architecture is:

                 Gemini
                   │
            ┌──────┴──────┐
            │             │
        Success         Failure
            │             │
            ▼             ▼
       AI briefing    NLP facts

This prevents the AI service from becoming the only path to a usable result.

7. Telegram Delivery

The Telegram module uses the Telegram Bot API.

The generated message is sent using Markdown formatting.

The project also disables webpage previews to avoid unnecessary visual clutter in the Telegram channel.

8. Discord Delivery

The main pipeline also supports sending the same briefing to a Discord webhook.

That makes the generated content available across multiple messaging platforms.

9. Generating a Static API and RSS Feed

The project doesn't stop after sending a Telegram message.

It creates:

public/briefing.json
public/rss.xml

The JSON contains information such as:

update timestamp
generated briefing
source
title
URL
extracted facts

The RSS feed packages the generated briefing for RSS readers.

10. GitHub Actions Automation

The GitHub Actions workflow runs at:

02:30 UTC

which corresponds to:

08:00 IST

The workflow uses Node.js 20 and executes:

npm ci
npm start

It then deploys the generated output using the Vercel CLI.

This removes the need for a permanently running server.

11. Environment Variables

The workflow keeps credentials in GitHub Actions secrets.

The project expects values such as:

GEMINI_API_KEY
TELEGRAM_BOT_TOKEN
TELEGRAM_CHAT_ID
DISCORD_WEBHOOK_URL
VERCEL_TOKEN
VERCEL_ORG_ID
VERCEL_PROJECT_ID

The important rule here is simple:

Never commit real API keys or bot tokens to Git.

12. Why This Architecture?

The project could have been much simpler:

RSS → Gemini → Telegram

But that would make every component dependent on the next one.

Instead, the pipeline separates responsibilities:

Scraping
   ↓
Filtering
   ↓
Extraction
   ↓
NLP
   ↓
AI
   ↓
Fallback
   ↓
Distribution
   ↓
Deployment

That makes it easier to debug and gives the system a useful fallback path.

Lessons From the Project

A few ideas I took away from building this:

1. AI doesn't need to process raw data

Preprocessing can significantly simplify what reaches the model.

2. External APIs should not become single points of failure

The offline NLP fallback keeps the application functional when Gemini isn't available.

3. Automation can replace an always-on server

For workloads that run once or a few times per day, GitHub Actions can be a practical execution layer.

4. One pipeline can have multiple outputs

The same generated data can power:

Telegram
Discord
JSON
RSS
Web dashboard

Final Architecture

The complete system can be summarized as:

GitHub Actions
      ↓
Node.js
      ↓
News Sources
      ↓
Filtering
      ↓
Readability
      ↓
Offline NLP
      ↓
Gemini
      ↓
Telegram + Discord
      ↓
JSON + RSS
      ↓
Vercel

The complete source code is available here:

https://github.com/starJeet000/Telegram-News-Scraper-Bot

If you're experimenting with Node.js + AI + web scraping + automation, this is a useful pattern to explore: use traditional software engineering to prepare and control the data, then use the LLM for the part it is actually good at—synthesis.

Let’s Break Down a Full-Stack RAG Pipeline With React, Node.js & MongoDB

Soumyajit Mukherjee — Sat, 19 Sep 2026 15:49:48 +0000

If you've built a normal full-stack application, you probably know this architecture:

React → Express → MongoDB

Now let's add an AI-powered RAG pipeline.

Our architecture becomes:

React
  ↓
Express API
  ↓
RAG Service
  ↓
Embedding Model
  ↓
MongoDB Vector Search
  ↓
Relevant Context
  ↓
LLM
  ↓
Response

Let's break it down.

What Are We Building?

Imagine a developer documentation assistant.

Users upload technical documentation, and later ask:

How do I refresh an expired JWT?

Our application searches the uploaded documentation and gives the relevant information to an LLM before generating the response.

This is Retrieval-Augmented Generation (RAG).

1. Document Ingestion

First, documents need to enter our system.

PDF / Markdown / HTML
        ↓
Text Extraction
        ↓
Cleaning
        ↓
Chunking
        ↓
Embeddings
        ↓
MongoDB

Why chunk the documents?

Because retrieving a small relevant section is usually more useful than sending an entire document to the LLM.

Example:

authentication.md

├── Chunk 1
├── Chunk 2
├── Chunk 3
└── Chunk 4

2. Generate Embeddings

Each chunk is converted into a vector.

const embedding = await embeddingModel.embed(chunk);

Conceptually:

"Refresh tokens are used..."
             ↓
[0.12, -0.43, 0.77, ...]

The vector represents the semantic meaning of the text.

3. Store the Data

A MongoDB document might look like:

{
  documentId: "auth-guide",
  content: "Refresh tokens are used...",
  embedding: [0.12, -0.43, 0.77],
  metadata: {
    page: 10,
    source: "auth-guide.pdf"
  }
}

MongoDB Atlas Vector Search can then be used to search these embeddings.

4. User Sends a Question

React sends:

POST /api/chat

{
  "question": "How do I refresh an expired JWT?"
}

Express receives the request.

app.post("/api/chat", async (req, res) => {
  const { question } = req.body;

  const answer = await ragService.ask(question);

  res.json({ answer });
});

5. Embed the Query

The question is converted into an embedding.

User Question
     ↓
Embedding Model
     ↓
Query Vector

Now the query vector can be compared with the document vectors.

6. Retrieve Relevant Chunks

Our vector search might return:

Refresh Token Documentation    0.94
JWT Authentication             0.89
Session Management             0.81
Database Configuration         0.31

We take the most relevant chunks.

This is the retrieval stage.

7. Build the Context

Now we combine the retrieved chunks:

const context = results
  .map(result => result.content)
  .join("\n\n");

Our application now has:

Question
+
Relevant Documentation

8. Build the Prompt

For example:

You are a developer documentation assistant.

Use the context below to answer the question.

Context:
[retrieved documents]

Question:
How do I refresh an expired JWT?

If the context doesn't contain the answer,
say that the information is unavailable.

9. Call the LLM

The backend sends the prompt to the LLM.

const answer = await llm.generate(prompt);

The model generates the response.

Then:

LLM
 ↓
Express
 ↓
React

React displays the answer.

Complete RAG Flow

                 USER
                   ↓
              React UI
                   ↓
             Express API
                   ↓
             RAG Service
                   ↓
          Query Embedding
                   ↓
          Vector Retrieval
                   ↓
           Relevant Chunks
                   ↓
          Context Construction
                   ↓
          Prompt Construction
                   ↓
                  LLM
                   ↓
             Final Answer
                   ↓
                React

The Ingestion Side

Don't forget that there are actually two important pipelines.

Ingestion pipeline

Document
 ↓
Extract
 ↓
Clean
 ↓
Chunk
 ↓
Embed
 ↓
Store

Query pipeline

Question
 ↓
Embed
 ↓
Search
 ↓
Retrieve
 ↓
Build Context
 ↓
LLM
 ↓
Answer

This distinction makes RAG much easier to understand.

Why Chunking Is Important

Imagine a 200-page API reference.

The user asks:

How does refresh-token rotation work?

Sending the entire document to the LLM is inefficient.

Instead, retrieval might identify:

Chunk 47
Chunk 51
Chunk 52

as the relevant sections.

That's what makes the "retrieval" part valuable.

Production Improvements

A basic RAG demo isn't enough for a production application.

We could add:

Authentication
Rate limiting
Caching
Metadata filtering
Hybrid search
Reranking
Query rewriting
Citations
Observability
Token/cost tracking
Prompt-injection defenses

For example:

Query
 ↓
Validation
 ↓
Query Rewriting
 ↓
Hybrid Search
 ↓
Metadata Filtering
 ↓
Reranking
 ↓
Context
 ↓
LLM
 ↓
Citations

Example MERN Structure

server/

├── controllers/
│
├── routes/
│
├── models/
│
├── middleware/
│
└── services/
    ├── embeddingService.js
    ├── retrievalService.js
    ├── ragService.js
    └── llmService.js

Keeping these services separate makes the architecture easier to maintain.

RAG Isn't Just "An LLM + Vector DB"

That's probably the most important lesson.

A useful RAG system depends on:

Document quality
       +
Chunking
       +
Embeddings
       +
Retrieval
       +
Context selection
       +
Prompt design
       +
LLM

If retrieval returns irrelevant information, even a powerful LLM can produce a poor response.

Final Architecture

A simple version:

React
 ↓
Node.js
 ↓
MongoDB Vector Search
 ↓
Relevant Context
 ↓
Gemini / OpenAI-style LLM
 ↓
React

A more advanced version:

React
 ↓
API Gateway
 ↓
Authentication
 ↓
Query Processing
 ↓
Hybrid Retrieval
 ↓
Reranking
 ↓
Context Compression
 ↓
LLM
 ↓
Citation Layer
 ↓
Response

And that's where a simple AI demo starts becoming a real full-stack engineering project.

Final Thought

The LLM is only one part of a RAG application.

The real engineering work happens around it:

ingestion → retrieval → context → generation → security → observability → optimization.

That's what makes RAG such an interesting architecture for full-stack developers.

Monolith vs Microservices: Stop Choosing Microservices Too Early

Soumyajit Mukherjee — Sat, 19 Sep 2026 14:27:34 +0000

Microservices are popular.

That doesn't mean every application needs them.

A common mistake is starting a project with ten services because "real companies use microservices."

What Is a Monolith?

A monolithic application keeps major functionality inside one deployable application.

For example:

Frontend
   ↓
Backend
   ├── Users
   ├── Products
   ├── Orders
   └── Payments
        ↓
    Database

This can be perfectly reasonable.

What Are Microservices?

With microservices, functionality is split into independently deployable services:

User Service
Product Service
Order Service
Payment Service
Notification Service

Each service can potentially have its own deployment lifecycle and data storage.

Why Microservices Are Attractive

They can provide:

Independent deployments
Team ownership boundaries
Independent scaling
Technology flexibility
Fault isolation

But these benefits come with complexity.

The Hidden Cost

You now have to manage:

Service discovery
Network failures
Authentication between services
Distributed tracing
Deployment pipelines
Monitoring
Data consistency
Message queues

A function call:

createOrder();

can become:

HTTP request
→ network
→ authentication
→ service
→ database
→ response

Start Simple

A modular monolith can be an excellent middle ground.

Organize your code into clear modules:

users/
products/
orders/
payments/

If the system eventually needs service separation, those boundaries can provide a foundation.

Final Thoughts

Microservices solve organizational and scaling problems.

They also create operational problems.

For many projects, a well-designed monolith is not a failure.

It's the correct architecture.

What Actually Happens When You Type a URL?

Soumyajit Mukherjee — Wed, 09 Sep 2026 17:22:29 +0000

Typing a URL into a browser looks simple.

Behind the scenes, however, several systems work together before the webpage appears.

Consider:

https://example.com

Step 1: The Browser Parses the URL

The browser identifies:

Protocol: HTTPS
Domain: example.com

It knows that HTTPS should be used to communicate securely with the server.

Step 2: DNS Lookup

Computers communicate using IP addresses.

DNS translates:

example.com

into an IP address such as:

93.184.216.34

The browser may use cached DNS information to avoid performing the lookup repeatedly.

Step 3: Establishing a Connection

The browser connects to the server.

With HTTPS, the connection also involves TLS negotiation.

This establishes encryption between the browser and server.

Step 4: HTTP Request

The browser sends something similar to:

GET / HTTP/1.1
Host: example.com

The server processes the request.

Step 5: Server Response

The server might return:

HTTP/1.1 200 OK
Content-Type: text/html

followed by HTML.

Step 6: Browser Rendering

The browser parses the HTML.

It then discovers resources such as:

CSS
JavaScript
Images
Fonts

Additional requests may be sent to retrieve them.

Eventually, the browser constructs the page you see.

Why Developers Should Understand This

Understanding this sequence helps explain:

DNS failures
SSL errors
Slow websites
HTTP status codes
CDN behavior
Browser caching
Network debugging

Final Thoughts

A URL is just the starting point.

The journey from a URL to a rendered webpage involves DNS, networking, TLS, HTTP, servers, browsers, and rendering engines.

Mandatory Skills Every Tech Professional Should Have on Their Resume

Soumyajit Mukherjee — Mon, 07 Sep 2026 07:50:32 +0000

Also, You can check out my blogs here: Click Here

With my GitHub projects here: starJeet000

Having a long list of technologies on your resume doesn't necessarily make you a strong candidate.

What matters is whether you can use those technologies to build, debug, deploy, and maintain real applications.

Here are the major skill categories you should consider including.

1. Programming Languages

You should have at least one language that you know well.

Examples:

JavaScript / TypeScript
Python
Java
C++
Go
C#

Don't list 10 languages if you can barely write a project in them.

Depth is better than keyword stuffing.

2. Frameworks & Libraries

Depending on your career path:

React
Next.js
Node.js
Express
Django
Spring Boot
.NET
Angular

Your resume becomes stronger when you connect these technologies to actual projects.

3. Databases

Understand how applications store and retrieve data.

Useful skills include:

PostgreSQL
MySQL
MongoDB
Redis
Database design
Indexing
Basic query optimization

Knowing a database isn't just knowing how to run SELECT or insert a document.

Understand why you chose a particular database.

4. APIs & Backend Fundamentals

Modern applications communicate through APIs.

Useful skills include:

REST APIs
Authentication
Authorization
HTTP/HTTPS
JSON
API integration
Error handling
Rate limiting

5. Git & GitHub

Version control is practically mandatory for software development.

Know how to:

Create branches
Commit changes
Merge branches
Resolve conflicts
Create pull requests
Review code
Manage repositories

6. Cloud & Deployment

You don't necessarily need to be a cloud architect.

But understanding basic deployment is extremely valuable.

Learn the fundamentals of platforms such as:

AWS
Azure
Google Cloud

Also understand environment variables, secrets, domains, HTTPS, and basic server deployment.

7. Docker & DevOps

Basic DevOps knowledge can make you stand out.

Consider learning:

Docker
Docker Compose
CI/CD
GitHub Actions
Linux fundamentals
Application monitoring
Deployment pipelines

8. Testing & Debugging

Writing code is only part of software development.

You should also know how to:

Debug applications
Read stack traces
Write basic tests
Handle errors
Test APIs
Identify performance problems

9. Security Fundamentals

Security shouldn't be an afterthought.

Understand fundamentals such as:

Authentication
Authorization
Password hashing
JWT/session security
HTTPS
Input validation
OWASP Top 10
Secure API design

10. AI & Modern Development Tools

AI-assisted development is becoming increasingly common.

Depending on your role, useful skills include:

LLM APIs
AI-assisted coding
Prompt engineering
AI automation
RAG fundamentals
Working with AI APIs
Evaluating AI-generated output

You don't need to claim that you're an AI engineer just because you use an AI coding assistant.

Be specific about what you actually built.

11. Data Structures & Problem Solving

For many software engineering roles, fundamental problem-solving skills remain important.

Know the basics of:

Arrays
Strings
Hash maps
Stacks
Queues
Trees
Graphs
Sorting
Searching
Time and space complexity

12. Software Engineering Practices

Don't forget the skills that aren't tied to a specific programming language.

Examples:

SDLC
Agile/Scrum
Code reviews
Documentation
Clean code
Design patterns
Basic system design
Team collaboration

The Most Important Rule

Don't turn your resume into a technology dictionary.

Instead of:

React, Node.js, MongoDB, Docker, AWS, Git, REST API

Show what you actually did:

Built and deployed a full-stack application using React and Node.js, designed MongoDB data models, implemented authenticated REST APIs, containerized the application with Docker, and automated deployment using CI/CD.

That's much more convincing.

Final takeaway

Your resume should answer three questions:

What can you build?
What problems can you solve?
Can you actually use the technologies you listed?

A skill becomes much more valuable when you can demonstrate it through a real project.

🧠 Building a Mental Health Prediction System with Machine Learning, SHAP & Flask

Soumyajit Mukherjee — Wed, 26 Aug 2026 09:17:56 +0000

I built an end-to-end Mental Health Prediction & Assessment System that combines machine learning, standardized screening, Explainable AI and a web application.

The objective was to explore what a more complete ML application looks like beyond simply training a model in a Jupyter Notebook.

🚀 What does the application do?

The system combines two major components:

1. Machine-learning-based risk prediction
2. PHQ-9-based clinical symptom screening

The results are presented through a web interface with additional explainability and support features.

🤖 Machine Learning Pipeline

I evaluated multiple classification algorithms:

AdaBoost
Random Forest
XGBoost
Logistic Regression

After tuning and evaluation, the AdaBoost classifier achieved approximately 86.9% accuracy and was selected as the final model.

Model evaluation included:

Confusion matrices
ROC-AUC curves
Precision-Recall metrics

🩺 PHQ-9 Integration

One of the more interesting parts of the project is the integration of the Patient Health Questionnaire (PHQ-9).

The questionnaire contains nine questions and generates a score from 0 to 27.

The project uses this standardized screening layer alongside the machine-learning prediction rather than presenting the ML model as a medical diagnosis.

🔍 Explainable AI with SHAP

A prediction is much more useful when users can understand why a model reached it.

That's why I integrated SHAP (SHapley Additive exPlanations).

The application generates visual explanations showing how individual features contributed to a particular prediction.

This turns:

"The model predicted this."

into:

"These features contributed to the model's prediction."

That's an important distinction when building responsible ML applications.

🏗️ Architecture

The application uses:

User
  ↓
Web Interface
  ↓
Flask Application
  ↓
Data Processing
  ↓
ML Model
  ↓
Risk Prediction
  ↓
SHAP Explanation
  ↓
Result Dashboard

The project also contains serialized ML artifacts such as the trained model, preprocessing transformer and label encoder.

🛠️ Technology Stack

Machine Learning

Python 3.12
Scikit-learn
XGBoost
Pandas
NumPy
SHAP

Backend

Flask
Gunicorn

Frontend

HTML5
CSS3
Bootstrap 5
Jinja2

DevOps

Docker
Render
GitHub Actions

🚀 Beyond Machine Learning

I also implemented additional application functionality:

Interactive mental-health assessment
SHAP visualization
Counselling booking interface
Crisis assistance information
Docker-based deployment
Automated uptime monitoring

The goal was to turn the ML experiment into an actual end-to-end web application.

📚 What I Learned

This project reinforced several important lessons:

1. Accuracy isn't everything
A model can have good accuracy and still be unsuitable for real-world use without considering context, limitations and safety.

2. Explainability matters
SHAP helped make the model's predictions easier to inspect.

3. Deployment changes everything
Moving from a notebook to Flask + Docker + Gunicorn introduced an entirely different set of engineering challenges.

4. Sensitive domains require extra caution
Mental-health applications should never present an ML prediction as a definitive medical diagnosis.

🔗 Source Code

The complete project is available on GitHub:

Click Here

The repository also includes the Flask application, trained model artifacts, notebook, dataset, Docker configuration and requirements.

If you're learning Machine Learning, Flask, Explainable AI or ML deployment, I'd love to hear your feedback.