DEV Community: Sanket Jagtap

How Much Does a Website Cost in India? (2026 Pricing Guide)

Sanket Jagtap — Fri, 31 Jul 2026 14:48:50 +0000

"How much will my website cost?" is the first question every client asks — and most answers online are either vague or written by agencies with something to sell. Here are real numbers, based on what I actually charge and what I see across the Indian freelance market in 2026.

The short answer

Basic website (3–5 pages): ₹10,000 – ₹25,000
Professional business website (CMS, animations, admin panel): ₹25,000 – ₹60,000
Full-stack web application (auth, database, payments, dashboards): ₹50,000 – ₹2,00,000+
Hourly work (fixes, features, consulting): ₹500 – ₹1,500/hour

For reference, my own packages start at ₹15,000 for a basic website and ₹800/hour for ad-hoc work — you can see the full breakdown on my services page.

What actually drives the price

1. Number of unique page designs

A 3-page site where every page shares one layout is cheap. Ten pages with distinct designs is not. Most of the cost is design and content work, not code.

2. Custom functionality

The moment you need logins, payments, bookings, or an admin panel, you've crossed from "website" into "web application" — the engineering effort roughly triples. A contact form is trivial; a customer dashboard is not.

3. Content management

If you want to edit content yourself, you need a CMS or admin panel. That adds cost up front but saves you paying a developer for every text change later. For most businesses it pays for itself within a year.

4. Who you hire

Freelancer (direct): best value — you pay for the work, not office overhead. ₹15k–₹60k for most business sites.
Small agency: ₹60k–₹3L for the same scope. You're paying for project managers and margins.
Website builders (Wix/WordPress templates): ₹0–₹10k, but you'll fight the template, load slowly, and rank poorly. Fine for a hobby; risky for a business.

Costs people forget

Domain: ₹800–₹1,500/year
Hosting: ₹1,500–₹8,000/year for most sites (a small VPS runs several sites comfortably)
SSL: free with Let's Encrypt — never pay for basic SSL
Maintenance: budget a small monthly retainer if your site changes often

Red flags when comparing quotes

Quotes with no scope in writing ("website: ₹40,000") — you'll pay for every change later
No mention of mobile responsiveness or page speed — in 2026 both are table stakes
"SEO included" with no specifics — real SEO is structured data, performance, and content, not a checkbox
You don't get the source code or hosting access — you should own what you pay for

How I price projects

I quote a fixed price against a written scope: pages, features, timeline, and what's included (responsive design, SEO basics, deployment). Anything outside scope is discussed before it's built — no surprise invoices. If you're planning a website or web app and want a real number for your specific case, tell me what you're building — I reply within a day with an honest estimate, no obligation.

How to Hire a Freelance Full-Stack Developer in India (Without Getting Burned)

Sanket Jagtap — Fri, 31 Jul 2026 14:48:50 +0000

Hiring a freelance developer is a leap of trust: you're handing your idea, your money and your timeline to someone you found on the internet. I'm a freelance full-stack developer myself, so consider this the checklist I'd want my own clients to use — including the questions that would make a bad freelancer uncomfortable.

What "full-stack" should actually mean

A genuine full-stack developer can take your project from empty folder to live product: front-end (Angular/React), back-end APIs (Node.js and similar), database design, and deployment to a real server. If a candidate can only do one side, you'll end up hiring twice and paying for the coordination overhead yourself.

Fair rates in India (2026)

Junior (0–2 yrs): ₹300–₹600/hour — fine for simple sites with supervision
Mid-level (2–5 yrs): ₹600–₹1,200/hour — the sweet spot for most business projects
Senior (5+ yrs): ₹1,200–₹2,500/hour — worth it for complex systems and architecture

Suspiciously cheap quotes usually mean the work is subcontracted, rushed, or will quietly die at 80% complete. The most expensive project is the one you pay for twice.

The 7-point vetting checklist

Live products, not just screenshots. Ask for URLs you can click and apps you can install. A portfolio of images proves nothing about deployment skills.
Real employment or client history. Cross-check LinkedIn. Someone who has shipped inside companies (banks, product firms) has survived code reviews and deadlines.
Ask "what would you build this with, and why?" A good developer explains trade-offs in plain language. A bad one hides behind jargon.
Written scope before money. Pages, features, milestones, timeline, and what happens when scope changes. If they resist writing it down, walk away.
Milestone payments. 30–40% to start, the rest tied to demos you can actually click. Never 100% up front.
You own the code. Repository access under your account, hosting credentials in your name, and a handover clause. Non-negotiable.
Communication rhythm. Agree on update frequency (I send progress updates at least weekly). Silence is how projects die.

Where to find good freelancers

Referrals — still the highest hit rate
Portfolio sites + a real conversation — a developer who writes about their work (blog, GitHub, case studies) is showing you how they think before you pay them
Marketplaces (Upwork, Contra) — workable, but reviews measure politeness more than engineering quality; still run the checklist above

Red flags that predict failure

"Yes" to every requirement without a single clarifying question
No questions about why you're building it — features without purpose become rework
Won't do a short intro call
Can't explain their own past projects in detail (they may not have built them)

Ready to talk to one?

I'm Sanket — a full-stack developer with 4+ years of experience across enterprise finance portals, real-time trading platforms and mobile apps, based in Pune and working with clients everywhere. My projects, pricing and contact form are all public — run this very checklist on me. That's exactly the kind of scrutiny a good freelancer should welcome.

Deploying a Full-Stack App with Docker and Nginx on a VPS

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

You do not need Kubernetes to ship a real app. A single VPS with Nginx and Docker handles a surprising amount of traffic. Here is the setup that runs this portfolio.

The topology

Nginx is the front door, terminating SSL and serving the built Angular app as static files.
The Node + Prisma API runs in a Docker container on a private port (6000).
MySQL is the database; uploaded images live on a persistent host volume.

Nginx as the front door

One server block does three jobs: serve the SPA with a history-API fallback, reverse-proxy the API, and serve uploaded files. The detail that bites everyone is the trailing slash on proxy_pass :

location /api/ {
  proxy_pass http://localhost:6000; # no trailing slash -> keeps /api prefix
}
location / {
  try_files $uri $uri/ /index.html; # SPA fallback
}

With a trailing slash Nginx strips the matched prefix, so /api/users would arrive at the backend as /users and 404. Dropping the slash preserves the path.

Persistent uploads

Anything written inside a container is gone on the next deploy. Uploads must live on the host and be mounted in, with ownership that matches the container user:

docker run -d --restart unless-stopped \
  -p 6000:6000 --env-file .env \
  -v /opt/app/uploads:/opt/app/uploads \
  portfolio

SSL

Let's Encrypt via certbot gives free, auto-renewing certificates. Nginx redirects all HTTP to HTTPS, so the app is TLS-only.

Deploys

The flow is pleasantly boring: pull the latest code, docker build , stop the old container, run the new one. Because migrations run on startup and uploads live outside the container, a redeploy is safe and repeatable.

Gotchas worth remembering

proxy_pass trailing slash changes the forwarded path — choose deliberately.
A non-root container user cannot write to a root-owned host volume; fix the ownership.
An existing database needs its migrations baselined once (P3005) before migrate deploy will run.

Building BeatNest: A Cross-Platform Music App in Flutter

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

BeatNest is a cross-platform music streaming app built with Flutter. It streams tracks from the Saavn API and focuses on the things that actually make a music player feel good: gapless background playback , media-style notifications, lock-screen controls and offline listening.

Why Flutter

One codebase, two stores. Flutter let me ship a consistent UI on Android and iOS while still dropping down to native APIs where it mattered — the media session, notifications and storage permissions.

Architecture

The app follows a clean, service-oriented structure so the UI stays dumb and the logic stays testable:

ApiService — talks to the Saavn API for search and trending songs.
MusicService — the playback brain: queue, current track, play/pause/seek, exposed as reactive streams with rxdart.
AudioHandler — the background audio service that survives the app being backgrounded.

Background playback

This is where most music apps fall apart. BeatNest combines just_audio for the player with audio_service for the OS-level media session. That gives you a notification with controls, lock-screen artwork, and playback that keeps going when the app is swiped away.

dependencies:
  just_audio: ^0.10.5
  audio_service: ^0.18.12
  audio_session: ^0.2.3
  rxdart: ^0.28.0

Auth and cloud sync

Users can continue as a guest or sign in with email or Google via Firebase Auth. Signing in syncs their liked songs and playlists across devices through Cloud Firestore, so the library follows the user, not the phone.

Offline and resilience

Downloads use dio with a local SQLite index so songs are available without a connection, and connectivity_plus gracefully degrades the UI when the network drops. Crashes and usage are tracked with Firebase Crashlytics and Analytics.

Lessons learned

Treat the audio session as the source of truth — the UI should reflect it, never drive it directly.
Background execution rules differ a lot between Android and iOS; test on real devices early.
A "Continue as guest" path removes friction and still lets you upsell sync later.

BeatNest started as an experiment in "can Flutter really do a proper media app?" The answer turned out to be a confident yes.

Making a Node.js and Prisma API Production-Ready

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

"It works on my machine" and "it is production-ready" are very different statements. Here is the checklist I worked through to take an Express + Prisma + MySQL API from the first to the second — using this very portfolio backend as the guinea pig.

1. Real migrations, not db push

prisma db push is great for prototyping and dangerous in production — there is no history and no safe rollback. The fix is committed migrations applied on deploy:

npx prisma migrate dev --name init # generate + commit
npx prisma migrate deploy # run on startup (never prompts)

If the database already has tables but no migration history you will hit P3005. Baseline it once by marking the migration as already applied, then deploys are clean forever after.

2. Graceful shutdown

Containers get SIGTERM on every redeploy. Without handling it you drop in-flight requests and leak database connections. Close the server, then disconnect Prisma:

process.on('SIGTERM', async () => {
  server.close(async () => {
    await prisma.$disconnect();
    process.exit(0);
  });
});

3. Map errors to real status codes

A blanket 500 tells the client nothing. A small helper maps known Prisma errors — unique violation to 409 , record-not-found to 404 — and keeps the raw error server-side only.

4. Liveness vs readiness

Two different questions. /health answers "is the process up?" cheaply. /health/ready answers "can I serve traffic?" by actually pinging the database with SELECT 1 — that is what your load balancer should probe.

5. Config and secrets

Fail fast at startup if a required secret like JWT_SECRET is missing.
Never ship a hardcoded admin password — seed a random one and print it once.
Keep .env out of git; commit a .env.example template instead.

6. A lean Docker image

A multi-stage build compiles TypeScript in a builder stage and ships only the runtime deps and compiled output, running as a non-root user. Migrations run as the first thing the container does on boot.

None of this is exciting, and that is the point. Production-ready means boring, predictable and observable.

Inside AlgoETF: An Algorithmic ETF Trading Platform

Sanket Jagtap — Mon, 22 Jun 2026 16:57:25 +0000

AlgoETF is an algorithmic trading platform for Indian ETFs. It runs rule-based strategies against live market data, places orders through connected brokers, and lets you research everything with a built-in backtester before risking real money.

The core strategy

At its heart is a simple, explainable idea: buy the dip, sell the rise , gated by momentum. The engine watches each ETF and acts when price moves a configured percentage, but only when the RSI(14) filter agrees — so it avoids buying into a falling knife or selling into strength.

Buy on dip and sell on rise thresholds, per ETF.
RSI oversold / overbought gate to filter bad entries.
Cycle targets so each position has a defined exit.

Real-time architecture

The frontend is Angular; the backend is Node.js + Express. Live prices and order updates stream over WebSockets , Redis handles pub/sub and hot state, and MySQL is the system of record for strategies, cycles and orders. Broker APIs sit behind an adapter layer so new brokers can be added without touching the strategy code.

The backtester

You can replay historical 1-minute data through the exact same strategy logic — research only, no orders placed. The best part is the A/B improvement rules : toggle a stop-loss, cap averaging, an EMA trend filter, a volume filter or a trailing exit, and compare the result against the base strategy.

Parameters: stock, date range, buy dip %, sell rise %
Gate: RSI period, oversold <, overbought >
Risk: qty/order, start capital, brokerage %, slippage %
A/B rules: stop loss, cap averaging, EMA filter, trailing exit

Safety first

Trading code is unforgiving, so the platform separates live , paper and backtest modes explicitly. Paper trading mirrors live behaviour with no money at stake, and every order is logged with a clear success / pending / failed status.

Lessons learned

Make strategies boring and explainable — you have to trust them with money.
Backtesting and live execution must share the same code path, or your results lie.
An audit trail of every order is not optional in fintech.

Angular Beyond the Docs: What 4+ Years of Production Code Taught Me

Sanket Jagtap — Wed, 17 Jun 2026 16:54:24 +0000

Angular Beyond the Docs: What 4+ Years of Production Code Taught Me

Most Angular blogs explain what a feature does.

Very few talk about when it hurts, when it helps, and when not to use it.

After more than 4 years of building Angular applications in production , I’ve learned that the hardest problems were never about syntax or APIs — they were about decisions.

This post is for developers who already know Angular and want to think more clearly while building real systems.

The Real Problem Was Never Angular — It Was Over-Abstraction

Early in my career, I believed:

More architecture means better code.

So I built:

1. Deep folder hierarchies
2. Over-generic services
“Shared” modules that depended on everything
Reusable components that were rarely reused

The result wasn’t scalability — it was:

Slower development
Harder onboarding
Fear of touching existing code

Modern Angular didn’t just introduce new features — it removed the need for unnecessary structure.

Lesson:

Simplicity scales better than cleverness.

Signals Didn’t Replace RxJS — They Replaced Misuse of RxJS

Signals are often described as “Angular without RxJS.”

That’s not accurate.

RxJS was never the real problem.

Using RxJS for synchronous UI state was.

What went wrong in real projects:

Observables for button state
Subscriptions inside components
Boilerplate like takeUntil(destroy$) everywhere
UI bugs caused by async timing

What signals fixed:

UI state became synchronous again
No subscriptions
No memory-leak anxiety
Predictable rendering

Lesson:

Signals didn’t replace RxJS — they rescued it from being overused.

Today my rule is simple:

Signals → UI and local state
RxJS → async streams (HTTP, WebSockets)

Change Detection Wasn’t Slow — Our Mental Model Was

For years, Angular performance advice felt like magic spells:

Use OnPush
Add trackBy
Avoid functions in templates

We followed rules without understanding why.

Signals changed this by making change detection explicit :

Angular updates only what reads a signal
Not the whole component tree
Not “everything just in case”

Lesson:

Performance improves when the framework matches how developers think.

Standalone Components Solved a Human Problem

NgModules worked — but they created cognitive overhead :

Where is this provided?
Why is this imported here?
Which module owns this component?

Standalone components didn’t just reduce code.

They reduced questions.

Developers can now open a file and understand it without tracing imports across multiple modules.

Lesson:

The best abstractions are the ones you don’t have to explain.

State Management Is a Cost — Not a Feature

NgRx is powerful.

It’s also expensive.

In production, I’ve seen:

Simple apps buried under actions and reducers
Teams afraid to touch state logic
Bugs hidden behind boilerplate

Signals enabled something important:

Local state that stays local.

My approach today:

Start with signals
Introduce heavier state management only when complexity demands it

Lesson:

State management should grow with the problem — not ahead of it.

The Biggest Angular Upgrade Is Restraint

Modern Angular gives us:

Signals
Standalone APIs
Deferrable views
Better performance tools

But the real upgrade isn’t knowing more APIs.

It’s knowing when not to use them.

I now ask:

Does this abstraction reduce thinking?
Will this still make sense in two years?
Can someone else debug this easily?

Lesson:

Senior Angular development is about clarity, not cleverness.

Final Thoughts

Angular today is:

Faster
Simpler
More predictable

But frameworks don’t make applications maintainable — decisions do.

The best code is the one that survives change — not the one that impresses today.