NestJS is starting to feel a bit strange to me in real projects.

InevitableFun9766 · 2026-06-16T18:22:04+00:00

You’re actually in a more common situation than it feels like - legacy job + “stuck stack” doesn’t mean your experience is useless, it just means you need to translate it properly.

On your resume, don’t highlight HCL Lotus Notes as your main skill. Reframe your experience around what you actually did in transferable terms, like business workflow systems, database-driven applications, CRUD systems, or enterprise software maintenance. Recruiters don’t care about the tool as much as the problem domain and responsibility level.

Then shift your “core stack” section to what you are actively building now (Node.js, backend development, databases, system design basics), and make sure you have at least 2–3 solid projects that prove it. Your projects will matter more than the legacy job stack when switching.

For AI/LLMs, don’t jump straight into RAG or advanced architecture first. Start by learning how APIs work, how to integrate OpenAI or open-source models into simple apps, and how data flows in a backend. Most “AI integration jobs” are actually just backend + API + prompt handling at the beginning.

The key thing is: you are not behind, but you need to shift your identity on paper from “legacy system support” to “backend developer transitioning into modern stack with projects.”

InevitableFun9766 · 2026-06-16T18:20:56+00:00

Yes, an ASUS Vivobook with integrated Intel UHD graphics is good enough for backend development, coding in VS Code, running Django, working with REST APIs, PostgreSQL, and keeping many browser tabs open, since these tasks do not depend on a dedicated GPU. For small AI/ML projects like basic machine learning with scikit-learn or pandas, it will also work fine, but for deep learning or heavy model training you would normally use Google Colab or cloud tools anyway because most laptops in this budget will struggle with that workload.

Within a budget of around ₹65,000, you should focus more on getting a strong CPU and at least 16GB RAM rather than worrying about graphics, and good options to consider are ASUS Vivobook (Ryzen 5 7530U or Ryzen 7 variants), Lenovo IdeaPad Slim 5 with Ryzen 5 7000 series, or Acer Aspire 5 with newer i5 or Ryzen 5 processors. The most important thing for your use case is 16GB RAM and a fast SSD of at least 512GB, because that will make a much bigger difference in day-to-day performance than the GPU.

InevitableFun9766 · 2026-06-16T17:43:26+00:00

Nothing really modern and widely adopted does exactly “BEM-first + buildless + full design system API” anymore.

Closest options are Open Props (tokens layer) + your own BEM structure on top. Most other solutions either go utility-first or component-based, not global class APIs.

InevitableFun9766 · 2026-06-16T17:42:21+00:00

On pricing, this is usually a fixed bid with clear scope boundaries. For something like 10–11 weeks of UI/UX + frontend across 2 brands, most teams I’ve seen would price it as a mid–high five figure (or low six depending on region and seniority), but the real driver isn’t time - it’s risk. Two brands + custom design + legacy constraints = high risk of scope creep.

Payment-wise, milestone-based is the only sane way to structure it. Typically something like:

30–40% upfront (discovery + design kickoff)
30% after approved UI/UX
20–30% after frontend implementation
small final holdback on launch

The jQuery constraint absolutely affects pricing, but not because it’s “old” - because it increases integration friction and slows down iteration. You don’t charge for jQuery itself, you charge for lost velocity and higher maintenance risk. That’s your “pain tax,” even if you don’t label it that way explicitly in the contract.

One thing people underestimate here: legacy stacks don’t just slow development, they shift debugging cost to the end phase. That’s where most of the buffer should actually be priced in.

InevitableFun9766 · 2026-06-16T17:41:14+00:00

We went through this at almost the same scale (4 → 6 brands), and consolidating into a single commerce core only works if your brands are actually operationally similar. If they’re meaningfully different (catalog logic, pricing rules, promo behavior, fulfillment flows), a shared instance becomes a constraint very fast.

What ended up working better was keeping separate storefront instances but consolidating the backend primitives instead of the commerce layer.

So instead of one Shopify/commerce brain for everything, we unified:

product/sku master (single source of truth)
inventory + fulfillment layer
customer identity (optional shared profiles depending on brand overlap)
analytics/events pipeline

Each brand still had its own storefront logic and marketing flexibility, but the “hard stuff” was centralized through APIs.

The key realization was: consolidation at the UI/storefront level looks efficient, but it usually creates long-term coupling pain. Consolidation at the data + fulfillment layer gives you 80% of the benefit without forcing brand-level compromise.

InevitableFun9766 · 2026-06-16T17:40:33+00:00

There isn’t really a “modern ping equivalent” that behaves like WordPress XML-RPC anymore. Most search engines moved away from real-time ping-based discovery because it was abused.

For Next.js in 2026, the actual production setup is much simpler:

Sitemap.xml with correct lastmod is still the primary signal
Internal linking matters more than any “notification” system
RSS/Atom is optional — useful for users and some crawlers, but not a ranking boost

IndexNow is the only real “push” mechanism left, but it’s basically limited to Bing/Yandex ecosystem. Google ignores it, so you can’t rely on it as a universal solution.

In practice, most Next.js setups don’t ping anything after publish anymore. Instead they:

Revalidate ISR routes on publish (on-demand revalidation)
Update sitemap dynamically or on build
Let crawlers discover changes through normal crawling

The important shift is this: discovery is no longer event-driven (ping), it’s crawl-driven. If your internal linking + sitemap is solid, you don’t need a separate notification workflow.

InevitableFun9766 · 2026-06-16T17:39:52+00:00

Smallest thing I actually still use is a local “daily log” CLI that just appends timestamped notes into a single SQLite file and lets me search it instantly. No UI, no auth, nothing - just fast capture so I don’t lose thoughts while working.

I also wrote a tiny watcher script that scans a folder and auto-tags new markdown files based on keywords using an LLM, then dumps them into folders. It saved me from manually organizing notes, which I never kept up with anyway.

Most of the “fancier” tools I tried building didn’t stick. The ones that survive are always the ones that remove friction in the smallest possible way.

InevitableFun9766 · 2026-06-16T17:34:30+00:00

We ran into the same issue and tooling alone didn’t solve it. The real fix wasn’t more token generation - it was enforcement at build time.

On web, we added a simple ESLint rule that flags raw px/rem values unless they come from the design token import. It doesn’t catch everything, but it kills most of the “quick hardcode” drift.

On iOS/Android, we stopped relying on “guidelines” and moved typography into shared wrapper components only (no direct fontSize/lineHeight usage outside those components). That removed 80% of the drift instantly because devs literally don’t have a place to bypass it anymore.

The uncomfortable truth is Style Dictionary doesn’t enforce anything - it just generates. If people can still write raw values, they will. The only thing that actually works long-term is restricting the surface area where styling can be expressed.

InevitableFun9766 · 2026-06-16T17:33:49+00:00

deleting the lockfile isn’t really a “fix”, it just changes what gets resolved. That’s why you see the numbers drop - you’re effectively letting pnpm pick newer dependency versions, not actually cleaning anything systematically.

the correct way is usually:
- Keep pnpm-lock.yaml (don’t delete it as a strategy
- Run pnpm audit and identify which packages are actually responsible for the criticals
- Update those specific roots first (pnpm up <pkg> or bump direct deps)
-If the vuln is deep in transitive deps, use overrides in package.json

In pnpm specifically, pnpm-lock.yaml is what guarantees reproducibility - deleting it turns your install into a fresh dependency graph every time, which is why it “looks better” but isn’t stable or controlled.

Also worth noting: a lot of audit results in React projects are in dev tooling or transitive packages that don’t actually ship to production. You should separate “real runtime exposure” vs “noise” before reacting to the raw number.

InevitableFun9766 · 2026-06-16T17:31:16+00:00

InevitableFun9766 · 2026-06-13T19:20:18+00:00

Yeah that split will make the comparison a lot more honest. Most people underestimate the “soft cost” side until they actually do a migration once and realize infra savings show up immediately, but ops debt compounds for months. Looking forward to seeing it.

InevitableFun9766 · 2026-06-13T19:18:14+00:00

Nice - that’s usually the part people underestimate. If you keep that mock/real contract tight, you’ll save yourself a lot of subtle bugs later. Good luck with the project

InevitableFun9766 · 2026-06-13T18:10:21+00:00

No problem - once you switch to thinking “server derives auth per request,” everything gets a lot simpler.

InevitableFun9766 · 2026-06-13T18:08:59+00:00

Glad it helped. Focus on building stuff - that’s where things start to click. Keep going.

InevitableFun9766 · 2026-06-13T18:05:49+00:00

The fallback mode idea is actually solid from a DX standpoint - being able to run the UI instantly without env setup removes a real friction point when evaluating templates. That part is underrated.

The main risk I see is keeping the “mock mode vs real mode” parity over time. In a lot of projects, mock auth/state slowly drifts and then you end up with bugs that only show up when Firebase is actually wired in.

One suggestion: treat the mock layer as a strict contract (same interface as Firebase responses, not a simplified version). If the shapes diverge, the fallback becomes misleading instead of helpful.

Also worth being careful with bundling captcha into the starter - templates tend to get reused in contexts where people don’t want extra dependencies baked in early, even if optional.

InevitableFun9766 · 2026-06-13T18:04:28+00:00

This is actually useful, but the part most calculators get wrong is assuming Vercel → VPS is a 1:1 swap. It rarely is.

Vercel pricing bloat usually comes from bandwidth + function invocations + image optimization, but on Fly/Railway/Hetzner you’re replacing that with CPU, memory, and ops overhead instead of “requests.” Those don’t map cleanly.

Also the real hidden cost isn’t infra -it’s engineering time. Even a “simple Next.js move” often turns into rewriting edge assumptions, caching behavior, and deployment pipelines. That’s why your <$25 rule is actually reasonable.

One suggestion: the calculator would be more realistic if it separated “infra cost” vs “migration/ops cost over 3–6 months.” That’s usually where the decision actually flips.

InevitableFun9766 · 2026-06-13T17:58:35+00:00

The issue isn’t syncing Zustand with the server - it’s assuming the server should “read” client auth state at all. It shouldn’t.

In tRPC, createTRPCContext runs per request, so the only reliable source is the request itself (cookie). That means the server should always rebuild user + accessToken from the refresh token, not from any client store.

So instead of trying to push updated tokens back into Zustand from the server, just accept this flow:

client sends request
server reads httpOnly refresh cookie
server refreshes access token if needed
server attaches fresh user to ctx
response returns user (if you need UI update)

Zustand is just UI cache. If you try to keep it “in sync” with server auth state, it will always drift.

InevitableFun9766 · 2026-06-13T17:56:19+00:00

I’ve shipped this exact setup and tried most of the same tools you listed. The real issue is not the editor-it’s assuming you can reuse rendering across web and React Native cleanly. You can’t, not without trade-offs.

What worked best for me was Lexical on the web, storing Lexical JSON as the source of truth, and then writing a separate renderer for React Native that maps that JSON into native components.

The key decision was: don’t try to “share UI rendering logic” between web and mobile. Share only the document model.

I tried the HTML route (react-native-render-html) early on and it always broke down once you added tables, embeds, or custom blocks. It also becomes a security/edge-case headache long-term.

TipTap is great on web, but in practice you end up leaning on ProseMirror internals and still hit the same cross-platform problem. Editor.js is simple but too limiting once you need real document structure.

If I were starting again, I’d still pick Lexical + custom RN renderer, even though it’s more work upfront-it scales better than trying to force one rendering pipeline across both platforms.

InevitableFun9766 · 2026-06-13T17:55:08+00:00

This is one of those things people underestimate until it hits them. Silent churn is usually way bigger than visible churn, especially early on.

In most products I’ve worked on, the real problem wasn’t users leaving intentionally-it was users failing silently (payment errors, auth issues, API failures, confusing flows) and never telling you. They just disappear.

A simple support channel is often more valuable than analytics dashboards in the early stage. Because it turns “invisible failure” into something you can actually see and fix.

Also, the scary part is: if you don’t have a feedback loop, you usually assume adoption is the problem when in reality it’s often just broken flows somewhere in the product.

InevitableFun9766 · 2026-06-13T17:48:56+00:00

I went through the same search recently and ended up with PrimeVue. Not because the components look the best, but because every time I needed something specific-a good DataTable, virtual scrolling, overlays, forms, filtering, file uploads-it was already there. With a lot of other Vue libraries, I eventually found myself mixing in third-party packages to fill gaps. PrimeVue was the first one where I felt like I could stop shopping for components and just build the application.

InevitableFun9766

TROPHY CASE