DEV Community: Atul Srivastava

I built a VS Code extension so you can respond to GitHub Copilot agent from your phone

Atul Srivastava — Thu, 16 Apr 2026 16:26:08 +0000

Here's something that happens constantly with Copilot agent mode:

You kick off a task. "Refactor the auth module and update all the tests." Agent starts. You step away — meeting, lunch, whatever. Agent hits a confirmation: "I need to delete 3 files. Proceed?" It sits there, waiting, doing nothing.

You come back 40 minutes later. It stopped 38 minutes ago. You click "Yes." It continues.

You just lost 38 minutes of autonomous work — because the only way to interact with Copilot agent is through the VS Code window on your desktop.

I built Copilot Remote Control to cut that chain.

What it does

Your phone becomes a live VS Code chat panel. Every message the agent prints appears on your phone in real time. When the agent stops and needs input, your phone buzzes in your pocket. You glance at it, type "yes", put it back. Agent continues. You never left your meeting.

No dead time. No wasted cycles.

The architecture (no third-party server)

This is not a wrapper around an API. There's no relay server I run. Here's what actually happens:

Your PC (VS Code)                          Your Phone
┌─────────────────────┐                   ┌──────────────────┐
│  Copilot Agent      │                   │  PWA (React 18)  │
│       ↓             │                   │       ↑          │
│  Extension hooks    │                   │  WebSocket       │
│  into chat session  │                   │  client          │
│       ↓             │                   │       ↑          │
│  WebSocket Server   │◄── Cloudflare ───►│  Secure Tunnel   │
│  (localhost:3000)   │    Tunnel (wss)   │                  │
│  Push Notifier ─────┼──► Google FCM ───►│  Push Notif      │
└─────────────────────┘                   └──────────────────┘

The WebSocket server runs inside the extension on localhost. A Cloudflare quick tunnel (cloudflared binary bundled in the extension) punches it out to the internet. Data flows directly from your PC to your phone through Cloudflare's network. I don't see your code. I don't store anything.

The technical details worth knowing

Real-time streaming at 20ms: The extension monitors Copilot's JSONL session files. VS Code writes response data in two modes — full snapshots (REPLACE) and incremental patches (SPLICE with an index offset). The extension reconstructs complete response state from both modes, diffs against what's been sent, and streams only new parts to your phone.

Mid-stream reconnection: If you open your phone after the agent has already been talking, you see the full accumulated response, not a blank screen. 200-message history buffer.

Offline license verification: The license key is a JWT signed with RSA-2048. The extension verifies it using a baked-in public key — pure math, no network call. Works on air-gapped machines.

$0/month infrastructure: Vercel free tier + Firebase free tier + Cloudflare free tier. The entire backend is one serverless function that wakes up for 200ms per sale.

Setup in 4 steps

Buy & activate at agent-handle.vercel.app (₹49 / ~$6 one-time). Paste the license key in VS Code.
Scan the QR code that appears in the sidebar panel with your phone camera.
Walk away. Your phone shows everything the agent is doing, in real time.
Respond when it buzzes. Firebase FCM pushes a notification when the agent needs input.

You can also send files from your phone — screenshots, PDFs, requirement docs — directly into your VS Code workspace.

I built a VS Code extension that auto-selects Ask/Plan/Agent mode for every Copilot prompt

Atul Srivastava — Thu, 16 Apr 2026 16:24:36 +0000

If you use GitHub Copilot, you've probably noticed something: most developers leave it on Agent mode all the time. It's the default. It feels powerful. But it's also expensive — Agent mode burns through 3,000+ tokens even for a question like "what does useState do?"

Ask mode handles that in ~500 tokens. But who switches manually every time?

That's the problem I built Prompt Router to solve. It watches your prompt, classifies it in milliseconds, and opens Copilot in the right mode automatically — no clicks, no thinking, no token waste.

How it classifies prompts

It uses a hybrid approach: a heuristic keyword classifier blended 40/60 with a Naive Bayes ML model. Both run entirely locally — no network calls, no telemetry, nothing leaves your machine.

Mode	Triggered by	Approximate token cost
Ask	Explanations, definitions, debugging concepts	~500 tokens
Plan	Architecture, design, step-by-step approach	~800 tokens
Agent	Write/fix/create code, run terminal commands	~3,000+ tokens

The ML model also learns from your corrections. Every time you dismiss or override its suggestion, it adjusts. Over time it personalises to how you actually write prompts.

The three ways to use it

1. Ctrl+Shift+R quick input (recommended)
Press the shortcut, type your prompt, and VS Code opens Copilot in the right mode with your prompt pre-filled. Zero friction.

2. @smart participant
In any Copilot chat, type @smart followed by your question. It shows the detected mode label and a one-click button if you want to switch.

3. @router participant
Type @router to get a full score breakdown — Ask / Plan / Agent percentages — so you can see exactly why it made the call it did.

There's also a Token Savings Dashboard in the Command Palette that shows your cumulative savings over time.

The license system

It's a one-time purchase: $2.9 / ₹19. You get a license key instantly by email. Paste it into VS Code once (Prompt Router: Activate License), and it works forever — no subscription, no cloud check-in.

The key is a JWT signed with RSA-256. The extension verifies it offline using a baked-in public key. Up to 3 device activations; you can deactivate any slot at any time.

I Built 2 Chrome Extensions for ADHD Users & Trust — Shipped to the Chrome Web Store

Atul Srivastava — Sun, 12 Apr 2026 17:09:42 +0000

I just shipped 2 Chrome extensions to the Chrome Web Store, both priced at $1.99 lifetime. Here's what they do and how I built them.

The Extensions

🧠 ADHD Web Simplifier

The web is a distraction machine. ADHD Web Simplifier fixes that automatically when you open any page.

Features:

Kills autoplaying videos, animations, and flashing banners
Bionic Reading mode — bolds the first half of every word for faster scanning
Built-in Pomodoro timer with focus/break cycles
One-click "Reading Mode" that strips sidebars, ads, and clutter
Accessibility-first — works on any site, no config needed

👉 Get ADHD Web Simplifier

🛡️ TrustLayer

Before you trust a website, TrustLayer scores it for you.

Features:

Real-time credibility score (0–100) in the browser toolbar
Checks domain age, HTTPS, known scam databases, and content signals
Visual trust badge on every page
Detailed breakdown: why the score is what it is

👉 Get TrustLayer

The Stack

React 18 · TypeScript · Chrome MV3 · Vite 5 · Tailwind CSS · Canvas API

Both extensions use Manifest V3 (the current Chrome standard) with service workers instead of background pages.

Key MV3 Patterns

Content script for DOM manipulation:

// manifest.json
"content_scripts": [{
  "matches": ["<all_urls>"],
  "js": ["content.js"],
  "run_at": "document_idle"
}]

Message passing between popup and content script:

// popup.tsx
chrome.tabs.sendMessage(tab.id!, { action: 'enableFocusMode' });

// content.ts
chrome.runtime.onMessage.addListener((msg) => {
  if (msg.action === 'enableFocusMode') applyFocusMode();
});

Lessons from the Chrome Web Store Review

Privacy policy is mandatory — even for simple extensions. I hosted mine on GitHub Pages
Permissions justify — the review team asks why you need each permission. activeTab only is safer than tabs
Screenshots matter — Chrome Web Store listing quality directly affects click-through rate

Try Them

Both are $1.99 one-time — no subscription, no account. Works on Chrome and all Chromium browsers.

I Built 6 Free Windows Desktop Apps with Tauri + Rust + React — Here's What I Learned

Atul Srivastava — Sun, 12 Apr 2026 17:08:38 +0000

Over the past few months I shipped 6 free productivity utilities for Windows, all built with Tauri v2 + Rust + React 18 + TypeScript. Here's what the suite looks like and what I learned building it.

The Apps

All 6 are live on the Microsoft Store under my publisher name Illusanato:

App	What it does	Link
🐢 WhySlowPC	System Monitor & slow-down analyser	Download
🌐 NetDiag	Network diagnostic & speed tester	Download
🖨️ PrintFix	Printer troubleshooter & fix tool	Download
📁 FileMemory	Smart file search & recent-files manager	Download
🔄 SmartReboot	Safe scheduled restart with open-app detection	Download
⌨️ UniversalKeys	Global keyboard shortcut manager	Download

Why Tauri Instead of Electron?

I've used Electron extensively (my SA ERP project is built on it), but for these utility apps I needed something lighter:

Bundle size: Tauri apps ship at ~3–8 MB vs Electron's 100+ MB
Memory: Tauri uses the system WebView (WebView2 on Windows), not a bundled Chromium
Rust backend: Native performance for system calls — reading CPU metrics, querying printers, scanning files

The Stack

Frontend:  React 18 · TypeScript · Vite · Tailwind CSS
Backend:   Rust (Tauri v2 commands)
Packaging: MSIX via Tauri bundler → Microsoft Store

Key Tauri Concepts

Tauri commands let you call Rust functions from the React frontend:

#[tauri::command]
fn get_cpu_usage() -> f64 {
    // system metrics via sysinfo crate
    let mut sys = System::new_all();
    sys.refresh_cpu();
    sys.global_cpu_info().cpu_usage() as f64
}

import { invoke } from '@tauri-apps/api/tauri';
const usage = await invoke<number>('get_cpu_usage');

What I'd Do Differently

Share more Rust utility code across apps from the start — I ended up duplicating window-management helpers
Use Tauri's updater plugin for auto-updates instead of relying on MS Store updates alone
Add more telemetry (crash reports) — diagnosing Windows-specific bugs without user logs is hard

Try Them

All apps are free, no account required. If you're on Windows, give one a try and let me know what you think in the comments!

👉 See all apps on MS Store

Building BloomNest: A Full-Stack Childcare Management Platform with Angular 18 & Appwrite

Atul Srivastava — Mon, 06 Apr 2026 12:19:18 +0000

Childcare centers run on spreadsheets, WhatsApp messages, and paper forms. I wanted to see if I could replace all of that with a single web app. The result is BloomNest — a full-stack management platform for nurseries and kindergartens.

🔗 Live demo: https://bloomnest-mu.vercel.app/
📦 GitHub: https://github.com/atul0016/BloomNest

What it does

BloomNest handles everything a childcare facility needs day-to-day:

Child enrollment — profiles, groups, allergies, parent linkage
Staff management — roles, status tracking, CRUD operations
Smart scheduling — weekly grid, shift blueprints, conflict detection
Time tracking — clock in/out, daily logs, monthly summaries
Absence management — request/approve workflow with calendar view
Analytics dashboard — charts for attendance trends and staff coverage
Parent portal — view-only access to their own child's data
Push notifications — real-time alerts via Firebase Cloud Messaging
Dark mode — because obviously

Five distinct role dashboards: Admin, Board, Manager, Educator, and Parent — each seeing only what they need.

Tech stack

Layer	Choice	Why
Frontend	Angular 18 (standalone components)	Strong typing, scalable architecture
UI	Bootstrap 5.3 + Bootstrap Icons	Fast, consistent layout
Charts	Chart.js 4.4	Lightweight, flexible
Database + Auth storage	Appwrite Cloud	Real-time subscriptions, file storage, easy SDK
Authentication	Firebase Auth	Reliable, free tier, easy social login
Push notifications	Firebase Cloud Messaging	Battle-tested for web push
Hosting	Vercel	Zero-config Angular deploys

Angular 18's standalone components (no NgModule) made the folder structure much cleaner. Lazy loading each feature module kept the initial bundle small.

The interesting architectural decisions

1. Splitting auth between Firebase and Appwrite

Firebase handles identity (sign-in, password reset, token). Appwrite handles everything else — user profiles, role assignments, all app data. The two talk through a thin service layer that keeps the rest of the app unaware of which provider does what.

This sounds like it adds complexity, but in practice it meant I could swap either provider independently. Firebase Auth's email verification flow is excellent; Appwrite's database permissions model is excellent. Both together = best of both worlds.

2. Role-based routing without a library

Rather than pulling in a full RBAC library, I implemented guard-based routing using Angular's CanActivate. Each route declares which roles can access it. A RoleGuard checks the current user's role from a service and redirects if unauthorized.

Simple, type-safe, zero extra dependencies.

3. Shift blueprints for scheduling efficiency

Managers spend a lot of time building the same weekly schedule. I added "shift blueprints" — reusable shift templates that can be applied to any week with one click. It stores the pattern, not the instances, so changing a blueprint does not retroactively alter past schedules.

4. Real-time updates without polling

Appwrite's real-time subscriptions push changes instantly to connected clients. When an admin approves an absence request, the educator's view updates without a page refresh. The subscription teardown on ngOnDestroy prevents memory leaks.

Challenges

Appwrite permissions model — Appwrite uses document-level permissions. Getting role-based read/write to work correctly (especially for the parent portal's read-only access to child documents) required careful collection design. I ended up using server-side functions for anything sensitive.

Chart.js with live data — Chart.js does not automatically re-render when Angular's change detection runs. I had to call chart.update() manually after data changes, which meant tracking chart instances across components.

Angular 18 signals — I started using Angular signals for reactive state in a few components. The mental model is cleaner than RxJS for simple derived values (computed()), but integrating signals with Appwrite's observable SDK took some bridging work.

Demo accounts

You can log in and explore any role:

Role	Email	Password
Admin	aria.thornewood@bloomnest.app	admin123
Manager	caspian.drake@bloomnest.app	manager123
Educator	elara.finch@bloomnest.app	educator123
Parent	diana.whitmore@bloomnest.app	parent123

What's next

Export reports to PDF/Excel
Mobile app (Ionic + Capacitor, same Angular codebase)
Multi-facility support (one account, multiple locations)

If you're building with Angular 18 or Appwrite and have questions about any of the patterns above, drop them in the comments. Happy to go deeper on any section.

Building an Offline-First Multi-Tenant SaaS with React 19 and Dexie.js

Atul Srivastava — Sat, 04 Apr 2026 15:40:40 +0000

When I set out to build ParkManager — a multi-tenant parking management SaaS — I knew "works offline" wasn't optional. Parking lots don't shut down when the internet goes out.

Here's how I architected an offline-first, multi-tenant application using React 19, Dexie.js (IndexedDB wrapper), and Appwrite as the cloud backend.

The Problem

Most SaaS apps assume always-on connectivity. But in the real world:

Internet can be spotty at parking lots
Attendants need to issue tickets regardless of connection
Payment records can't be lost
Multi-tenant data must stay isolated

The Architecture

Stack Overview

Layer	Technology
Frontend	React 19 + Vite
Local DB	Dexie.js (IndexedDB)
Cloud Backend	Appwrite
Desktop	Electron
PWA	Service Workers
Auth	Role-Based Access Control (5 roles)

Offline-First with Dexie.js

The core idea: write locally first, sync to cloud when available.

// Dexie database schema
const db = new Dexie('ParkManagerDB');
db.version(1).stores({
  tickets: '++id, vehicleNumber, entryTime, exitTime, status, tenantId, synced',
  payments: '++id, ticketId, amount, method, tenantId, synced',
  users: '++id, email, role, tenantId'
});

Every record gets a synced flag. When online, a background sync job pushes unsynced records to Appwrite:

async function syncToCloud() {
  const unsynced = await db.tickets
    .where('synced').equals(0)
    .toArray();

  for (const ticket of unsynced) {
    try {
      await appwrite.databases.createDocument(
        DB_ID, TICKETS_COLLECTION, ticket.id, ticket
      );
      await db.tickets.update(ticket.id, { synced: 1 });
    } catch (err) {
      console.log('Will retry on next sync cycle');
    }
  }
}

// Run sync every 30 seconds when online
setInterval(() => {
  if (navigator.onLine) syncToCloud();
}, 30000);

Multi-Tenancy

Each record includes a tenantId. The Dexie queries always filter by tenant:

async function getTickets(tenantId) {
  return db.tickets
    .where('tenantId').equals(tenantId)
    .reverse()
    .sortBy('entryTime');
}

On the Appwrite side, collection-level permissions ensure tenants can only access their own data.

5 RBAC Roles

ParkManager supports 5 distinct roles with different permissions:

Owner — Full system access, can manage tenants
Admin — Manage parking lots, users, and reports
Operator — Day-to-day operations, view reports
Attendant — Issue/close tickets, collect payments
Accountant — View-only access to financial reports

const PERMISSIONS = {
  owner: ['*'],
  admin: ['manage_lots', 'manage_users', 'view_reports', 'manage_tickets'],
  operator: ['manage_tickets', 'view_reports'],
  attendant: ['create_ticket', 'close_ticket', 'collect_payment'],
  accountant: ['view_reports', 'view_payments']
};

function hasPermission(user, action) {
  const perms = PERMISSIONS[user.role];
  return perms.includes('*') || perms.includes(action);
}

PWA + Electron = Everywhere

The same React codebase runs as:

PWA — installable on any device with a browser
Electron app — native desktop experience with system tray, auto-updates
Web app — standard browser access

The Electron wrapper is thin:

const { app, BrowserWindow } = require('electron');

function createWindow() {
  const win = new BrowserWindow({
    width: 1200,
    height: 800,
    webPreferences: {
      nodeIntegration: false,
      contextIsolation: true
    }
  });

  // In production, load the built React app
  win.loadFile('dist/index.html');
}

app.whenReady().then(createWindow);

Key Takeaways

Offline-first isn't hard — Dexie.js makes IndexedDB pleasant to work with
Sync conflicts are the real challenge — use timestamps and "last write wins" for simple cases
Multi-tenancy at the data layer — tenant isolation should be enforced at every query
RBAC from day one — retrofitting permissions is painful
React 19 + Vite — blazing fast dev experience with HMR

Try It

Live Demo: Live Demo
GitHub: github.com/atul0016/park-manager

If you're building SaaS products that need to work in unreliable network conditions, offline-first architecture is worth the investment. The user experience improvement is dramatic.

What offline-first patterns have you used in your projects? Drop a comment below!

How I Built a Full-Scale ERP System as a Solo Developer

Atul Srivastava — Fri, 03 Apr 2026 08:30:22 +0000

Most developers avoid ERP. It's complex, boring, and usually built by teams of 20+. I built one alone.

Why?

Indian small businesses run on disconnected spreadsheets, Tally, and WhatsApp. I wanted to build one clean desktop app that handles everything — finance, inventory, sales, purchase, GST, manufacturing, HRM, and reporting.

The Stack

Electron — Desktop delivery (Windows)
React + TypeScript — UI layer
SQLite — Local-first data storage
Node.js — IPC handlers and service layer

Why desktop + SQLite instead of a web app? Indian SMEs often have unreliable internet. A local-first app that just works, every time, was the right call.

What's Inside — 8 Modules

Finance: Chart of accounts, journal entries, general ledger, trial balance, P&L, balance sheet. Double-entry accounting built from scratch.

Inventory: Item master, warehouse structure, stock movement, valuations, low-stock alerts.

Sales: Customer management, sales orders, GST-compliant invoicing, receipt tracking, aging analysis.

Purchase: Vendor management, purchase orders, goods receipt, purchase invoicing, payment tracking.

Manufacturing: Bill of materials, work centers, production orders, MRP planning, job work, quality control.

HRM: Employee records, attendance, leave management, payroll, tax declarations.

GST & Compliance: E-invoice, e-way bill, GSTR reports, ITC reconciliation, HSN summaries. Built for Indian tax workflows.

Reports: Financial, sales, purchase, inventory, and GST reports with export options.

The Hard Parts

1. Domain modeling

ERP isn't one problem, it's 15 interconnected problems. A stock movement affects inventory valuations, which affects financial reports, which affects GST filings.

2. Double-entry accounting

Getting the chart of accounts, journal entries, and ledger posting right took longer than any UI work.

3. GST compliance

Indian GST rules change constantly. Building a flexible structure that handles e-invoicing, reverse charges, and ITC was the most research-heavy part.

4. Keeping it simple

The biggest temptation in ERP is feature creep. I forced myself to keep the UI clean: clear navigation, card-based actions, search-first header.

What I Learned

Build the data model first. If your chart of accounts is wrong, everything downstream breaks.
SQLite is underrated. For local-first business software, it's fast, reliable, and zero-config.
ERP is a product exercise, not just a coding exercise. You need to understand business operations, not just API design.
Ship module by module. I built Finance first, then Inventory, then Sales — each one tested before moving on.

Try It

Live demo: indian-erp.vercel.app
Source code: github.com/atul0016/sa-erp
Portfolio: beimatulportfolio.tech

If you're thinking about building business software as a solo developer — do it. The domain complexity is what makes it valuable, both as a product and on your portfolio.

I'm Atul Srivastava, a full-stack developer building ERP systems, SaaS platforms, and Chrome extensions. Open to freelance and remote work. Reach me at imatulsrivas@gmail.com.

DEV Community: Atul Srivastava

I built a VS Code extension so you can respond to GitHub Copilot agent from your phone

What it does

The architecture (no third-party server)

The technical details worth knowing

Setup in 4 steps

Links

I built a VS Code extension that auto-selects Ask/Plan/Agent mode for every Copilot prompt

How it classifies prompts

The three ways to use it

The license system

Links

I Built 2 Chrome Extensions for ADHD Users & Trust — Shipped to the Chrome Web Store

The Extensions

🧠 ADHD Web Simplifier

🛡️ TrustLayer

The Stack

Key MV3 Patterns

Lessons from the Chrome Web Store Review

Try Them

I Built 6 Free Windows Desktop Apps with Tauri + Rust + React — Here's What I Learned

The Apps

Why Tauri Instead of Electron?

The Stack

Key Tauri Concepts

What I'd Do Differently

Try Them

Building BloomNest: A Full-Stack Childcare Management Platform with Angular 18 & Appwrite

What it does

Tech stack

The interesting architectural decisions

1. Splitting auth between Firebase and Appwrite

2. Role-based routing without a library

3. Shift blueprints for scheduling efficiency

4. Real-time updates without polling

Challenges

Demo accounts

What's next

Building an Offline-First Multi-Tenant SaaS with React 19 and Dexie.js

The Problem

The Architecture

Stack Overview

Offline-First with Dexie.js

Multi-Tenancy

5 RBAC Roles

PWA + Electron = Everywhere

Key Takeaways

Try It

How I Built a Full-Scale ERP System as a Solo Developer

Why?

The Stack

What's Inside — 8 Modules

The Hard Parts

1. Domain modeling

2. Double-entry accounting

3. GST compliance

4. Keeping it simple

What I Learned

Try It