Skip to content
RAHUL/
Full-Stack Engineer

Full Stack Engineer

I build complete products — interface to infrastructure — and the systems that keep them fast, secure and coherent as they scale.

MERNNext.jsAIProduct engineering
View selected workStart a conversationRésumé
Scroll to travel the stack
01 · Location
Entry
The way in

Every product starts as an empty space and a decision about what belongs in it.

02 · Location
Frontend
React · Next.js · TypeScript

Interface surfaces that stay calm under real data — composed, responsive, and consistent across every viewport.

03 · Location
Backend
Node · APIs · Services

Requests become contracts. Services stay small, boundaries stay honest, and traffic keeps moving.

04 · Location
Data
Postgres · Mongo · Modelling

Storage shaped around the questions the product will actually ask of it.

05 · Location
AI
Retrieval · Agents · Inference

Prompt, retrieval, reasoning, response — a pipeline like any other, with latency and failure modes to design for.

06 · Location
Cloud
CI/CD · Edge · Observability

Infrastructure that makes shipping boring — distributed, observable, and reversible.

  1. 01
    Entry
    The way in

    Every product starts as an empty space and a decision about what belongs in it.

  2. 02
    Frontend
    React · Next.js · TypeScript

    Interface surfaces that stay calm under real data — composed, responsive, and consistent across every viewport.

  3. 03
    Backend
    Node · APIs · Services

    Requests become contracts. Services stay small, boundaries stay honest, and traffic keeps moving.

  4. 04
    Data
    Postgres · Mongo · Modelling

    Storage shaped around the questions the product will actually ask of it.

  5. 05
    AI
    Retrieval · Agents · Inference

    Prompt, retrieval, reasoning, response — a pipeline like any other, with latency and failure modes to design for.

  6. 06
    Cloud
    CI/CD · Edge · Observability

    Infrastructure that makes shipping boring — distributed, observable, and reversible.

  7. 07
    Projects
    Five builds, end to end

    The work itself — analytics platforms, generative AI, fintech and marketing surfaces.

  8. 08
    Experience
    Two roles, deeper each time

    From agency cadence to owning a multi-application platform.

  9. 09
    Contact
    The way out

    Open to full-time roles and selective freelance work.

AboutHow do I think?

Frontend depth, full-stack range

I started in the browser and worked outward — into APIs, data models and the architecture that keeps a product coherent as it grows.

I design, build and ship production systems end to end — interface engineering, APIs, data models and the architecture that holds them together. Recently that has meant micro-frontend platforms, AI-assisted product surfaces and performance work that moves real numbers.

I care about code that lasts: clear boundaries, honest naming and interfaces that stay calm under real data. Good engineering, to me, is as much about what you decide not to build.

See the full capability map
3+
Years shipping production software
20+
Products delivered end to end
7
Industries — finance to generative AI
  1. 01

    Architecture

    Micro-frontends, shared component libraries and boundaries that let teams ship independently without drift.

  2. 02

    Performance

    Rendering strategy, asset discipline and measurement — recent work took a Lighthouse score to 98.

  3. 03

    Product thinking

    Deciding what to build and what to leave out, so the interface earns its complexity.

CapabilityWhat can I build?

Full-stack engineer, end to end

Not a badge wall — a map of where I actually operate across the stack, with honest depth markers. Pick a domain to move the system into it.

  • Frontend
  • Backend
  • Database
  • AI
  • Architecture
  • Performance
  • Cloud
  • Security

8 domains · 63 technologies · 3 proficiency tiers

Frontend Engineering: 17 technologies

01 · Domain

Frontend Engineering

Component architectures and motion systems that stay fast and coherent as a product scales — including a shared library spanning three micro-frontends.

  • Core
  • Working knowledge
  • Exploring
Core
React.js — CoreNext.js — CoreTypeScript — CoreJavaScript — CoreTailwindCSS — CoreRedux — CoreZustand — CoreContext API — CoreGSAP — CoreFramer Motion — CoreHTML5 — CoreCSS3 — CoreResponsive Design — Core
Working knowledge
Zod — Working knowledgeThree.js — Working knowledge
Exploring
TanStack Form — ExploringTanStack Table — Exploring
Core
Day-to-day, shipped to production repeatedly.
Working knowledge
Used in real projects; comfortable, still deepening.
Exploring
Active study and prototypes — not production ownership yet.
03Next chapter

What have I built?

Five builds — analytics, generative AI, fintech, marketing. Each one taken from interface through to backend.

Selected Work

Five builds, told properly

Every one of them has a full case study — the problem, the architecture, the engineering that was actually hard, and what shipped.

Also shipped
ExperienceWhere have I applied it?

Two roles, deeper each time

From shipping client sites on an agency cadence to owning a multi-application platform — each step further into systems, not screens. Scroll to follow it.

01 / 02Oct 2025 — PresentNoida, India

Frontend Developer · Jasper Colin

B2B market research, data insights and analytics — a multi-application CRM platform plus an AI-powered lead-generation product.

Engineering challenges

  • Three CRM applications — Admin, Client and Supplier — had to ship and deploy independently without fragmenting the interface or duplicating UI code across teams.
  • The AI lead-generation product needed UI workflows wired directly into backend intelligence services while staying responsive.
  • A marketing site that marketing could turn into campaign-ready pages without waiting on engineering.

Systems built

  • A micro-frontend CRM platform composed of independently deployable Admin, Client and Supplier applications.
  • A shared, reusable UI component library consumed by all three micro-frontends as the single source of interface truth.
  • The front end for an AI-powered lead-generation product, connecting UI workflows to backend intelligence services.
  • The public marketing site, structured for fast, campaign-ready page delivery.

Impact

  • Shared component library removed duplicated UI code across the three apps and cut new-feature build time by an estimated 40%.
  • Marketing site ships at a Lighthouse performance score of 98.
ReactNext.jsTailwindCSSMicro-frontends
02 / 02Jan 2023 — Sep 2025Goa — Remote

Frontend Web Developer · Melange Digital

A digital studio shipping client web products across industries on an agency delivery cadence.

Engineering challenges

  • Client sites had to stay fast and visually consistent across browsers while being built and iterated on tight agency timelines.
  • Marketing teams needed to edit live copy and data without a deploy — a spreadsheet standing in for a lightweight CMS.
  • Motion and interaction had to feel considered, not bolted on, across a wide range of brands.

Systems built

  • Scalable client websites delivered end to end, from build through cross-browser testing to launch.
  • Reusable UI systems and shared front-end standards carried from project to project.
  • A content pipeline backed by the Google Sheets API so non-technical teams could update live content directly.
  • Scroll and interaction layers built with GSAP and Framer Motion.

Impact

  • Delivered 15+ client projects end to end across a range of industries.
  • Shared components and review practice raised code consistency and maintainability across the team.
  • Cross-browser testing and an Agile workflow kept releases predictable on an agency schedule.
ReactNext.jsTailwindCSSGSAPFramer MotionGoogle Sheets APIGit / GitHub
Download full résumé
ApproachHow do I keep it safe?

How I keep production systems safe

Security handled as a build-time constraint, not an afterthought — from token handling and RBAC to CSP, headers and dependency hygiene.

Approach

In client projects and enterprise portals I build state-driven authorization: session state managed reactively in the frontend store to show or hide UI, with every API request routed through interceptors that enforce cryptographic verification on the backend. Rich client interactivity, strict server-side policy.

In practice
  • Silent token refresh that runs asynchronously before JWTs expire.
  • Hide structural components and actions reactively to guide users at the UI layer.
  • Enforce identical authorization mappings in the API layer — never trust client logic.

Approach

Route-level protection via Next.js edge middleware that checks claims and token metadata before page chunks load. Unauthorized users are redirected at the edge, before any sensitive JavaScript is downloaded or hydrated.

In practice
  • Intercept restricted endpoints at the edge to protect code-split assets.
  • Group routes under access tiers (e.g. /admin/*).
  • Re-check tokens during layout render before components mount.

Approach

To mitigate session hijacking and XSS token harvesting, access tokens live only in application memory (store / React state) and refresh tokens sit in Secure, SameSite=Strict, HttpOnly cookies — unreadable by client scripts.

In practice
  • Short expiry (5–15 min) on in-memory access tokens.
  • HttpOnly on auth cookies to shield them from document.cookie.
  • Prompt server-side revocation to invalidate compromised credentials.

Approach

Never trust user input. Validation schemas with Zod for form processing; DOMPurify before rendering or storing anything user-provided, neutralising injection risk at the point of capture.

In practice
  • Map Zod validation to form controls for real-time feedback.
  • Sanitize input at point of capture with DOMPurify.
  • Reject values outside logical bounds.

Approach

Lean on React's default string escaping. Where raw rich text is unavoidable, pass it through a strict DOMPurify config that strips scripts, event handlers and javascript: protocols.

In practice
  • Avoid dangerouslySetInnerHTML unless wrapped in a sanitised helper.
  • Verify hyperlinks resolve to http/https schemes.
  • Ship a strict Content Security Policy to block inline execution.

Approach

APIs rely on custom headers (Bearer authorization) that browsers do not auto-send cross-site. For cookie-based setups, SameSite=Strict is enforced.

In practice
  • Bearer headers instead of session cookies for cross-origin calls.
  • Confirm SameSite policies on every server-issued session token.
  • Validate CORS pre-flight origin for state-changing methods.

Approach

Restrictive CSP delivered via HTTP headers: execution limited to first-party and trusted CDNs, single-use nonces for inline scripts, no unsafe-inline or unsafe-eval.

In practice
  • default-src 'self' to lock down connections by default.
  • Server-generated nonces for trusted inline scripts.
  • report-only directives during staging to catch violations early.

Approach

All traffic over HTTPS (TLS 1.3). CORS scoped to explicit frontend origins — never a wildcard for authenticated endpoints.

In practice
  • Enforce TLS 1.3 for encryption in transit.
  • Whitelist client domains explicitly in CORS.
  • Request timeouts on HTTP clients to manage bottlenecks gracefully.

Approach

Credentials, password inputs and PII stay out of global stores and persisted files. Passwords live in transient variables cleared once the request completes; console leaks are stripped at build time.

In practice
  • Clear passwords from memory immediately after the auth request.
  • Never write credentials or profiles to local logs.
  • Strip console output at compile time (Terser).

Approach

Strict separation of secrets and config. Server keys never reach the client bundle — only NEXT_PUBLIC_ public parameters are compiled in.

In practice
  • Database URLs, payment secrets and JWT keys stay server-side.
  • All .env files listed in .gitignore.
  • Validate required keys at build time to catch misconfiguration.

Approach

Third-party supply-chain risk managed by scanning. npm audit plus Snyk in CI to flag and block insecure upgrades before they reach production.

In practice
  • Lockfile installs (npm ci) for reproducible pipelines.
  • Automated vulnerability audits in pre-commit hooks.
  • Check project health and support status before adopting a package.

Approach

Hardened HTTP headers at the host (X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, HSTS) on every route.

In practice
  • nosniff to mitigate MIME-type sniffing.
  • Strict-Transport-Security to force HTTPS.
  • strict-origin referrer policy to limit referrer leakage.

Approach

Uploads checked for size, MIME category and magic bytes on the client, then routed to isolated storage buckets where files are renamed to random hashes to prevent execution.

In practice
  • Validate size and real binary header (magic bytes).
  • Restrict selectable file types on the input.
  • Never store user uploads in the application root.

Approach

Block embedding with X-Frame-Options: DENY and CSP frame-ancestors, so other origins cannot render the app in a hidden frame.

In practice
  • X-Frame-Options: DENY against third-party framing.
  • CSP frame-ancestors 'none' as a second barrier.
  • Frame-busting in base layouts for older browsers.

Approach

A strict storage classification: sensitive data (JWTs, refresh keys, PII) in HttpOnly cookies; non-sensitive preferences (locale, theme) in local or session storage.

In practice
  • Keep access credentials out of localStorage.
  • Clear sessionStorage on sign-out.
  • Encrypt any local data that must persist.

Approach

Error boundaries keep stack traces and database errors out of the browser. Users see generic messages; full traces go to a secure service like Sentry.

In practice
  • Return generic messages instead of raw API errors.
  • Keep stack details, SQL and traces on secure servers.
  • Global React error boundaries to prevent client crashes.

Approach

Security as a build-time constraint: eslint-plugin-security in the lint step, threat review before release, interfaces designed against the OWASP Top 10.

In practice
  • ESLint security presets to catch unsafe patterns in development.
  • Monthly audit of third-party package security.
  • Security checklists baked into release templates.
06Next chapter

What can we build next?

Open to full-time roles and selective freelance work.

Contact

Let's build something considered

The fastest way to reach me is email — the form below goes to the same place.

Emailrahuldev.kb@gmail.comPhone+91 8077464884
LocationNoida, India
Elsewhere