DEV Community: Mittal Technologies

How We Built a Real-Time Ride-Sharing App with Node.js, Socket.io, and Google Maps API

Mittal Technologies — Mon, 01 Jun 2026 11:30:37 +0000

Building a ride-sharing app sounds like one of those "just follow a tutorial" projects until you're actually in it. Then you realize pretty quickly that the tutorial version and the production version are completely different animals.
At Mittal Technologies, we recently shipped a full ride-sharing platform, driver matching, real-time routing, live location tracking, fare calculation, payment flows, the whole thing. This post is a walkthrough of the architecture decisions we made, the problems we didn't anticipate, and the things we'd do differently. No fluff, just the real build.

The Core Challenge: Everything Happens at Once

The fundamental difficulty with ride-sharing (versus, say, a food delivery app) is the density of concurrent real-time events. When a rider requests a trip, you need to:

Find nearby available drivers
Broadcast the request to eligible drivers
Handle the first acceptance and cancel broadcasts to others
Begin live location tracking for both rider and driver
Update ETAs as conditions change
Handle dropoff and trigger payment

All of this needs to happen with sub-second responsiveness. A user waiting 4 seconds for a match confirmation isn't "slow", it feels broken.

Stack Overview

Backend: Node.js + Express
Real-time: Socket.io
Mapping: Google Maps Platform (Directions, Distance Matrix, Geocoding)
Database: MongoDB (user/trip data) + Redis (live location state)
Auth: JWT + refresh token rotation
Payments: Stripe Connect (for driver payouts)
Hosting: AWS EC2 + ElastiCache for Redis

We chose Node.js for the obvious reason, event-driven, non-blocking I/O is a natural fit for a system where you're constantly waiting on external events (driver acceptance, location pings, payment confirmations) without wanting to block threads.

Real-Time Architecture: Socket.io Room Strategy

The part most people under-architect. The naive approach is broadcasting everything to everyone and filtering on the client. That works fine at 10 concurrent users. At 1,000, you've built yourself a very expensive problem.

Our approach used Socket.io rooms aggressively.

Driver rooms by geohash zone:
When a driver comes online, they join a room corresponding to their geohash zone (we used precision-5 geohash, roughly 5km x 5km cells). When a ride is requested, we compute the rider's geohash and broadcast only to that room, plus adjacent cells to handle edge cases.

// Driver comes online
socket.on('driver:online', async (data) => {
const { driverId, lat, lng } = data;
const geohash = Geohash.encode(lat, lng, 5);

// Join the zone room
socket.join(zone:${geohash});

// Also join adjacent zones for edge-of-cell coverage
const neighbors = Geohash.neighbors(geohash);
neighbors.forEach(neighbor => socket.join(zone:${neighbor}));

// Store live state in Redis (TTL 30s, refreshed by heartbeat)
await redis.setex(driver:location:${driverId}, 30, JSON.stringify({
lat, lng, geohash, socketId: socket.id, available: true
}));
});

Trip rooms for matched rides:
Once a match is confirmed, both driver and rider join a trip-specific room. All subsequent location updates, status changes, and messages go through that room only.

// On match confirmation
const tripRoom = trip:${tripId};
driverSocket.join(tripRoom);
riderSocket.join(tripRoom);

// Location updates now scoped to this room only
socket.on('location:update', async ({ lat, lng }) => {
const tripId = await getActiveTripForSocket(socket.id);
if (!tripId) return;

io.to(trip:${tripId}).emit('location:update', {
role: socket.data.role, // 'driver' or 'rider'
lat,
lng,
timestamp: Date.now()
});

// Refresh Redis state
await redis.setex(socket:location:${socket.id}, 60, JSON.stringify({ lat, lng }));
});

The Matching Algorithm

We went through three iterations here. The first was too naive (just nearest driver). The second was too complex (we briefly went down a machine learning rabbit hole we had no business going down for v1). The third is what we shipped.

The production matching logic scores available drivers on three factors:

async function scoreDriversForRequest(riderLat, riderLng, drivers) {
const scores = await Promise.all(drivers.map(async (driver) => {
// Factor 1: Distance (Google Distance Matrix for real road distance, not straight line)
const distanceData = await getDistanceMatrix(
{ lat: driver.lat, lng: driver.lng },
{ lat: riderLat, lng: riderLng }
);
const etaMinutes = distanceData.duration.value / 60;
const distanceKm = distanceData.distance.value / 1000;

// Factor 2: Driver acceptance rate (stored per driver, updated async)
const acceptanceRate = await redis.get(`driver:acceptance:${driver.id}`) || 0.8;

// Factor 3: Trip completion quality score
const qualityScore = driver.rating / 5;

// Weighted scoring
const score = (
  (1 / (etaMinutes + 1)) * 0.5 +   // 50% weight on proximity
  parseFloat(acceptanceRate) * 0.3 +  // 30% weight on reliability
  qualityScore * 0.2                  // 20% weight on quality
);

return { driver, score, etaMinutes, distanceKm };

}));

return scores.sort((a, b) => b.score - a.score);
}

One non-obvious problem: Google Distance Matrix API charges per element (origin × destination pair). With 20 nearby drivers and 1 rider, that's 20 API calls per request event. At scale that gets expensive fast. We added a Redis cache on recently computed routes (5-minute TTL) that reduced our API usage by about 60% in practice.

The Race Condition Problem

This one bit us in testing and took a day to properly solve.

When a ride request broadcasts to a driver zone, multiple drivers can accept nearly simultaneously. Without proper locking, two drivers could both receive confirmation. Our first attempt at fixing this was a database-level unique constraint on tripId + status = 'accepted'. That works, but the second driver still gets a confusing error with no good recovery path.

The proper fix was a Redis distributed lock on the trip acceptance:

async function acceptTrip(tripId, driverId, socket) {
const lockKey = lock:trip:${tripId};
const lockValue = ${driverId}:${Date.now()};

// Attempt to acquire lock (10s expiry as safety net)
const acquired = await redis.set(lockKey, lockValue, 'NX', 'EX', 10);

if (!acquired) {
// Another driver got there first
socket.emit('trip:already_accepted', { tripId });
return;
}

try {
// Check trip is still unmatched
const trip = await Trip.findById(tripId);
if (trip.status !== 'pending') {
socket.emit('trip:already_accepted', { tripId });
return;
}

// Commit the match
trip.driverId = driverId;
trip.status = 'matched';
trip.matchedAt = new Date();
await trip.save();

// Notify rider, cancel broadcast to other drivers
io.to(`trip:rider:${trip.riderId}`).emit('trip:matched', {
  driverId,
  eta: /* computed ETA */
});
io.to(`zone:${trip.requestZone}`).emit('trip:cancelled', { tripId });

} finally {
// Always release the lock
const currentValue = await redis.get(lockKey);
if (currentValue === lockValue) {
await redis.del(lockKey);
}
}
}

Google Maps Integration: The Parts That Surprised Us

Directions API for route display — straightforward. You get a polyline, you decode it, you render it.
Real-time ETA updates — less straightforward. Hitting the Directions API on every location ping is expensive and unnecessary. We poll it every 90 seconds and on significant route deviations (>200m from expected path), using driver location from Redis rather than waiting for a socket event.
Geocoding for pickup/dropoff — the forward geocoding (address → coordinates) from the search input was fine. The reverse geocoding (coordinates → readable address for pickup confirmation) needs caching. We saw the same coordinates geocoded dozens of times within minutes. Simple Redis cache keyed on truncated lat/lng (4 decimal places) with 24-hour TTL solved that.

What We'd Do Differently

WebSockets vs Socket.io: Socket.io's auto-reconnection and room management are genuinely useful, but we carry its full weight even for connections that never need the fallback transports. For v2, we'd evaluate raw WebSocket with a custom reconnection layer for driver clients (which are known environments) and keep Socket.io only for rider-facing web clients.
Location update frequency: We defaulted to 3-second driver location pings. For active trips, 3 seconds is fine. For nearby-but-unmatched drivers, 10 seconds is more than sufficient and meaningfully reduces Redis write load.
Testing real-time flows: Unit tests don't really capture Socket.io behavior at scale. We should have built load testing with Artillery or k6 earlier. We found a socket room leak in staging that we should have caught in testing.

Performance in Production

Initial load after launch: ~400 concurrent WebSocket connections during peak. Redis handling ~2,000 ops/second. Average match time: 4.2 seconds from request to driver confirmation. Google Maps API costs: higher than projected in month 1 before the caching improvements, then normalized to budget by month 2.

The architecture held. The main scaling bottleneck we're watching is the matching algorithm's Distance Matrix calls as ride volume grows, we're evaluating switching to a cached-graph approach for high-density urban zones as a next step.

If you're building something similar and want to talk through architecture decisions, feel free to drop questions in the comments. And if you're looking for a team that's shipped this kind of real-time infrastructure, Mittal Technologies has the case study to prove it.

How to Add Pinterest Rich Pins to a Website Using HTML Meta Tags

Mittal Technologies — Fri, 29 May 2026 08:26:21 +0000

Pinterest Rich Pins sound like a marketing thing, but the actual implementation is a developer's job. If a client asks you to "set up Rich Pins" and you've never done it before, here's exactly what you need to know, no fluff, just the technical breakdown.

What Pinterest actually needs from your HTML

Pinterest validates Rich Pins by crawling a URL you submit and looking for either Open Graph meta tags or schema.org structured data in the

. For most blog or article-based sites, Open Graph is the simpler path.
The minimum viable set of Open Graph tags for Article Rich Pins:

For product Rich Pins (e-commerce), you'll also need:

Validating before submission

Pinterest provides a validator at developers.pinterest.com/tools/url-debugger. Paste in one of your URLs and it will tell you exactly which tags it found, which are missing, and whether you're eligible for Rich Pin approval.
If you're seeing errors, the most common culprits are: the og:type tag being missing, the og:image URL returning a 404, or the image dimensions being too small (Pinterest recommends a minimum of 1000px on the longest side).

Using schema.org as an alternative

If you prefer structured data over Open Graph, Pinterest also accepts JSON-LD schema markup for articles. A basic implementation:

Both methods work. If you're already implementing JSON-LD for Google's structured data requirements (which you should be), the Pinterest benefit is essentially free, same markup, dual benefit.
The folks at Mittal Technologies have written about this overlap between technical SEO and platform-specific requirements, and it's a good read if you're trying to build a unified metadata strategy rather than patching each platform separately.
After your tags are in place, submit your validation URL through Pinterest's Rich Pins application. Approval usually comes within 24 to 48 hours.

The Problem with Overusing JavaScript Frameworks: A Front-End Developer's Honest Take

Mittal Technologies — Thu, 28 May 2026 10:00:48 +0000

I've worked on enough frontend codebases to have real opinions about this. The JavaScript framework ecosystem is genuinely impressive React, Vue, Svelte, Astro, Next, Nuxt, the list doesn't end, but there's a pattern I keep seeing that I find genuinely frustrating: teams reaching for a full SPA framework before they've asked whether they actually need one.
This isn't a framework-bashing post. React is great. Vue is great. The problem is the reflex, not the tools themselves.

When a marketing site becomes a React app for no reason

Picture a five-page company website. Static content, a contact form, maybe a few scroll animations. No user authentication, no real-time data, no complex state to manage. And yet it's built as a full React SPA with client-side routing, a 400KB JavaScript bundle, and a first meaningful paint that takes three seconds on a decent connection.
Why? Usually because the dev team knew React, the project kicked off with a create-react-app starter, and nobody stopped to ask whether this particular site actually warranted the overhead. The framework became the default, not a considered choice.
Teams at Mittal Technologies encounter this regularly in audit work, sites that are technically sophisticated but perform worse than a well-written HTML/CSS page would have, purely because of unnecessary JavaScript weight that nobody questioned at the architecture stage.

The real cost: performance, SEO, and developer experience

JavaScript is expensive to parse. That 200KB bundle isn't just 200KB of download, it's 200KB that the browser has to download, parse, compile, and execute before users see anything interactive. On a mid-range Android device (which represents most of the world's real web traffic), this isn't a theoretical concern. It's a meaningful delay that affects real users.
Then there's SEO. Googlebot handles JavaScript. Yes, but with documented delays and occasional rendering failures. A content-heavy site that requires JavaScript to render its primary content will always have weaker crawl coverage than one that serves HTML directly. That's not an opinion, it's observable behavior.

The alternative isn't "no framework", it's the right tool for the context

Astro changed how I think about this. The islands architecture model where most of the page is static HTML but interactive components hydrate individually only where needed, is the right mental model for most content-heavy sites. You get component-based developer experience without shipping a full SPA runtime to every user.
For highly interactive applications, dashboards, collaborative editors, real-time tools, a full client-side framework makes complete sense. The mismatch is when that same architecture gets applied to a blog, a landing page, or a documentation site. The complexity doesn't serve anyone.

Three questions to ask before picking a framework

I now try to honestly answer three questions before committing to a framework on any new project: Does this UI have a complex, interdependent state that genuinely needs managing? Will users interact with it in ways that require real client-side reactivity? Is this project going to grow into something where a component ecosystem actually matters long-term?
If the answer to all three is no or even mostly no, the simplest tool that can do the job is almost always the right choice. Your users will feel the performance difference. Search engines will notice it. And six months from now, the developer who inherits the codebase will appreciate not having to wrangle a full SPA for what is, at its core, a brochure site.

Best Tech Stack Choices for Scalable eCommerce Development

Mittal Technologies — Wed, 27 May 2026 08:29:24 +0000

This is the kind of post I wish existed when I was making technology decisions for eCommerce builds three years ago. The advice out there is either too abstract or too opinionated without context.
So, here's my actual thinking, with tradeoffs included.

Frontend

Next.js is the dominant choice right now for a reason. Server-side rendering, static generation, image optimization built-in, strong ecosystem. For most eCommerce frontends, it's the right default.
If you need something lighter and are comfortable with a slightly smaller ecosystem, Astro is genuinely excellent for content-heavy store pages.
Avoid building a heavy single-page application (React or Vue without SSR) for a public eCommerce store. Crawlability and first-load performance both suffer.

Backend / Commerce Engine

Shopify + Storefront API if your client wants a managed solution with minimal ops overhead. The headless capability is solid and the ecosystem is unmatched.
Medusa.js if you want a truly open-source, self-hosted commerce backend with real flexibility. It's younger but it's mature enough for production now. I've used it on two projects and it held up.
Magento/Adobe Commerce for enterprise complexity, large catalogs, complex B2B pricing, multi-store setups. But be honest with clients about the total cost of ownership. It's not cheap to run or maintain.

Database

PostgreSQL for almost everything transactional. It's boring advice but it's correct. Don't reach for NoSQL in your commerce core unless you have a very specific reason.
Redis for session management, caching, cart state. Non-negotiable at any real scale.

Search

Algolia or Typesense (self-hosted, lower cost) for product search. Native database queries will not give you the faceted filtering, typo tolerance, and search-as-you-type experience that modern shoppers expect. This is not a place to cut corners.

Lessons Learned Working on Large eCommerce Builds

Over-engineering early is a real failure mode. I've seen teams spend three months on infrastructure for a store that had 500 products and 200 daily visitors. Build for where you are, with architecture that can grow, not architecture built for 10x traffic you don't have yet.
Database indexing on product and order tables gets forgotten until things slow down. Don't wait for the performance complaint to add them.
Image optimization is never done. It always comes back. Automate it or it will always be a problem.
API rate limits from third-party services (payment gateways, shipping, tax) bite you in load testing if you haven't planned for them. Always plan for them.
And finally, work with partners who understand the full picture. A great ecommerce development company isn't just writing code. They're making architectural decisions that affect your business two years from now.

Full-Stack Development Roadmap for Beginners (2026 Guide)

Mittal Technologies — Tue, 26 May 2026 10:45:20 +0000

Where to start, what to skip, and how to actually finish.

If you search "full-stack roadmap" right now, you'll find diagrams with 40+ technologies connected by arrows going in every direction. It's overwhelming on purpose, I think or at least it has that effect. The reality of learning full-stack development is much more linear than those diagrams make it seem. You don't need to learn everything. You need to learn the right things in the right order.

This is what that actually looks like in 2026.

Phase 1: The web basics (don't skip this)

HTML and CSS. I know, I know, everyone wants to skip straight to JavaScript. But understanding how the web is structured, how the box model works, how layout systems like flexbox and grid behave, this underpins everything that comes after. You don't need to become a CSS expert, but you need to be comfortable enough to build a page without constantly fighting the browser.
Timeline: 3-4 weeks of focused practice.

Phase 2: JavaScript properly

Not just syntax. The things that actually matter how the event loop works, what closures are and why they behave the way they do, asynchronous programming with Promises and async/await, DOM manipulation, and how modules work. This phase takes longer than people expect, and the temptation to rush to a framework is real. Resist it.
Timeline: 6-8 weeks minimum.

Phase 3: A front-end framework

React is still the right default choice in 2026 purely from a job market perspective. It's not always the best technical choice for every project, but if you're learning to get hired, react knowledge opens the most doors. Learn components, state, props, hooks, and how to fetch data from APIs. Build a couple of small projects to cement it.

Mittal Technologies curriculum structure has a similar progression, building real understanding at each layer before moving on. It's worth browsing if you want structured guidance alongside your self-learning.

Phase 4: Back-end basics

Node.js with Express is the most beginner-friendly way into the back-end. You’ll learn how servers work, how to handle routes, how to build REST APIs, and how to connect to a database. If you prefer Python, FastAPI or Django REST Framework are excellent alternatives.
Timeline: 4-6 weeks.

Phase 5: Databases

Start with PostgreSQL. Learn how to create tables, write queries, understand joins, and think about data structure. Then spend a bit of time with MongoDB to understand how document databases differ. This doesn't need to be exhaustive, you're building competence, not expertise.

Phase 6: Deployment and the basics of DevOps

Vercel or Railway for front-end and full-stack apps. A basic understanding of environment variables, CI/CD pipelines, and what Docker does conceptually. You don't need to be a DevOps engineer, but you need to be able to put your app online and keep it there.

What to build along the way

Projects at each phase matter more than finishing the phase quickly. A weather app that hits an external API (Phase 3). A notes app with a proper back-end and database (Phase 4–5). A full CRUD application with authentication deployed online (Phase 6). That last one, working and living, is worth more than any certificate.
The developers who complete this path and actually get hired aren't necessarily the fastest learners. They're the ones who built real things at each stage, got comfortable being confused, and kept going anyway. That sounds simple. It's also genuinely all it takes.

Why AI Automation Is Becoming Essential for Modern Developers

Mittal Technologies — Mon, 25 May 2026 10:43:53 +0000

I remember when using a linter felt like "automation." You know, that smug feeling of having ESLint yell at you so you didn't have to manually check spacing rules. Those were simpler times.
Now we're writing prompts to generate entire features, having AI review our PRs, and letting it handle the first draft of test cases. The bar has moved so far that "automation" as a concept has basically been redefined for developers in the last two years.
And honestly? It's time to stop treating AI automation as optional in your workflow.

The Developer Who Doesn't Use AI in 2026

They exist. I've worked with some. They're often genuinely talented, sharp, experienced, and know their codebase inside out. But here's what I've noticed: they're spending a disproportionate amount of their time on work that doesn't require their level of skill.
Writing tests for functions they already know work. Documenting code they wrote six months ago. Looking up the exact syntax for something they use twice a year. Debugging an obscure CSS issue that Copilot would've flagged immediately.
That's not a skill problem. It's a tooling problem. And it's fixable.

What AI Automation Actually Looks Like in a Dev Workflow

Not the hype version. The actual, day-to-day version.
Code generation: Not "write my entire app." More like "here's the shape of this function, fill it out" or "generate the boilerplate for this API endpoint pattern." Fast, accurate, and you still review it before it goes anywhere.
PR reviews: AI can catch things humans miss on tired afternoons. Logic gaps, security vulnerabilities, inconsistent patterns. It's not replacing your team's code review; it's the first pass that makes your team's review more focused.
Documentation: Let's be honest. Nobody loves writing docs. AI can generate a solid first draft from your code. You edit, refine, add context. Ship. Done.
Test generation: Describe the behavior, get test cases. Not perfect, but 70% there out of the box, and editing is faster than starting from scratch.
Debugging: Paste the error, paste the relevant code, get five possible causes ranked by likelihood. Sometimes it's wrong. Usually, it at least points you in the right direction faster than reading through documentation alone.

The Skill Is Learning How to Direct It

This is the part that doesn't get talked about enough in developer circles. Using AI tools well is genuinely a skill. It's not passive.
Writing a good prompt, one that gives the model enough context to actually be useful, is something you get better at over time. Knowing when to trust the output and when to be skeptical. Knowing how to break a complex problem into pieces that AI can handle well. Knowing when to just write the code yourself because the back-and-forth will take longer than doing it directly.

What This Means for How You Grow as a Developer

The developers I've seen grow fastest in the last couple of years aren't necessarily the most technically brilliant. They're the ones who've figured out how to use AI to punch above their weight class and then used the time they saved to work on genuinely hard problems.
If AI handles your boilerplate, you can spend more time on architecture. If AI handles your first draft of tests, you can spend more time thinking about edge cases that matter. If AI handles your documentation, you can spend more time on the actual design of the system.
The ceiling rises when the floor gets handled.

Getting Started If You Haven't Yet

If you're still on the fence, just pick one thing. One part of your workflow. Use Copilot or Cursor for a week on a feature you're building and pay attention to where it actually helps versus where it's more trouble than it's worth.
You'll find a pattern. Build from there.
And if you're working on client projects or building AI-powered web products, it's also worth looking at how companies like Mittal Technologies are integrating automation into real-world development workflows, not theory, actual production systems. Seeing how others have done it makes the starting point a lot less abstract.
AI automation in a developer's workflow isn't about replacing your skills. It's about making sure your skills are being spent on the right things. In 2026, that's not a productivity tip anymore, it's baseline professional hygiene.

JavaScript Features Developers Use Daily but Rarely Talk About

Mittal Technologies — Sat, 23 May 2026 09:40:12 +0000

There's a version of JavaScript discourse that's all about the flashy stuff, new framework releases, edge runtimes, the latest React drama. Which is fine, but it means some genuinely useful language features stay in the background, used constantly but rarely discussed. I want to talk about those.
Not async/await everyone knows that. Not arrow functions, those have been covered to death. The stuff that quietly makes your code better without you necessarily realizing why.

Optional chaining and nullish coalescing: still underappreciated

Yes, these have been around since ES2020. And yes, most developers use them. But I still see code in PRs that does things like:
const city = user && user.address && user.address.city;
When it could just be:
const city = user?.address?.city;
The optional chaining operator (?.) short-circuits to undefined instead of throwing. Combine it with nullish coalescing (??) for a default value and you've got something genuinely elegant:
const city = user?.address?.city ?? 'Unknown';
These aren't new. They're just still being underused in codebases that grew up before they existed and never got a thorough refactor.

Array destructuring with defaults and skipping elements

Most developers know basic array destructuring. Fewer use the full range of what it can do. You can skip elements, set defaults, and rename in a single line:
const [,, third = 'fallback'] = someArray;
That double comma skips the first two elements. The = 'fallback' is a default if the third element is undefined. Small things. Surprisingly useful in utility functions where you're pulling specific values out of consistently shaped arrays.
"The best JavaScript knowledge isn't about knowing the most features, it's knowing which feature solves the problem cleanly, without over-engineering it."

Object.entries() and chained array methods for data transformation

This pattern comes up constantly in real-world code and I don't see it talked about enough. You have an object; you want to filter or transform its properties and then get an object back. The clean way:
const filtered = Object.fromEntries(
Object.entries(config)
.filter(([key, value]) => value !== null)
);
Object.entries() gives you an array of [key, value] pairs. You chain your array methods. Object.fromEntries() reconstructs the object. It's readable, it's functional, and it avoids the usual dance of reduce with an accumulator object that confuses anyone reading the code later.

WeakMap for private-ish data and memory-conscious caching

Private class fields with # syntax is great, but WeakMap solves a slightly different problem: associating data with an object without preventing garbage collection. The classic use case is caching computed results keyed to DOM nodes or class instances, when the object gets garbage collected, the entry disappears too. No memory leak, no manual cleanup.
const cache = new WeakMap();

function getMetadata(element) {
if (!cache.has(element)) {
cache.set(element, computeExpensiveMetadata(element));
}
return cache.get(element);
}
This is the kind of pattern that doesn't come up in tutorials but shows up in production code at companies building complex UIs. Worth knowing.

Structured clone: the deep copy you've been looking for

For years the go-to deep clone was JSON.parse(JSON.stringify(obj)). It works for simple data but breaks with Date objects, undefined, functions, and circular references. Libraries like Lodash have _.cloneDeep. But since 2022, you've had a native option:
const deepCopy = structuredClone(original);
Handles Date, Map, Set, ArrayBuffer, circular references. Available in all modern browsers and Node 17+. Still seeing it absent from codebases that should be using it.

The Intersection Observer for scroll-based logic

If you're still attaching scroll event listeners to window for lazy loading or animation triggers, please stop. The Intersection Observer API has been broadly available for years and it's dramatically more performant, it fires callbacks only when elements enter or leave the viewport, without blocking the main thread.
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
entry.target.classList.add('visible');
}
});
}, { threshold: 0.1 });

document.querySelectorAll('.animate-on-scroll')
.forEach(el => observer.observe(el));
Clean, efficient, and a significant improvement in user experience on content-heavy pages. Teams offering web development services India businesses rely on should be reaching for this by default rather than scroll listeners.
None of these features are obscure or experimental. They're all stable, well-supported, and genuinely useful in day-to-day work. They just don't get talked about because they're not new. But "not new" doesn't mean "not worth knowing well."

Why Developers Should Care About Cybersecurity Beyond Authentication

Mittal Technologies — Fri, 22 May 2026 09:03:41 +0000

At some point most developers implement JWT, hash passwords with bcrypt, set up OAuth, and mentally tick "security" as done. I understand the logic. Auth is the visible, user-facing part of security. It's what tutorials cover. It's what interviews ask about.
But the vulnerabilities that cause real damage in production? Usually not auth failures. They're the stuff that never made it onto the checklist.

Auth vs authorization: not the same thing

IDOR: Insecure Direct Object Reference is still appearing in codebases built by developers who know better. You authenticate the user at the route level, but you don't check if they're allowed to access that specific resource. So, a user changes ?userId=123 to ?userId=124 in the URL and suddenly they're looking at someone else's data. Every data access point needs its own authorization check. A gate at the route entry isn't enough.

Your dependencies are part of your attack surface

The average Node.js project has hundreds of transitive dependencies. You're not just shipping your code; you're shipping everyone else's code too. Running npm audit occasionally isn't a security practice. You need something in CI/CD that blocks deploys when critical vulnerabilities are found. Snyk, Dependabot, or GitHub's native security alerts can automate most of this without adding meaningful overhead.

Secrets management is not optional

API keys committed to public repos. Production database credentials visible in CI logs. .env files checked into version control. These aren't edge cases, they're regular findings. Use a proper secrets manager: AWS Secrets Manager, HashiCorp Vault, or Doppler. Rotate credentials. Audit access. This is infrastructure-level hygiene and it should be in your dev workflow from day one, not after something goes wrong.

Your error messages are leaking information

Verbose stack traces in production API responses tell attackers your tech stack, your file structure, your database query patterns. Your frontend should receive generic error messages. Your internal logging should receive the details. These should never be the same response. It's a one-line environment check. Do it.

Security isn't something you add at the end of a sprint. It's a default way of thinking about every architectural decision. For teams that want structured support for building secure systems, whether that's audits, implementation, or training, professional cybersecurity services in India work directly with development teams without slowing down the build cycle.

Auth is necessary. It's just not sufficient. Start thinking about what happens after the user gets in.

Why Most Responsive Websites Still Fail Mobile Users in 2026

Mittal Technologies — Thu, 21 May 2026 09:22:35 +0000

You'd think by now we'd have this figured out. Responsive design has been the standard for over a decade. Every major CSS framework ship mobile-friendly grids out of the box. And yet, open your phone, browse to a random business website, and there's a reasonable chance the experience is still frustrating.
Why? Because "responsive" became a checkbox, and checkboxes don't build good experiences.

The Checkbox Problem

Somewhere along the way, "is your site responsive?" became a yes/no question with a trivial answer. Add a viewport meta tag. Use a framework. Done.
But responsiveness was never supposed to be about layout alone. It was supposed to be about the experience adapting meaningfully to the context of use. A phone isn't just a small desktop. The person using it is in a different physical situation, with different constraints, and often different goals.
When we reduce "responsive" to "the layout doesn't break on small screens," we miss everything that actually matters.

Performance Isn't Optional and Mobile Performance Is a Different Problem

This is worth saying plainly: a site can be perfectly responsive and still be unusable on mobile because it's slow.
Mid-range Android devices which represent a huge slice of global mobile users, have significantly less processing power than the machines developers build on. JavaScript that runs fine on a MacBook can cause visible jank on a Redmi Note. Images that look sharp on a Retina display are absurdly oversized for a 360px screen.
The gap between "works in DevTools mobile emulation" and "works on a real device with real network conditions" is larger than most teams realize.

Hidden Content Is Still Content People Need

A common responsive pattern is to show condensed or hidden content on mobile, collapsed sections, removed sidebars, truncated text. Sometimes this makes sense. A lot of the time, it's a design decision masquerading as an optimization.
If the content was worth including on desktop, ask yourself whether it's genuinely not needed on mobile, or whether it's just inconvenient to design for. Those are different problems with different solutions.
Also, Google indexes your mobile content. Content you hide on mobile is content that may not count toward your SEO. Worth knowing.

Interaction Patterns That Feel Wrong on Touch

Hover states that reveal information. Dropdowns that require precise cursor positioning. Drag interactions that conflict with scroll. These are desktop interaction patterns that get ported to mobile without adaptation.
Touch is a different medium. There's no hover. There's no right-click. The "pointer" is imprecise and has a physical size. Interfaces designed around mouse interactions feel off on touch in ways that are hard to articulate but immediately felt.
The fix isn't just making things bigger. It's rethinking the interaction model for touch from the start, which is part of why mobile-first design philosophy, not just responsive CSS, matters.

The Expectations Gap

Mobile app experiences have raised the bar significantly. Native apps, especially well-funded consumer apps are fast, smooth, and purposefully designed for touch. When someone uses your mobile website right after using their banking app or their food delivery app, the comparison isn't flattering if your site is technically responsive but experientially clunky.
This is why investing in genuinely good mobile experiences, whether through professional mobile app development India teams or dedicated mobile-first web design, isn't just a nice-to-have. It's the baseline users now expect.

What "Not Failing" Actually Looks Like

A mobile experience that doesn't fail users is fast to load on a mid-range device on LTE, easy to navigate with one thumb, readable without pinching or squinting, and capable of completing its core tasks without friction.
It doesn't need to be fancy. It doesn't need animations or clever transitions. It needs to work — quickly, clearly, reliably.
That's the bar. It's not actually that high. But clearing it requires treating mobile as the primary design target, not an afterthought.

Why Most Responsive Websites Still Fail Mobile Users in 2026

Mittal Technologies — Thu, 21 May 2026 09:22:35 +0000

The Checkbox Problem

Performance Isn't Optional and Mobile Performance Is a Different Problem

Hidden Content Is Still Content People Need

Interaction Patterns That Feel Wrong on Touch

The Expectations Gap

What "Not Failing" Actually Looks Like

React vs Vue vs Angular for startups and SaaS apps

Mittal Technologies — Wed, 20 May 2026 08:23:05 +0000

Last year I shipped three different products: one in React, one in Vue, one with a legacy Angular backend I had to extend. I didn't plan it that way, it just happened. By the end of the year, I had opinions I didn't have before, and I figured I'd share them.

Quick context: I'm not a framework evangelist. I've seen people wreck perfectly good projects by picking a stack based on what was trending on Twitter. So, take this as "things I noticed" not "you should definitely do this."

What startups actually need from a framework

Speed to first prototype. Ease of onboarding new devs. Not creating technical debt that becomes load bearing in six months.

React is fast to start but slow to standardise if your team doesn't have strong conventions. I've seen two devs on the same React project solving the same problem in completely different ways. That kind of inconsistency compounds, and eventually it affects the product's user experience design, bugs in edge cases, inconsistent behaviour across features, UI that drifts from the design system.

Vue handles this better. The file structure is opinionated enough that two devs independently writing components end up with something more similar. That's genuinely valuable when you're moving fast.

Angular for SaaS: not as crazy as it sounds

Most people write Angular off for early-stage startups. I'd agree, the setup cost is real. But if you're building a B2B SaaS product that's going to live for 4+ years and you know you'll eventually have a team of 8+, starting in Angular isn't insane. You're basically paying upfront to avoid architectural debt later.

The built-in router, forms module, HTTP client, and dependency injection mean you're not making package choices at every turn. For a team that wants to focus on product instead of tooling decisions, that matters.

My actual recommendation for a 2026 SaaS product

If you're a solo founder: Vue + Nuxt. Ship fast, stay clean. If you're a 2-4 person team: React + Next.js. Hiring will be easier. If you're building something that'll need serious scale: Angular or React with a very strict architecture guide.

Whatever you pick, have a conversation with your team about conventions before you write the first component. That conversation will save you more time than the framework choice itself.

Best AI Tools for Developers to Boost Productivity & Workflow

Mittal Technologies — Tue, 19 May 2026 09:49:08 +0000

Let me start with something that might be mildly controversial: most developer productivity content is written by people who either never code seriously or are being paid by the tools they're recommending. So, I want to be upfront, this is just my honest experience of what's actually improved how I work, and a few things that are overhyped.

AI coding tools are genuinely useful now. Not in the "it writes perfect code" sense, it still doesn't, and anyone telling you otherwise is selling something. But in the "it eliminates the boring parts of being a developer" sense, yes, absolutely. Let me break that down.

The productivity gains that are actually real

The biggest win isn't autocompleted, it's context. When you're working inside a large codebase and you ask an AI tool "where does this state get updated?" and it can reason across multiple files to give you a sensible answer, that's genuinely different from anything we had before. That's Cursor in a nutshell. It's not magic, it's wrong often enough to keep you on your toes, but the speed gain on navigating unfamiliar code is real.

Claude Code (Anthropic's CLI tool) is where things get interesting for autonomous tasks. You can describe a refactor at a fairly high level "move all database calls into a service layer, here's the pattern to follow" and it'll make a reasonable attempt across the whole project. You still review everything. But the drafting work is done for you.

The honest truth is that for a software development company India or anywhere else managing multiple concurrent projects, these tools compress the feedback loop on low-to-medium complexity tasks significantly. Not everything, architecture decisions, complex debugging, code review judgment, still needs senior developer time. But the scaffolding work? AI handles that well.

Testing and documentation: the two things devs hate most

Nobody enjoys writing tests. I said it. And yet everyone agrees they're necessary. AI tools have made this one genuinely less painful. Give GitHub Copilot or Claude a function and ask for unit test cases, including edge cases, and you'll usually get something worth iterating on in about 30 seconds. It doesn't replace thinking about what to test. It replaces the tedious act of writing the boilerplate.

Documentation is similar. Inline docstrings, README updates, API documentation, these are the tasks that always get deprioritized because they're not building anything. AI drafts them fast enough that you can actually keep documentation current, which is a small miracle if you've ever worked on a team where docs were six months out of date.

What's still genuinely hard for AI coding tools

Debugging. Not the obvious stuff, AI is fine at "this error message means X." But the subtle bugs that only appear under specific conditions, race conditions, memory issues, flaky tests that fail one in ten times, AI tools fumble these more than they'd admit. You can spend more time arguing with an AI about why its suggested fix doesn't work than you would've spent debugging yourself. Know when to close the chat window and just think.

Also: anything involving deep domain-specific context. If you're working in financial systems, healthcare data pipelines, or anything with complex regulatory or business logic, AI tools lack the domain knowledge to give you confident answers. They'll give you plausible answers, which is arguably more dangerous. Trust but verify, always.

The tools worth actually trying in 2026

Cursor for day-to-day coding if you're open to a new editor. Claude Code for autonomous multi-file tasks. GitHub Copilot for anyone who can't leave VS Code or JetBrains. Tabnine if you're in an environment where code can't leave your servers. And honestly, a well-set-up Claude prompt for code review is still surprisingly useful even without an IDE integration.

The teams getting the most out of AI tools have done something important: they've thought carefully about where AI fits and where it doesn't. They've written internal guidelines. They have a review process that accounts for AI-assisted code. That's not bureaucracy, that's engineering discipline applied to a new kind of tool.

For any team, whether you're a solo developer or part of a larger software development company India working across enterprise projects, the ROI of getting this right is significant. The cost of getting it wrong (shipping AI-generated bugs that nobody understood) is equally significant.

Start small. Pick one task type. Build confidence before you expand. That's the approach that actually sticks.