Skip to content
Shubham TiwariDossier

First Light · India · UTC+5:30

Hi, I'mShubham Tiwari

Frontend Engineer

I build fast, accessible web platforms — and the systems that keep them fast as they grow.

Years
4
Technologies
24
Shipped worlds
4
Shubham Tiwari

Observer's Log · 4 years · India

About

Location
India
Timezone
Asia/Kolkata · UTC+5:30
Experience
4 years
Focus
Frontend platforms, performance, accessibility
Currently
Astro, design systems
Availability
Weekdays
Writes at
dev.to/shubhamtiwari909
Open to
Frontend / platform roles
Most frontend problems are really delivery problems — the interesting work is making the fast path the easy path for everyone who touches the codebase.

I've spent four years on frontend platforms — the kind where the hard part isn't the component, it's that a lot of people need to ship pages without breaking the build. Most of my work has been migrations and plumbing: moving legacy applications onto Next.js, standing up a headless CMS that took page publishing from two pages a sprint to two a day, and wiring a Playwright suite covering E2E, API, accessibility, and visual regression so releases stopped being a negotiation.

I care more about the second year of a codebase than the first week of it. In practice that means I'd rather add a lint rule than a conventions document, and I'll usually argue for the boring, typed, testable version of a feature. Outside of work I build small things to learn from — an AI content app on Gemini, a blog CMS on Payload — and I write up what breaks at dev.to.

Open questions

  • How far can a design system go before it starts constraining product velocity?
  • What does genuinely accessible rich-text editing look like?
  • Where does AI-assisted development actually pay off in a large codebase — and where does it just add review load?
  • TypeScript
  • React
  • Design systems
  • A11y
  • Performance

The Atlas · 24 entries · 3 constellations

Skills

Magnitude encodes depth of experience, not preference. The lines are real dependencies — React to TypeScript, Payload to MongoDB, Next.js out to Vercel.

Spectrograph

24 lines · depth of experience

Sweep across it, or use the arrow keys

Docker

Familiar

Tooling · magnitude 60

No dependency lines recorded.

InterfaceFrontendSubstrateBackend & dataOperationsTooling & qualityAI-assisted developmentCSSESLint / PrettierGitHTMLJavaScriptNode.jsReactTailwind CSSTypeScript
Core(10)Daily. Can debug deeply and would defend design decisions.
  • CSSFrontend
  • GitTooling
  • HTMLFrontend
  • JavaScriptFrontend
  • ReactFrontend
  • Tailwind CSSFrontend
  • AI-assisted developmentTooling
  • ESLint / PrettierTooling
  • Node.jsBackend
  • TypeScriptFrontend
Working(12)Shipped production work; comfortable without hand-holding.
  • FigmaTooling
  • Gemini / LLM APIsBackend
  • Next.jsFrontend
  • Payload CMSBackend
  • REST APIsBackend
  • AccessibilityTooling
  • AstroFrontend
  • ExpressBackend
  • Performance optimisationTooling
  • PlaywrightTooling
  • SEOTooling
  • VercelTooling
Familiar(2)Used and functional; would need a ramp-up.
  • MongoDBBackend
  • DockerTooling

Trajectory · 4 years · 7 burn events

Experience

Each burn is a moment where deliberate effort changed the vehicle's course.

  1. Frontend Engineer

    4 years

    1. Burn 01

      Next.js platform modernization

      Led the migration of legacy frontend applications to Next.js, improving performance, SEO, accessibility, and developer experience.

      • Next.js
      • React
      • TypeScript
    2. Burn 02

      Headless CMS & delivery

      Designed and built a scalable headless CMS on Next.js, Payload CMS, and PostgreSQL, transforming how fast pages reach production.

      14×faster page deliveryFrom 2 pages per 14-day sprint to 2 pages per day

      • Next.js
      • Payload CMS
      • PostgreSQL
    3. Burn 03

      Multi-brand CMS setup

      Architected a multi-brand CMS on a monorepo, improving code reuse, maintainability, and onboarding speed for new brands.

      • Monorepo
      • Payload CMS
      • Next.js
    4. Burn 04

      Playwright automation suite

      Built a Playwright suite covering E2E flows, API testing, UI and snapshot tests, accessibility checks, link validation, and authentication workflows.

      • Playwright
      • TypeScript
    5. Burn 05

      Cross-team delivery ownership

      Worked with backend, QA, and product teams to own frontend delivery and improve product stability and release confidence.

    6. Burn 06

      Database schema & data migrations

      Performed database schema and data migrations in coordination with Payload CMS and PostgreSQL.

      • PostgreSQL
      • Payload CMS
    7. Burn 07

      Legacy JSP maintenance

      Maintained and enhanced legacy JSP applications, enabling gradual modernization without disrupting production systems.

      • JSP
      • Java

Instrument Bay · 4 instruments

What I Build

The tools and systems behind the products, rather than the products themselves.

Instrument Bay · Diagnostic Console
  • I-01Zentauri UIReact + Tailwind v4, token-first, axe-core in CIONLINE
  • I-02Playwright automation suiteE2E, API, snapshot, a11y, link validation, auth flowsCALIBRATED
  • I-03Multi-brand monorepo CMSNext.js + Payload + PostgreSQL across brandsACTIVE
  • I-04OrbitWebGL n-body simulation with live telemetryDEPLOYED