DEV Community: Mittal Technologies

How to Make a Website Faster: 15 Web Performance Optimization Techniques

Mittal Technologies — Tue, 18 Aug 2026 12:32:14 +0000

I've shipped enough slow websites to feel a little embarrassed writing this, honestly. Early in my career I once spent three weeks polishing a hero animation on a client site and completely ignored the fact that the hero image itself was a 4MB PNG. Nobody clapped for the animation. They just bounced before it finished loading. If you're looking for practical web performance optimization techniques that actually move the needle instead of chasing Lighthouse vanity metrics, here's the list I actually use on real projects, not the theoretical one from a conference talk.

I'm grouping these into images, code, network, and rendering, because that's roughly the order I audit a slow site in — the same checklist I'd hand to a client comparing options at a best website designing company in Ludhiana versus doing it in-house.

Images (Usually the Biggest Win, Fastest)

1. Compress and resize before upload, not after. Sounds obvious, but I still find raw 6000px camera exports sitting in production img folders more often than I'd like to admit.

2. Serve modern formats. WebP and AVIF genuinely cut file size significantly compared to JPEG/PNG for equivalent quality. A basic fallback pattern:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero banner" loading="lazy">
</picture>

3. Lazy-load anything below the fold. Native loading="lazy" gets you most of the way there for free — no library required for the common case.

4. Use responsive srcset instead of one giant image for every screen size. Mobile users don't need your 2400px desktop hero.

5. Self-host critical images instead of pulling them through a slow third-party CDN you don't control the caching headers on.

Code and Bundle Size

6. Audit your bundle before you optimize anything else. npx webpack-bundle-analyzer or the equivalent for your build tool will usually surface an embarrassing dependency you forgot you imported for one function.

7. Code-split by route. Most frameworks make this close to free now:

const Dashboard = React.lazy(() => import('./Dashboard'));

8. Tree-shake dead code. I've found entire unused UI libraries sitting in production bundles because someone imported the whole package instead of the one component they needed.

9. Defer or async non-critical JavaScript. Anything that isn't needed for first paint shouldn't be blocking it:

<script src="analytics.js" defer></script>

10. Kill zombie third-party scripts. Old chat widgets, abandoned A/B test tools, tracking pixels nobody checks anymore — audit your <head> every few months and you'll usually find at least one script nobody remembers adding.

Network and Delivery

11. Use a CDN properly, not just for static assets but for cached HTML where it makes sense. Edge caching shaves real time off Time to First Byte.

12. Enable HTTP/2 or HTTP/3 if your hosting supports it. Multiplexed requests mean you stop needing to hack around the old six-connections-per-domain limit with domain sharding.

13. Set proper cache headers. I still see sites serving Cache-Control: no-cache on assets that haven't changed in a year. That's just making every returning visitor re-download everything.

Rendering and Layout

14. Reserve space for images and ads to avoid layout shift. This one bit me directly — a client's CLS score tanked because ad slots loaded after content, shoving everything down mid-read. Fix is usually just setting explicit dimensions:

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

15. Minimize main-thread work during load. Heavy synchronous JS on page load blocks interactivity even if the page looks done. Chrome DevTools' Performance tab will show you exactly where the main thread is stuck if you profile a real load.

The Part Nobody Wants to Hear

Here's my honest take after doing this for a while — most sites don't need a fancy new framework or a full rebuild to get fast. They need someone to actually sit down, run a Lighthouse audit, and fix the boring stuff nobody prioritized. I've turned five-second load times into sub-two-second ones with nothing more exotic than image compression, script auditing, and proper caching headers. No rewrite required.

If you're managing this for a client site and don't have the bandwidth to do a full technical audit yourself, it's worth outsourcing to a web development company in Ludhiana that specializes in performance work specifically — not every agency treats this as a real discipline, and it shows in the final output.

A Quick Word on Measuring, Because Guessing Is Useless

Don't optimize blind. Run Lighthouse, WebPageTest, or Chrome's own Core Web Vitals report before and after every change, and isolate variables where you can — it's the same discipline I'd expect from a best website designing in Ludhiana provider running a client audit. I've seen developers "fix" something that wasn't actually the bottleneck because they didn't measure first, then wonder why the numbers didn't move.

If your team doesn't have someone dedicated to this, checking website development cost for a focused performance sprint is usually far cheaper than it sounds — this is scoped, contained work, not a full rebuild, and pricing should reflect that.

Wrapping Up

None of these 15 techniques are individually revolutionary. That's kind of the point — performance work is rarely about one clever trick, it's about methodically clearing out a dozen small inefficiencies that accumulated because nobody was watching. Pick the three or four from this list that apply most to your stack, measure your baseline, fix them, and measure again. That loop, repeated a few times, will get you further than chasing whatever's trending on Twitter this week.

One thing I'd add for anyone maintaining a legacy codebase: performance debt compounds the same way tech debt does. A site that was fast at launch three years ago has probably accumulated a dozen small regressions since — a new tracking pixel here, an unoptimized image there, a dependency upgrade that quietly doubled bundle size. Treat performance audits as a recurring calendar item, not a one-time fire drill, and you'll spend a lot less time firefighting later.

If you're stuck and it's genuinely outside your team's expertise, looking into affordable website development services for a dedicated audit is a reasonable move — sometimes an outside set of eyes catches the thing you've been staring at for months.

Building a Scalable Mobile App in 2026: Architecture, Tech Stack, and the Mistakes I'd Rather You Skip

Mittal Technologies — Fri, 07 Aug 2026 11:29:19 +0000

I rebuilt an app's backend architecture twice in eighteen months because nobody asked the scalability question early enough. Twice. That's the kind of mistake that eats a quarter of your roadmap and makes your team quietly resent every sprint planning meeting for weeks. So, when people ask me about building a scalable mobile app in 2026, my answer usually starts with "let's talk about what breaks first," because that's more useful than a generic tech stack recommendation copy-pasted from a comparison article.

This isn't a theory post. It's mostly things I learned by getting them wrong first.

Start With the Data Layer, Not the UI

Everyone wants to talk about frontend frameworks first because that's the fun, visible part. Wrong order. Your data layer decisions - how you structure your database, how you handle caching, whether you're using REST or GraphQL, determine how painful scaling becomes six months down the line, long after your onboarding screens are already pixel-perfect. A team that's actually done mobile app development in Ludhiana at any real scale will usually tell you the same thing before they'll even discuss your UI mockups.

If your app has any kind of social or real-time feature, think hard about read-heavy vs write-heavy patterns before picking your database. Postgres with proper indexing handles a lot more than people give it credit for, and reaching for something exotic before you've hit actual bottlenecks is usually premature optimization dressed up as forward planning.

Pick an Architecture That Assumes Growth, Not One That Assumes Comfort

Monolithic architecture gets a bad reputation it doesn't always deserve. For a lot of apps, a well-structured modular monolith scales fine well past the point most teams need it to. Microservices solve real problems, but they also introduce real complexity, network latency between services, distributed transaction headaches, deployment orchestration that eats engineering time you'd rather spend on features.

My rule of thumb now: don't reach for microservices until you can articulate the specific scaling bottleneck they'd solve for you. "It's what big companies do" isn't a technical reason, it's a resume-driven decision, and I've watched teams pay for that mistake in velocity for a full year.

API Versioning: The Boring Thing That Saves You Later

This one always gets skipped in tutorials because it's not exciting, but it's saved me more headaches than almost anything else on this list. Once you have multiple app versions live simultaneously across app stores with different rollout speeds, breaking changes without versioning becomes a genuine nightmare. Something as simple as this goes a long way:

// Express route versioning example
const router = express.Router();

router.use('/api/v1/users', require('./routes/v1/users'));
router.use('/api/v2/users', require('./routes/v2/users'));

// Middleware to handle deprecated version warnings
app.use('/api/v1/*', (req, res, next) => {
  res.set('X-API-Deprecation-Notice', 'v1 will be sunset on 2026-12-01');
  next();
});

It looks trivial written out like this. It is not trivial when you're retrofitting it onto an API that fifty thousand active installs are already hitting.

Caching: Build It Before You Need It, Not After

Redis for session and hot-data caching has saved more launches than I can count, quietly, in the background, where nobody notices until it's missing. Here's roughly the pattern I reach for on read-heavy endpoints:

async function getUserProfile(userId) {
  const cacheKey = `user:profile:${userId}`;
  const cached = await redis.get(cacheKey);

  if (cached) return JSON.parse(cached);

  const profile = await db.users.findById(userId);
  await redis.set(cacheKey, JSON.stringify(profile), 'EX', 3600);

  return profile;
}

Simple, sure, but the number of teams I've watched skip even this basic layer until their database started choking under load is honestly higher than it should be.

Choosing Your Tech Stack Without the Hype Cycle Getting Involved

This is where a lot of teams get talked into decisions that don't fit their actual needs, often by whoever reads the most Twitter threads that week. A few things I actually weigh now:

Team familiarity matters more than theoretical performance gains, a team fluent in one stack ships faster and with fewer bugs than a team learning a "better" one mid-project
Cross-platform frameworks have matured enough that native-only decisions need real justification now, not default assumption
Backend language choice should match your team's hiring pool, not just what's trending in benchmarks nobody on your team will actually read closely
Third-party dependencies need an exit plan, what happens if that SDK gets deprecated or the pricing changes overnight

A solid mobile app development company in Ludhiana that's shipped past the "comfortable MVP" stage will usually push back on trendy choices for exactly these reasons, and that pushback is worth listening to even when it's not what you wanted to hear.

Automate Your Pipeline Early, Even for Small Teams

CI/CD feels like overhead when you're a three-person team shipping your first build. It stops feeling like overhead the first time a manual deployment error takes down production at 11pm. A minimal GitHub Actions setup gets you most of the way there:

name: Mobile CI
on: [push]
jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run test
      - run: npm run build

The five hours you spend setting this up in month one saves you dozens of hours of manual deployment errors by month six.

Platform-Specific Architecture Decisions Aren't Optional

A lot of scalability problems aren't really technical, they're experience gaps, teams making the same architectural mistakes another team already made and fixed years ago. An android app development company in Ludhiana with real experience handling device fragmentation and background process limits across manufacturers will architect your app differently from day one, in ways that save serious rework later.

The iOS side has its own scaling landmines. Memory management quirks and Apple's evolving background execution rules cause a category of bugs that only show up once you're actually at scale, not during testing on a handful of devices, which is exactly why an iOS app development company in Ludhiana familiar with those specifics matters more than people expect going in.

Budget for Scale, Not Just for Launch

This is the part founders underestimate constantly. Any mobile app development cost in Ludhiana or wherever you're building tends to get quoted against launch requirements, not against what happens once you actually gain traction. Ask specifically what architectural decisions in your quote account for scale, and which ones would need revisiting once you hit meaningful user numbers. That gap between "launch-ready" and "scale-ready" is where budgets quietly blow up six months post-launch.

The Honest Takeaway

Scalability isn't a feature you bolt on later; it's a mindset baked into decisions you make in week one, most of which feel unnecessary at the time because your current user base doesn't need them yet. Build for where you're realistically heading in eighteen months, not for an infinite hypothetical scale you might never reach. That balance, practical, not paranoid, is what actually separates apps that hold up under growth from ones that quietly fall apart the first time something goes right.

Designing APIs That Survive Product Growth: Lessons from Real Business Applications

Mittal Technologies — Mon, 03 Aug 2026 12:47:52 +0000

I've rewritten the same API three times in my career. Same core domain, different companies, same mistake pattern each time: designing for the feature request in front of me instead of the shape the product was clearly heading toward. So, this isn't a theory. This is stuff I've paid for in weekend debugging sessions, and I'd rather you skip that part.

Designing APIs that survive product growth isn't really about picking the "right" framework or following a REST-vs-GraphQL debate to its conclusion. It's about a handful of decisions you make early that either bend or break as your product scales. Let's get into the ones that actually matter.

Versioning Is Not Optional, Even for MVPs

I get it - when you're shipping v1 of a product, versioning your API feels premature. It isn't. The cost of adding /v1/ to your routes on day one is basically zero. The cost of retrofitting versioning after you've got three external integrations depending on your current response shape is measured in weeks, not hours.

# Do this from day one, even if v2 never happens
/api/v1/users
/api/v1/orders

The one time I skipped this "because it's just an internal tool," that internal tool got exposed to a partner integration eight months later, and I spent a very unpleasant sprint building a compatibility shim instead of just having versioned it originally.

Stop Designing Endpoints Around Your Database Schema

This is the single most common mistake I see in early-stage codebases. Your /users endpoint returns exactly what's in the users table, joined with whatever else seemed convenient at the time. It works fine until the product needs change and now your API response is a weird hybrid of three different features bolted together because nobody separated the resource model from the storage model.

Design your API around what the client actually needs, not around your ORM's default serialization. It's more upfront work. It saves you from breaking five frontend features every time you refactor a table.

Pagination From the Start, Even If You Only Have 10 Records

I've watched a /products endpoint go from returning 12 items to returning 40,000 without anyone touching the response format, because "we'll add pagination later." Later arrives as a production incident, usually. Cursor-based pagination is a little more work to implement than offset-based, but it holds up much better once your dataset is large and mutating frequently.

{
  "data": [...],
  "pagination": {
    "next_cursor": "eyJpZCI6MTIzfQ==",
    "has_more": true
  }
}

Error Responses Deserve as Much Design Effort as Success Responses

Nobody designs their error format until something's already on fire. Then you end up with three different error shapes across your API because different developers handled it differently under pressure. Standardize this early:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is already in use",
    "field": "email"
  }
}

Consistent error shapes matter more than people expect once you've got a frontend team, a mobile team, and maybe a partner integration all-consuming the same API and all needing to handle failures gracefully.

Rate Limiting Before You Think You Need It

I once built a fairly straightforward B2B integration API with no rate limiting, reasoning that our client volume was low and predictable. Then one client's cron job misfired and hit our endpoint 4,000 times in ten minutes, taking down a shared service for everyone else on the platform. Rate limiting isn't just about abuse prevention - it's about isolating the blast radius of someone else's bug from your own uptime.

Idempotency for Anything That Mutates State

If your API handles payments, order creation, or anything where a duplicate request causes real damage, idempotency keys aren't a nice-to-have. Client retries happen constantly - flaky networks, timeout misconfigurations, mobile clients on bad connections. Without idempotency support, a single dropped response can trigger a client retry that duplicates a transaction.

POST /orders
Idempotency-Key: 8f14e45f-ceea-4bb7-8f37-1caf1f5f...

Document as You Build, Not After

This one's less technical and more cultural, but it matters just as much. Undocumented internal APIs accumulate tribal knowledge that lives in three people's heads and dies the moment one of them leaves. OpenAPI specs generated from your route definitions cost you almost nothing if you set it up early, and they save the next developer, possibly future you, from reverse-engineering behavior from response payloads.

Where This Shows Up in Client Work

I spend a chunk of my time consulting for small businesses building their first real product API, and the pattern above repeats constantly. A founder comes in after outgrowing a no-code backend, and the conversation almost always starts with "how much is this actually going to cost us to fix properly." If you're weighing that decision yourself, it's worth getting a straight answer on website design and development cost in Ludhiana before committing to a rebuild, because the backend work I'm describing here is usually a fraction of what people assume once it's scoped honestly.

That said, not every team needs a full backend overhaul immediately. I've seen founders get quoted for a ground-up rebuild when a targeted API refactor, done through a genuinely affordable website development services in Ludhiana provider, would've solved 80% of the pain for a fraction of the price and timeline.

For teams evaluating who actually builds this stuff well, it's worth treating backend architecture the same way you'd vet website development businesses trust for their frontend - ask for real examples of APIs they've built that survived a scaling event, not just a portfolio of pretty dashboards.

On the design side specifically, the same scrutiny applies. A best website designing company in Ludhiana should be able to explain how their design decisions hold up once real usage data starts coming in, not just how the mockups looked in the pitch.

If you're further along and need a partner who can own both the product architecture and the delivery timeline end to end, look specifically for a best website development company in Ludhiana with engineers who can talk you through their actual API design decisions, not just their tech stack buzzwords. The conversation itself tells you a lot about whether they've actually lived through a scaling problem or just read about one.

The Bigger Pattern Here

Every one of these mistakes shares a root cause: optimizing for the immediate feature instead of the trajectory of the product. It's a genuinely hard discipline to maintain under deadline pressure, and I don't think there's a clean fix for that beyond experience and a bit of institutional scar tissue.

If you're building internal tooling and thinking "this'll never need to scale," I'd gently push back on that assumption. I've seen a surprising number of "temporary internal APIs" become load-bearing infrastructure within a year. Design accordingly, even when it feels like overkill in the moment - the overkill is a lot cheaper than the rebuild.

What Does a Website Developer Actually Do? Services, Explained by Someone Who's Been in the Trenches

Mittal Technologies — Tue, 28 Jul 2026 11:47:50 +0000

I still remember a client asking me, mid-project, "so what exactly are you doing all day, is it just typing?" Fair question, honestly. From the outside, development looks like a black box - stuff goes in, a website comes out. But if you've actually done this work, you know what a website developer actually does covers a lot more ground than writing HTML and hoping for the best. Let me break down the real service categories, with a few war stories and code snippets along the way, because I think the abstract descriptions people usually give don't tell you much.

Front-End Work: More Than Just "Making It Look Nice"

This is the part clients understand best, at least on the surface - buttons, layouts, colors, fonts. But the actual work is mostly about behavior under different conditions. Does the nav collapse properly on a 375px screen? Does that hero image not shift the layout while it loads (hello, Cumulative Layout Shift)? I've lost entire afternoons chasing a flexbox bug that only appeared on Safari, which, if you've done frontend work, you already knew was coming before I finished the sentence.
Here's a small, real example - a responsive nav toggle I've rebuilt a dozen times with minor variations:

.nav-menu {
  display: none;
}

@media (max-width: 768px) {
  .nav-toggle {
    display: block;
  }
  .nav-menu.active {
    display: flex;
    flex-direction: column;
  }
}

Simple on paper. In practice, you're debugging why it snaps shut on iOS Safari but not Chrome, or why the animation stutters on a mid-range Android phone. Nobody tells you at the start of your career that half this job is just "why does this device behave differently."

Back-End Development: Where the Actual Logic Lives

This is the part that's invisible to most clients, and honestly, that's kind of the point - if it's working right, you never notice it. Server logic, database structure, API integrations, authentication, all the plumbing that makes forms actually submit somewhere and payments actually process.
A basic example, a simple contact form handler:

app.post('/contact', async (req, res) => {
  const { name, email, message } = req.body;

  if (!name || !email || !message) {
    return res.status(400).json({ error: 'Missing required fields' });
  }

  try {
    await sendEmail({ to: 'admin@example.com', name, email, message });
    res.status(200).json({ success: true });
  } catch (err) {
    res.status(500).json({ error: 'Failed to send message' });
  }
});

Looks basic, and it is, but I've seen this exact pattern implemented wrong more times than I can count - no validation, no error handling, forms that just silently fail and the business owner never finds out they've been missing leads for three months. A competent website development company Ludhiana clients rely on will always build this defensively, not optimistically.

Technical SEO: The Part Nobody Asks About Until Traffic Drops

I used to think SEO was someone else's job, a marketing thing that happened after I shipped the site. I was wrong, and I learned that the hard way on a project where rankings tanked post-launch because nobody had set up canonical tags correctly, and every page was quietly telling Google to index the homepage instead.
A basic schema example I add to most business sites now, without being asked:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Business Name",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Ludhiana",
    "addressRegion": "Punjab"
  }
}

Small addition, real impact on how search engines understand the page. If you're evaluating website development services in Ludhiana, ask specifically whether structured data and canonical tag hygiene are part of the base package or a separate line item. It shouldn't be treated as optional in 2026.

Performance Optimization: The Unsexy Work That Actually Matters

Nobody gets excited about lazy loading images or minifying CSS, but this is where a huge chunk of real developer time goes, especially post-launch. Core Web Vitals aren't just a Google checkbox; they genuinely affect whether people stick around or bounce after three seconds of a spinning loader.

<img src="hero.jpg" loading="lazy" width="800" height="600" alt="Product showcase">

That one attribute, loading="lazy", seems trivial. But multiply it across a site with forty images and you've meaningfully changed load time. I've had clients skeptical that "such a small thing" mattered, right up until their PageSpeed score jumped fifteen points and their mobile bounce rate dropped noticeably the following month.

Maintenance and Ongoing Support

This is the part almost nobody budgets for properly, and it's the part that quietly determines whether a site is still functioning well two years from now. Security patches, plugin updates, broken link checks, backup systems, unglamorous, recurring work that prevents the 2 AM "the site is down" phone call.
I always tell clients this directly: a web developer Ludhiana businesses can actually rely on long-term isn't just the person who builds the site, it's the person still answering the phone eight months later when something breaks. That distinction matters more than most people realize before they've been burned once.

Consulting and Strategy, Which Is Honestly Half the Job

A lot of the actual value I provide happens before I write a single line of code, figuring out what the client actually needs versus what they think they're asking for. Someone says, "I want an e-commerce site," and the real conversation is about their inventory size, their shipping logistics, their payment preferences, whether they even need full e-commerce or just a "contact to order" page with a product catalog.
This is where experience in web development in Ludhiana specifically starts to matter, because local business patterns, export documentation needs, GST invoicing quirks, regional payment gateway preferences, aren't things you learn from a generic tutorial. You learn them from doing the work here, repeatedly, and getting it wrong at least once.

So, What Does a Developer Actually Do?

Design, build, secure, optimize, maintain, and occasionally talk a client out of a bad idea before it costs them money. It's less "typing" and more "solving problems that only reveal themselves once real users start clicking around." If you're hiring one, look for a website developer in Ludhiana who talks about all six of these areas, not just the pretty frontend part. The invisible work is usually where the real value sits.

Next.js + Contentful vs Next.js + Sanity: A Real Performance Comparison

Mittal Technologies — Mon, 20 Jul 2026 09:29:01 +0000

Everyone recommends "just pick a headless CMS and pair it with Next.js" like it's a five-minute decision. It isn't. When our team was scoping a rebuild for a client who wanted faster page loads without losing editorial flexibility, we actually benchmarked Contentful and Sanity side by side instead of going with whatever had the shinier marketing site. As a website development company in Ludhiana that ships client projects on both stacks, here's what the numbers and the day-to-day developer experience actually looked like.

Setup

We built the same landing page and blog template twice — once pulling content from Contentful's REST/GraphQL API, once from Sanity's GROQ-powered API — both deployed on Next.js 14 with ISR enabled. Same hosting, same image optimization pipeline, same Lighthouse testing conditions. We wanted a genuinely fair comparison, which meant resisting the urge to over-optimize one stack more than the other just because it happened to be more familiar.

// Contentful fetch example
const entries = await client.getEntries({
  content_type: 'blogPost',
  order: '-fields.publishDate',
  limit: 10
});

// Sanity fetch example using GROQ
const posts = await sanityClient.fetch(
  `*[_type == "post"] | order(publishDate desc)[0...10]`
);

What We Found on Speed

Sanity's GROQ queries came back noticeably faster for nested, relational content — think blog posts with linked authors, categories, and related posts. Contentful handled flat content types just as well, but once we needed two or three levels of reference resolution, response times crept up unless we restructured the content model. Neither was "slow," to be clear — we're talking differences in the 100-300ms range, which matters for Core Web Vitals but won't make or break a small brochure site.

Cache behavior differed too. Contentful's CDN-backed delivery API is reliably fast for read-heavy traffic once cached, but the first uncached request after a content update showed a small but measurable lag. Sanity's CDN caching behaved similarly, though its real-time preview mode occasionally introduced its own overhead during active editing sessions, which is worth knowing if your editorial team previews frequently before publishing.

Developer Experience Differences

Sanity's Studio is code-based and highly customizable, which developers on our team preferred
Contentful's editor UI is more polished out of the box for non-technical content teams
GROQ has a steeper learning curve than Contentful's query language
Contentful's free tier is more generous for small projects; Sanity's pricing scales differently at volume
Webhooks and real-time preview worked more smoothly with Sanity in our testing

One thing that surprised us: image handling. Sanity's built-in image pipeline with hotspot cropping saved real development time compared to manually configuring Contentful's image API parameters. Small thing, but it adds up across a project with hundreds of images, especially when a client's content team is uploading new photography every week without a developer double-checking crop point.

Content Modeling Differences That Actually Matter

Beyond raw speed, the two platforms encourage slightly different habits. Contentful's content type builder nudges you toward more rigid, form-like structures, which content editors generally find intuitive. Sanity's schema-as-code approach gives developers more control over validation and conditional fields, but it does mean content modeling becomes a developer task rather than something a content strategist can adjust independently. If your team wants editors to be able to add new fields without filing a dev ticket, that's a real consideration, not a minor one.

Cost at Scale

Pricing structures diverge more than people expect once a project grows past a handful of content types. Contentful bills primarily around API calls and environments, which can get expensive quickly for high-traffic sites unless caching is well configured. Sanity's pricing leans more on dataset size and bandwidth, which tends to favor content-heavy sites with moderate traffic over traffic-heavy sites with lean content. Neither pricing model is a trap exactly, but both can surprise a client who scaled past their original estimate without revisiting the numbers, so we now build a rough cost projection into every proposal rather than leaving it as a line item nobody checks until the first real invoice arrives.

When to Pick Which

Contentful tends to make sense for larger marketing teams who want a familiar, low-friction editor and don't mind paying for that convenience. Sanity fits teams with developers comfortable customizing the editing environment and who need flexible, relational content modeling. We've built client projects on both, and honestly, neither is objectively "better" — it depends on team structure more than raw performance. If your content team is non-technical and change-averse, Contentful reduces friction. If your developers want control, Sanity gives them more of it.

We put a version of this comparison into practice while rebuilding infrastructure for a client project, where content flexibility mattered more than editorial simplicity, so Sanity ended up being the right call for that particular build — the kind of judgment call a software company in Ludhiana makes on a project-by-project basis rather than defaulting to one platform every time.

What We'd Tell a Team Starting From Scratch

Don't pick a CMS based on a blog post, including this one. Build a small prototype of your actual content model — not a generic blog template — in both platforms before committing budget to either. The differences that matter most tend to show up in your specific content relationships, not in generic benchmarks. If your team doesn't have the bandwidth to run that kind of trial, our website designing company in Ludhiana has done this exact exercise enough times to shortcut the process for you.

Wrapping Up

Benchmark your own content structure before committing to either platform — generic comparisons like this one are a starting point, not a final answer. If you want a second opinion on your specific setup, our website developer in Ludhiana team has run this exact comparison for multiple client stacks and can walk through what fits yours. Reaching out to us directly is a faster route than another week of research.

// Quick reference: fetching with revalidation in Next.js
export async function getStaticProps() {
  const data = await client.getEntries({ content_type: 'post' });
  return { props: { data }, revalidate: 60 };
}

MCP Explained for Web Developers

Mittal Technologies — Thu, 16 Jul 2026 08:24:52 +0000

I ignored MCP for longer than I should have because the acronym soup around AI tooling right now is genuinely exhausting, and I assumed it was another framework-shaped thing I'd need to relearn in six months. Then I actually built something with it over a weekend, a small internal tool connecting Claude to our project's data, and it clicked faster than I expected. If you're a web developer who's been putting this off the same way I did, here's the version of the explanation I wish someone had given me first.

What MCP Actually Is

Model Context Protocol is an open standard for connecting AI models to external tools and data sources in a consistent, predictable way, the kind of infrastructure a best digital marketing company in Ludhiana building AI-powered client tooling now has to think about too. Before MCP, every AI integration you built was custom, your own function-calling setup, your own auth handling, your own way of describing what the model could do. MCP standardizes that.

Think of it roughly like this: if REST gave web developers a consistent way to expose data over HTTP, MCP gives AI applications a consistent way to expose tools and data to a model, regardless of which AI provider is calling it.

The Core Pieces

An MCP setup has a few consistent parts:

MCP Server — exposes tools, resources, and prompts that a model can use
MCP Client — the AI application (like Claude) that connects to one or more servers
Tools — functions the model can call, similar conceptually to API endpoints
Resources — data the model can read, like files or database records
Transport — how the client and server actually communicate, commonly over stdio locally or HTTP/SSE for remote servers

If you've built a REST API before, tools will feel familiar. If you've worked with GraphQL resolvers, resources will feel familiar too.

A Minimal Example

Here's roughly what a basic MCP server tool definition looks like in practice:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

const server = new McpServer({
  name: "project-tools",
  version: "1.0.0"
});

server.tool(
  "get_task_status",
  "Retrieve the current status of a project task by ID",
  { taskId: z.string() },
  async ({ taskId }) => {
    const task = await db.tasks.findById(taskId);
    return {
      content: [{ type: "text", text: JSON.stringify(task) }]
    };
  }
);

That's the whole shape of it. You define a tool, describe what it does in plain language (the model reads that description to decide when to use it), specify the expected input, and return a result. No custom prompt engineering to teach the model your API shape, no brittle regex parsing of model output to extract function calls.

Why This Matters If You're Building AI Features

Before MCP, adding a new data source to an AI feature usually meant a lot of repeated, provider-specific work, exactly the kind of overhead a digital marketing agency Ludhiana building custom automation tooling for clients wants to avoid:

Writing custom function definitions for whichever provider's function-calling format you were using
Rebuilding that integration if you switched providers or supported multiple ones
Handling auth and connection logic separately for every single integration

With MCP, you write the server once, and any MCP-compatible client can use it, without you rebuilding provider-specific glue code every time the AI landscape shifts, which right now is often.

A Realistic Use Case

Say you're building an internal tool where a team wants to ask Claude questions about your company's live inventory data instead of digging through a dashboard. Without MCP, you'd be writing custom prompt templates, stuffing inventory data into context, or a bespoke function-calling setup tied to one provider's API.
With MCP, you'd expose a search_inventory tool and an inventory_item resource once. The model calls the tool when it needs live data, gets structured results back, and you're not rewriting integration logic every time you add a new AI feature to the product.

Where People Get Tripped Up Early On

A few things caught me off guard the first time through, and they're worth knowing before you build anything a digital marketing in Ludhiana team might eventually depend on for reporting automation:

Tool descriptions matter more than you'd expect, since the model relies entirely on your description to decide when and how to call a tool. Vague descriptions produce vague tool usage.
Error handling needs to be explicit in your return values, since the model can't infer a failure state from a thrown exception the way your app's error boundary would
Local (stdio) vs remote (HTTP/SSE) transport changes your deployment story significantly, decide early which one your use case actually needs

Should You Actually Use This Right Now

If you're building AI features that need to reach live data or perform actions beyond generating text, probably yes. If you're doing straightforward prompt-and-response work with no external tool calls, MCP is overhead you don't need yet. It's a solution to the integration fragmentation problem specifically, not a replacement for basic API design.

Teams building this kind of AI feature work into client projects, the sort of thing a best SEO company in Ludhiana offering broader digital services increasingly gets asked about, tend to treat MCP as infrastructure worth learning now rather than waiting until it's unavoidable.

A Quick Look at Resources, Not Just Tools

Tools get most of the attention in MCP writeups, but resources are worth understanding too, since they cover the "give the model read access to data" side rather than the "let the model do something" side:

server.resource(
  "project-tasks",
  "tasks://active",
  { description: "List of currently active project tasks" },
  async () => {
    const tasks = await db.tasks.findActive();
    return {
      contents: [{
        uri: "tasks://active",
        mimeType: "application/json",
        text: JSON.stringify(tasks)
      }]
    };
  }
);

The distinction matters in practice. Tools are for actions and computed results; resources are for exposing data the model can read directly. Mixing the two up early on is a common source of confusion. I initially tried to model everything as a tool, including things that were really just read access to static data, and ended up with a server that was harder to reason about than it needed to be. Once resources and tools are separated cleanly, the rest of the implementation tends to fall into place faster, and it's the sort of infrastructure work a SEO services in Ludhiana provider building internal automation would want to set up correctly from the start rather than refactored later.

JavaScript SEO: Common Rendering Pitfalls (Learned the Hard Way)

Mittal Technologies — Tue, 14 Jul 2026 11:31:07 +0000

I once spent three days convinced Google was just "being slow" to index a client's newly rebuilt React site. Turned out Googlebot was rendering the page just fine, it just wasn't seeing the same content a user's browser saw, because a chunk of it loaded via a client-side fetch call that fired after an intersection observer triggered on scroll. A crawler doesn't scroll. That was a dumb, expensive lesson, and I've since learned it's an extremely common one.

JavaScript SEO isn't really about SEO knowledge at all. It's about understanding what actually happens between your framework rendering content and a crawler trying to index it, and that gap is where most rendering pitfalls live.

The Core Problem, Explained Simply

Search engines (and increasingly, AI crawlers) need to see your final rendered HTML, not just your initial server response, a distinction that a SEO services in Ludhiana provider running technical audits checks before anything else. If your content depends on client-side JavaScript execution to appear, you're trusting the crawler to:

Actually, execute your JS correctly
Wait long enough for async operations to resolve
Not hit a rendering budget limit before your content loads
Handle whatever framework-specific quirks your app introduces

Googlebot generally handles this reasonably well now. A lot of other crawlers, including several AI bots, are far less reliable at it.

Pitfall 1: Content Behind User Interaction

// This pattern is a crawler trap
useEffect(() => {
  const observer = new IntersectionObserver(() => {
    fetchContent().then(setContent);
  });
  observer.observe(ref.current);
}, []);

If your important content only loads after a scroll event, a click, or a hover, most crawlers will never see it. I've caught this exact pattern hiding pricing tables, product descriptions, and entire FAQ sections from indexing.

Fix: load critical content on initial render and treat scroll-triggered loading as a progressive enhancement for below-the-fold, non-essential content only.

Pitfall 2: Relying Entirely on Client-Side Rendering

// Client-only rendering leaves an empty shell for crawlers
function App() {
  const [data, setData] = useState(null);
  useEffect(() => {
    fetch('/api/content').then(res => res.json()).then(setData);
  }, []);
  return data ? <Content data={data} /> : <Loading />;
}

A crawler hitting this before the fetch resolves sees a loading spinner and not much else. Depending on rendering budget and timeout behavior, that might be all it ever indexes.

Server-side rendering (SSR) or static generation solves this at the source
If a full SSR migration isn't realistic, at minimum pre-render your highest-value pages
Frameworks like Next.js, Nuxt, and SvelteKit handle this natively, it's usually a configuration problem, not a rewrite

Pitfall 3: Broken or Missing Canonical Signals in SPAs

Single-page apps handling routing client-side sometimes fail to update canonical tags, meta descriptions, and title tags per route. I've seen sites where every single route reported the same title tag because the meta update logic only ran on initial load, not on client-side navigation.

// Easy to miss: update meta tags on route change, not just mount
useEffect(() => {
  document.title = pageTitle;
  updateMetaTag('description', pageDescription);
}, [route]); // don't forget the dependency array

Pitfall 4: Infinite Scroll Without Paginated Fallbacks

Infinite scroll feels great for users. For crawlers, content past the initial load is often invisible unless you're providing an alternative path to it.

Add paginated URLs alongside infinite scroll (?page=2, ?page=3) even if most users never see them
Link those paginated URLs somewhere crawlable, a sitemap entry or a visible "load more" link with a real href
Test with JS disabled to see what actually persists without client-side execution

Pitfall 5: Render Blocking on Slow Third-Party Scripts

If your critical content waits on a third-party script (a personalization engine, an A/B testing tool, a chat widget's data layer) to finish before rendering, you're at the mercy of that script's reliability and speed inside a crawler's rendering budget, which is typically far less generous than a real browser's.

Audit what's actually blocking your main content render, not just what's blocking visual paint
Move non-essential third-party scripts to load after critical content, not before

How to Actually Test This

Use Google Search Console's URL Inspection tool and look at the rendered HTML, not just the fetched source
Fetch your page with JavaScript disabled and manually diff it against what a real browser show
Check server logs for crawler user-agents and confirm they're actually hitting your key routes, not just the homepage, the kind of check a digital marketing in Ludhiana team runs routinely as part of ongoing technical maintenance

This kind of technical audit is exactly the layer a best digital marketing company in Ludhiana usually runs before touching content strategy at all, since no amount of content work fixes a page, a crawler can't actually see.

What I'd Prioritize First

If you're triaging a site with rendering issues and can't fix everything at once, this is the order I'd generally recommend, similar to how a best SEO company in Ludhiana would sequence a technical audit for a client under time pressure:

Fix content that's entirely hidden behind interaction first, since that's a hard zero for crawlability
Move to SSR or pre-rendering for your highest-traffic-potential pages next
Fix per-route meta tag updates, since this affects how every page gets represented in search results
Address infinite scroll and third-party render blocking last, since these tend to be partial rather than total visibility losses

A Quick Diagnostic Script

If you want to check any of this yourself without opening DevTools manually, here's a rough script for diffing rendered vs. raw HTML using Puppeteer:

import puppeteer from 'puppeteer';

async function compareRendering(url) {
  const rawHtml = await fetch(url).then(r => r.text());

  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: 'networkidle0' });
  const renderedHtml = await page.content();
  await browser.close();

  console.log('Raw HTML length:', rawHtml.length);
  console.log('Rendered HTML length:', renderedHtml.length);
  console.log('Difference:', renderedHtml.length - rawHtml.length);

  // Anything wildly larger in rendered vs raw is content
  // that depends entirely on JS execution to appear
}

compareRendering('https://example.com/product-page');

A large gap between raw and rendered length is a decent early signal that meaningful content is JS-dependent. It's not a substitute for checking Search Console's actual rendered HTML, but it's a fast local sanity check before you go digging deeper, and it's often the first diagnostic a digital marketing agency Ludhiana runs before touching anything else on a client audit.

Lessons We Learned Building a Production Flutter App

Mittal Technologies — Thu, 09 Jul 2026 11:08:44 +0000

We shipped a Flutter app to production about eight months ago for a client in the logistics space, and I want to write down the stuff that actually bit us, because most "Flutter in production" posts I read beforehand were either marketing fluff or way too basic. This one's going to be messier and more specific, closer to what actually happened.

Quick context: cross-platform requirement (iOS + Android), tight timeline, a small team of three, and a backend already built in Node.js that we had to integrate with, not design from scratch. That combination shaped a lot of the decisions below. On the client side, this was a website development company Ludhiana, led engagement, with our team handling the Flutter build specifically while the client's existing web presence stayed with their original team.

State Management: We Switched Mid-Project and It Was Worth It

We started with Provider because it's what the docs push you toward early on, and honestly, it's fine for small apps. Once our widget tree got deeper and we had cross-screen state that needed to survive navigation (cart contents, auth state, a multi-step form), Provider started producing a lot of boilerplates and some annoying rebuild issues we couldn't cleanly debug.

We migrated to Riverpod around week six. Painful in the short term, genuinely worth it by the end. The dependency injection is cleaner, testing providers in isolation is much easier, and we stopped fighting context-based lookups breaking when widgets moved around in the tree.

final cartProvider = StateNotifierProvider<CartNotifier, CartState>((ref) {
  return CartNotifier(ref.read(apiClientProvider));
});

If I were starting fresh today, I'd just start with Riverpod (or Bloc if your team prefers a stricter pattern) and skip Provider entirely, unless the app is genuinely tiny and staying that way.

Platform Channels Are Where the Pain Lives

Flutter's "write once" promise holds up well for UI. It holds up much less well the moment you need something platform-specific, in our case, a barcode scanner integration and background location updates for delivery tracking. We ended up writing native platform channel code for both, and this is where the estimate blew past what we'd budgeted.

The barcode scanner especially, we tried three different Flutter plugins before landing on a combination of a maintained plugin plus custom native fallback code for a specific Android device model our client's driver actually used in the field. Turns out that device had a known camera focus bug that only showed up in production, never in our testing on newer phones. Lesson: test on the actual hardware your users have, not whatever's sitting in your office.

static const platform = MethodChannel('com.example.app/scanner');

Future<String?> scanBarcode() async {
  try {
    final result = await platform.invokeMethod<String>('startScan');
    return result;
  } on PlatformException catch (e) {
    // handle scanner-specific failures here
    return null;
  }
}

Build Times Got Bad, Then We Fixed Them

By month four, our CI build times had crept up to almost 20 minutes for a full iOS build, which killed our iteration speed. Most of it came from an over-bloated dependency list, we'd added packages for things we ended up building custom solutions for anyway and never removed the old dependencies. A dependency audit cut our pubspec down significantly and shaved several minutes off build time.

We also moved to splitting our CI pipeline, so Android and iOS builds ran in parallel instead of sequentially, which sounds obvious in hindsight but wasn't how our pipeline was originally set up. Small process fix, meaningful time saved across a team running multiple builds a day. It's a fix I'd now recommend to any website developer in Ludhiana working on a mobile-and-web hybrid team, since the CI habits that work fine for a single web repo often don't scale cleanly once mobile builds get added into the same pipeline.

API Integration and Error Handling Needed More Structure Than We Planned For

This is the unglamorous part nobody talks about enough. Our backend team (working separately, coordinated through a mobile app development in Ludhiana partnership on our side) had solid API docs, but real-world network conditions, spotty connectivity for delivery drivers moving between areas, exposed gaps in our error handling that our happy-path testing never caught.

We ended up building a proper retry-with-backoff layer and a local queue for actions taken while offline, syncing once connectivity returned. Should have built this from day one instead of bolting it on in month five once drivers started reporting "lost" data that was actually just stuck in a failed request nobody retried.

Future<T> withRetry<T>(Future<T> Function() action, {int retries = 3}) async {
  for (int attempt = 0; attempt < retries; attempt++) {
    try {
      return await action();
    } catch (e) {
      if (attempt == retries - 1) rethrow;
      await Future.delayed(Duration(seconds: pow(2, attempt).toInt()));
    }
  }
  throw Exception('Retry logic failed unexpectedly');
}

Testing Discipline Slipped Under Deadline Pressure, and We Paid For It

We had decent widget test coverage early on. Then the deadline got tighter, and testing was the first thing that got quietly deprioritized, which is a classic mistake, and we knew it was a classic mistake even while doing it. Two production bugs that shipped in month six would have been caught by tests we didn't have time to write. Not catastrophic, but embarrassing, and it cost more time to hotfix than it would have taken to just write the tests properly the first time.

If you're working with an app developer Ludhiana team or any external partner on a Flutter project, it's worth setting a hard rule upfront about minimum test coverage for anything touching payments, auth, or offline sync, the categories where bugs are expensive rather than just annoying.

What I'd Actually Do Differently Next Time

Start with Riverpod, not Provider. Budget real time for platform channel work if there's any hardware integration at all, don't assume a plugin will "just work" on every device. Set up parallel CI builds from day one. And don't let testing slip just because the deadline is tight; it always costs more time later than it saves now.

Flutter's genuinely good for cross-platform work when the app is UI-heavy and doesn't need deep hardware integration. The moment hardware or background processes get involved, budget extra time and extra patience, because that's where the framework's abstractions start leaking.

I Logged Every AI Suggestion During a Two-Week Client Project. These Were Actually Useful.

Mittal Technologies — Wed, 08 Jul 2026 06:36:41 +0000

I got tired of the extremes in this conversation. Half of Twitter acts like AI coding assistants are replacing developers by Friday. The other half insists it's all hallucinated garbage that wastes more time than it saves. So, on a two-week client project last month, I logged every AI suggestion I actually used, rejected, or modified, and the results were a lot more boring and more useful than either camp would have you believe.

Context first: this was a mid-sized e-commerce platform rebuild, React frontend, Node backend, fairly standard stack. I kept a running note file next to my editor, tagging every suggestion as accepted-as-is, accepted-with-edits, or rejected, along with a one-line reason why. Not scientific, but honest.

What Actually Turned Out Useful in Two Weeks of Real Work

Boilerplate and repetitive patterns were where AI suggestions earned their keep, no contest. Writing the fifth nearly identical form validation schema of the week, the AI correctly guessed the pattern from the first four and saved genuine typing time. Same with test scaffolding, given an existing test file's structure, it reliably generated new test cases following the same conventions, which I then filled in with actual assertions. Not glamorous, but it added up to real hours saved across two weeks.

// AI correctly inferred this pattern after seeing 3 similar schemas
const productSchema = z.object({
  name: z.string().min(1).max(200),
  price: z.number().positive(),
  sku: z.string().regex(/^[A-Z0-9-]+$/),
  inventory: z.number().int().nonnegative()
});

It was also genuinely good at explaining unfamiliar error messages and stack traces from libraries I didn't know well. One dependency threw a cryptic error about a circular reference during serialization, and instead of digging through GitHub issues for twenty minutes, I pasted the trace and got a plausible explanation in seconds, which turned out to be correct once I verified it against the library's source.

Where It Actively Wasted My Time

Business logic specific to this client's inventory rules was where things fell apart. The platform had a genuinely unusual rule, certain product bundles needed inventory decremented from a shared pool, but only during specific promotional windows, with a fallback to individual inventory tracking otherwise. Every suggestion confidently implemented the common, generic version of bundle inventory logic, which was wrong for this client's actual business rule. It wasn't a bad suggestion in a vacuum. It was a wrong suggestion delivered with total confidence, which is a worse failure mode than an obviously broken suggestion, because it takes longer to notice the mistake.

I also burned time on suggestions for the payment integration that looked plausible but referenced API methods that didn't exist in the version of the SDK we were actually using. This is the failure mode I trust least, code that reads perfectly reasonably, compiles-looking syntax, references a method name that sounds exactly like something that should exist, and simply isn't real. Caught it because I actually ran the code rather than trusting it on sight, which is the only defense against this particular problem.

The Middle Ground: Accepted With Real Edits

This was the largest category by volume, honestly. Suggestions that got the shape of the solution right but needed real correction, wrong edge case handling, missing null checks, or a reasonable approach that just didn't account for something specific to this codebase's existing patterns. A good chunk of the API route handlers fell here: the AI correctly guessed our error-handling middleware pattern from context but consistently missed one specific logging call our team always includes for audit purposes on write operations.

// AI got the structure right, missed our team's audit logging convention
async function updateInventory(req, res) {
  try {
    const result = await inventoryService.update(req.body);
    auditLog.record('inventory.update', req.user.id, result); // had to add this manually every time
    res.json(result);
  } catch (err) {
    next(err);
  }
}

That pattern, right shape, missing the project-specific convention, was the single most common thing I logged across the two weeks. It's not a knock against the tooling. It just means these tools are pattern-matching against general conventions, not your specific team's unwritten rules, and there's no shortcut around teaching it those rules through context or just doing the edit yourself.
The same held true on the frontend side. Teams doing web design in Ludhiana work know component structure often follows a designer's specific system, not a generic pattern, and AI suggestions for UI components consistently defaulted to the most common layout convention instead of the client's actual design tokens, which had to be corrected by hand every time.

What I'd Actually Tell a Client About This

Clients ask us about this constantly now, usually some version of "should we worry about AI replacing our dev team, or should we be using it more aggressively." Working on client projects through web development in Ludhiana engagements, my honest answer is that it's a genuinely useful multiplier on the boring 60% of a project, boilerplate, test scaffolding, explaining unfamiliar errors and actively risky on the specific 40% that makes a client's business unique. The two-week log basically confirmed that split numerically instead of just as a vibe.

If your team is evaluating whether a website development company Ludhiana business relies on using these tools responsibly, the actual question to ask isn't "do you use AI." It's "how do you catch the confidently wrong suggestions before they ship." That's the part that actually matters, and it's the part most teams don't have a real answer for yet.

The Discipline That Actually Made This Useful

None of this worked well without actually running the code and reading it critically, every single time, no exceptions even for suggestions that looked obviously fine. The moment I got lazy about that, twice, that I caught, was exactly when a subtly wrong suggestion slipped through toward a commit before I caught it in review. Both times it was the "sounds right, isn't real" failure mode, not a logic error, which is genuinely the harder one to catch by just reading code.

Any web developer Ludhiana working with these tools daily should build this same habit, log it if you can, but at minimum, treat every suggestion as a draft from a very fast, very confident junior developer who's read a lot of code but doesn't know your specific codebase's history.

Final Tally

Across two weeks: roughly a third accepted as-is, mostly boilerplate and scaffolding. A little under half accepted with real edits, mostly missing project-specific conventions. The rest rejected outright, split fairly evenly between wrong business logic and hallucinated API references. Nothing dramatic. Nothing that confirms extreme take you'll find on social media.

If you're a website developer in Ludhiana or anywhere else deciding how much to lean on these tools, the honest answer from two weeks of actually counting is: a lot, for the boring stuff, and cautiously, with your own eyes on every line, for anything that touches the specific reason a client hired you instead of a template.

From Localhost to Production: A Developer's Website Hardening Checklist for 2026

Mittal Technologies — Tue, 07 Jul 2026 08:54:05 +0000

Every developer has that moment. You've been running the app on localhost for weeks, everything's fine, .env files are loose, CORS is wide open because who cares, it's just you and your terminal. Then deploy day comes and suddenly all that comfortable looseness becomes a liability. This developer's website hardening checklist for 2026 is basically the list we run through every single time before flipping something from dev mode to production, because muscle memory alone isn't enough anymore.

I say this as someone who's shipped that exact .env file to a public repo before. Once. Never again but once was enough to build this checklist out properly instead of trusting memory.

For context, this list comes out of running deploys for a website development company Ludhiana clients hire specifically because we treat this stuff as process, not vibes. Doesn't matter how experienced the individual dev is, checklists catch what tired brains miss at 2 AM before a launch.

Environment Variables: The Boring Check That Saves You

First thing, always: grep your entire codebase for anything that looks like a secret before you even think about deploying.

grep -rn "API_KEY\|SECRET\|PASSWORD\|TOKEN" --include="*.js" --include="*.ts" .

This catches the obvious stuff, but the sneakier problem in 2026 is framework specific. If you're on Next.js, double-check that anything without the NEXT_PUBLIC_ prefix genuinely isn't referenced anywhere in client-side code. It's an easy mistake to make when you're refactoring fast and forget which file runs where.

// This leaks to the browser bundle if used client-side
const dbPassword = process.env.DB_PASSWORD; // fine in API routes, disaster in components

// This is the safe pattern for anything the client legitimately needs
const publicKey = process.env.NEXT_PUBLIC_API_KEY;

CORS: Localhost Habits Don't Survive Production

On localhost, it's tempting to just slap Access-Control-Allow-Origin: * on everything and move on with building features. That habit needs to die before deploy.

// Localhost comfort, production liability
app.use(cors({ origin: "*" }));

// What should actually ship
app.use(cors({
  origin: process.env.NODE_ENV === "production"
    ? ["https://yourdomain.com"]
    : ["http://localhost:3000"],
  credentials: true
}));

I've seen this exact wildcard survive into production more times than I'd like to admit, usually because it got set during early testing and nobody circled back to tighten it. It's worth adding a pre-deploy grep for this pattern specifically.

Rate Limiting Isn't Optional Anymore

This one didn't used to make every checklist, but with AI-driven scraping and credential stuffing attempts up significantly this year, it's non-negotiable now. Even a basic implementation goes a long way.

import rateLimit from "express-rate-limit";

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  message: "Too many requests, slow down."
});

app.use("/api/", limiter);

Pair this with stricter limits specifically on auth routes, since login endpoints are the most common target for automated attempts.

Database Query Safety: Still the Classic Mistake

SQL injection feels like a solved problem until you find it in a client's supposedly modern codebase. It usually hides in places nobody thought to check, like a search feature bolted on late in development.

// Vulnerable, still shows up more than you'd expect
const query = `SELECT * FROM users WHERE email = '${userInput}'`;

// Parameterized, the way it should always be written
const query = "SELECT * FROM users WHERE email = $1";
db.query(query, [userInput]);

If you're on an ORM like Prisma or Drizzle, this risk drops significantly by default, but raw queries still creep in during performance optimization work, so it's worth a manual scan before shipping. Honestly, this is the kind of thing any decent web developer Ludhiana team should be scanning for reflexively, ORM or not.

Authentication Token Storage

Storing JWTs in localStorage is convenient and also a genuinely bad idea for anything handling sensitive data. It's vulnerable to XSS in ways httpOnly cookies simply aren't.

// Convenient but vulnerable to XSS token theft
localStorage.setItem("token", jwt);

// Safer approach
res.cookie("token", jwt, {
  httpOnly: true,
  secure: true,
  sameSite: "strict"
});

I get why localStorage is tempting, it's simpler to work with in a lot of frontend setups. It's just not worth the tradeoff once real user data is involved.

Headers You're Probably Missing

Security headers are cheap to add and genuinely useful. This is one of those checks that takes five minutes and prevents entire categories of attack.

app.use((req, res, next) => {
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("X-Frame-Options", "DENY");
  res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");
  next();
});

If you're on Next.js, this can go in next.config.js instead, which is cleaner and easier to maintain across the whole app. A clean, well-structured web design in Ludhiana teams often build from scratch tends to make this kind of config easier to audit too, versus a messy patchwork of inherited templates and plugins.

Dependency Audit Before Every Deploy

Run this before every production push, not just occasionally.

npm audit --production

Fix what's flagged as high or critical severity at minimum. It's tedious, sure, but outdated dependencies are consistently one of the top causes of breaches we've had to clean up after the fact. This kind of gap is exactly what a proper cybersecurity audit should catch if your own process misses it.

Working With Someone Outside Your Own Codebase

Even with a solid personal checklist, there's real value in bringing in outside review before anything customer-facing goes live. It's not about the code being bad, it's about blind spots that come from staring at the same codebase for weeks straight. A second review from a cyber security company in Ludhiana or wherever your team's based tends to catch the stuff you've genuinely stopped seeing.

Final Thought

None of this is exciting work. It's grep commands and header configs and double-checking things you're pretty sure you already did right. But localhost forgives sloppiness in ways production never does, and the gap between "works on my machine" and "safe in production" is exactly where these checks live.
Ship carefully. The bots are definitely watching your DNS propagate.

I Ran a 2026 Security Audit on a Fresh WordPress + WooCommerce Site: Here's Everything That Broke

Mittal Technologies — Mon, 06 Jul 2026 09:22:26 +0000

I spun up a brand new WordPress install last week, added WooCommerce, a handful of the most commonly recommended plugins, and did basically nothing custom. No weird theme hacks, no sketchy nulled plugins, just a standard setup like thousands of small businesses launch every single day. Then I ran a full 2026 security audit on this fresh WordPress and WooCommerce site, expecting maybe two or three minor flags.
I found eleven issues. On a site that was, by all appearances, doing everything "right."

Setting Up the Baseline

Stack was simple: WordPress core (latest version), WooCommerce, a popular free theme, and five plugins covering SEO, caching, contact forms, backups, and a security plugin because irony demanded it. Fresh install, no content beyond placeholder products, default settings left mostly untouched, basically the exact starting point a new client site looks like on day one.

wp core version
# 6.8.1

wp plugin list --status=active

I ran the audit using a mix of manual checks and automated scanning, then verified anything the scanner flagged by hand before trusting it.

Issue 1: Default Login URL, No Rate Limiting

The obvious one, but still worth stating plainly: /wp-login.php was wide open with zero rate limiting on failed attempts. I simulated repeated login attempts and got no lockout, no CAPTCHA trigger, nothing.

for i in {1..20}; do
  curl -s -X POST https://freshsite.test/wp-login.php \
    -d "log=admin&pwd=wrongpass$i" -o /dev/null -w "%{http_code}\n"
done

All twenty attempts returned 200. On a live site, that's an open invitation for credential stuffing.

Issue 2: WooCommerce REST API Exposing More Than It Should

This one surprised me more than it probably should have. The WooCommerce REST API, even without generated keys, leaked product and category data through publicly accessible endpoints that weren't properly scoped.

curl https://freshsite.test/wp-json/wc/store/v1/products

Returned full product listings including internal SKUs, which isn't catastrophic on its own, but it's the kind of data leak that becomes ubiquitous across default WooCommerce installs simply because almost nobody checks REST API scope during setup.

Issue 3: XML-RPC Still Enabled by Default

I genuinely thought this had mostly died out as a concern, but XML-RPC was active and responding, which still gets used for brute-force amplification attacks via system.multicall.

curl -X POST https://freshsite.test/xmlrpc.php \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Got a full method list back, no restrictions. Disabling this outright, unless something specifically depends on it, is basically free security.

Issue 4: File Permissions Looser Than They Should Be

Default install left wp-config.php at 644 permissions instead of the tighter 600 recommended for anything holding database credentials.

ls -la wp-config.php
# -rw-r--r-- 1 www-data www-data

Not a critical flaw by itself, but combined with any other vulnerability giving read access to the filesystem, this turns into a much bigger problem fast. Small fix, meaningful risk reduction.

Issue 5 Through 8: The Plugin Pile-Up

This is where things got genuinely uncomfortable. Two of the five plugins had unpatched vulnerabilities listed in public CVE databases from earlier in the year, both still showing as "up to date" according to the plugin's own version number, because the vulnerability was in a version range that technically wasn't the newest release yet, just recent.

wp plugin list --update=available

This is exactly the kind of gap a scheduled cybersecurity audit catches that a one-time setup check never will, since plugin vulnerabilities get disclosed on an ongoing basis, not in a single batch.

Issue 9: Checkout Page Missing Additional Transport Security

SSL was active, which is table stakes at this point, but the checkout page wasn't setting HSTS headers, meaning a user's first visit over HTTP before any redirect could theoretically be intercepted.

app.use((req, res, next) => {
  res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains");
  next();
});

WordPress doesn't handle this by default, it needs to be added at the server config level, which is easy to forget on a standard shared hosting setup.

Issue 10 and 11: Admin Account Sprawl and Weak Password Policy

The install had two admin accounts left over from the setup process, one of which was a leftover default account nobody had bothered removing. Password policy was also essentially nonexistent, accepting anything over six characters with no complexity requirement.

This is honestly the most common finding across every WordPress site I've personally audited, fresh or otherwise. Access control keeps losing to convenience, every single time, on every kind of project.

What This Means If You're Launching WooCommerce in 2026

None of these eleven issues were exotic. Nothing here required advanced exploitation skills, just patience and a checklist. That's honestly the scary part. A fresh, "default" WordPress and WooCommerce site, set up by someone following standard documentation, ships with real exposure baked in from day one.

If you're running an online store, this is exactly the kind of gap that gets caught by pairing development with a proper cyber security company in Ludhiana or equivalent, someone whose entire job is watching for exactly this stuff rather than treating it as a one-time launch checkbox. A website development company Ludhiana businesses actually trust for ongoing WooCommerce projects should be running audits like this as standard practice, not as an upsell.

I'll be re-running this same audit on the same install again in three months just to see how much drifts back open on its own. My guess is at least half of it.

How I Reduced API Response Times by 70% Without Changing My Database

Mittal Technologies — Thu, 02 Jul 2026 08:13:10 +0000

So, a few months back I got handed a legacy Node.js API that was averaging around 1.4 seconds per request on some of our heavier endpoints. Users were complaining, the frontend team was slapping loading spinners on everything to hide the pain, and the initial instinct from pretty much everyone, including me if I'm honest, was "we need to migrate the database." We didn't. Got the average down to around 420ms without touching the schema or swapping the database engine at all. Writing this up because I think a lot of teams jump to the expensive fix before ruling out the cheap ones.

Quick context: this was an order management API for a mid-sized e-commerce client, built maybe four years ago, handed off between a couple of different dev teams over that time, the usual story. Nobody fully owned it anymore. That's often exactly the kind of codebase where these problems hide in plain sight.

Step one, actually profile instead of guessing

Everyone has a theory about what's slow before they've looked at any numbers. I did too, honestly, my first guess was the database. So, I stopped guessing and started measuring. Threw some console.time blocks through the request lifecycle initially just to get a rough shape of where time was going, then moved to proper APM tracing once I had a hypothesis worth confirming.

console.time('db-query');
const result = await db.query(sql, params);
console.timeEnd('db-query');

console.time('serialization');
const payload = serializeResponse(result);
console.timeEnd('serialization');

Turns out the database query itself was taking maybe 80-120ms. Not amazing, but nowhere near the villain everyone assumed it was. The real time sink was everywhere else, N+1 queries hiding inside a "single" endpoint call, redundant serialization work, and basically zero caching on data that barely changes minute to minute.

Fix 1: killed the N+1 queries with proper eager loading

This was the biggest single win by a wide margin. The endpoint was fetching a list of orders, then looping through and firing off a separate query for each order's line items. Classic N+1, and with pagination set to 50 items per page, that's 51 sequential round trips to the database for what should've been one API call.

// before - N+1 disaster
const orders = await Order.findAll();
for (const order of orders) {
  order.items = await OrderItem.findAll({ where: { orderId: order.id } });
}

// after - single query with join
const orders = await Order.findAll({
  include: [{ model: OrderItem, as: 'items' }]
});

This one change alone cut response time nearly in half on the heaviest endpoint. I know N+1 queries are a well-worn topic in performance write-ups, almost a cliché at this point, but I keep finding them in production codebases anyway, so clearly the lesson hasn't fully landed industry-wide.

Fix 2: added a caching layer for data that doesn't need to be real-time

A decent chunk of the response payload was product metadata, stuff that updates maybe once a day if that. There was no good reason to hit the database for it on every single request.

const CACHE_TTL = 300; // 5 minutes

async function getProductMetadata(productId) {
  const cached = await redis.get(`product:${productId}`);
  if (cached) return JSON.parse(cached);

  const data = await Product.findByPk(productId);
  await redis.set(`product:${productId}`, JSON.stringify(data), 'EX', CACHE_TTL);
  return data;
}

Simple, almost boringly so, but it removed a huge amount of repeated, unnecessary work from the hot path.

Fix 3: trimmed the response payload to what the frontend actually uses

Turned out the API was returning full ORM objects with dozens of fields the frontend never touched, half of them internal flags nobody remembered adding. Serializing all of that, especially nested relations, was adding measurable overhead on every single request. Switched to explicit response DTOs instead of just dumping the model.

function toOrderResponse(order) {
  return {
    id: order.id,
    status: order.status,
    total: order.total,
    items: order.items.map(i => ({ name: i.name, qty: i.qty, price: i.price }))
  };
}

Smaller payloads, faster serialization, faster network transfer on top of that. All three add up more than people expect, especially on mobile connections.

Fix 4: connection pooling had been misconfigured the whole time

Found the pool size still sitting at the driver's default, way too low for our actual concurrent load. Requests were literally queuing for a free connection during traffic spikes, which doesn't show up clearly when you're profiling a single isolated request, only under real concurrent load.

const pool = new Pool({
  max: 25, // was defaulting to 10
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000
});

This is the kind of thing that's easy to overlook because it hides behind the symptoms rather than causing an obvious error.

What I'd tell anyone facing a similar problem

Profile before you assume anything. Everyone's first instinct is to blame the database, and sometimes it genuinely is the culprit, but more often it's the code sitting around the query that's the real problem, redundant calls, missing caching, bloated payloads, connection handling nobody's revisited in years. A full database migration is expensive, risky, and honestly avoidable more often than teams think, especially when nobody's bothered to profile first.

If you're maintaining an older system and running into similar complaints, it's worth getting a second, less attached set of eyes on it before committing to a rewrite. This kind of performance audit is something we do fairly often at Mittal Technologies, working alongside teams that just need someone to actually trace the problem rather than guess at it. If there's a genuine architectural issue underneath, that's usually where a proper software development company in Ludhiana earns its keep, digging into the parts nobody's had time to revisit.

A lot of legacy codebases end up desultory in their architecture, not through any single bad decision, but through years of different hands touching the same system with no shared plan. That's usually where these performance issues quietly accumulate.

If you're working on something similar and want a structured audit rather than a guess-and-check approach, teams doing custom software development in Ludhiana tend to have this exact profiling-first workflow baked into how they approach legacy handoffs, which honestly saves a lot of wasted migration effort down the line.

Curious if others have run into similar N+1 traps hiding inside seemingly simple endpoints, or connection pool defaults that nobody thought to touch. Feel free to drop your own war stories in the comments, I always enjoy hearing where these things hide in other people's codebases.