(a)
Frontend architecture
Monorepo topology, package boundaries, rendering strategy per route, and the type contracts that keep three products from drifting apart.
Portfolio — 2026
Open to senior frontend roles and select contract work
Ashish Kumar
Senior Frontend Engineer
Next.js & React Specialist
Four years deep in Next.js, React and TypeScript — shipping healthcare platforms, a UK telecom storefront and configuration tools where a slow page or a broken flow costs actual money. Architecture first, animations last, and performance treated as a feature rather than a cleanup task.
Fig. 01 — Frontend architecturehover to trace
build · deploy
▸$ next build --turbo
✓ Compiled successfully in 3.1s
○ (Static) prerendered as static content
- Experience
- 4+ years
- Remote
- 3+ years
- Best LCP gain
- −40%
- Lighthouse
- 95+
Next.jsReactTypeScriptTurborepoReact QueryZustandGraphQLTailwind CSSGSAPStorybookJestCypressNode.jsAWSDockerAEMStrapiCore Web VitalsWCAG 2.1 AANext.jsReactTypeScriptTurborepoReact QueryZustandGraphQLTailwind CSSGSAPStorybookJestCypressNode.jsAWSDockerAEMStrapiCore Web VitalsWCAG 2.1 AA
01About
Frontend ownership, end to end.
About Ashish Kumar
- Based in
- Patna, Bihar — India
- Working
- Remote-first · UK / EU overlap
- Experience
- 4+ years product engineering
- Core stack
- Next.js · React · TypeScript
- Currently
- Senior Frontend Engineer, Segwitz
- Also
- Freelance frontend consulting
Four years of frontend, spent almost entirely on products where the interface is the product.
I’m a senior frontend engineer working across healthcare, telecom, fintech, e-commerce, SaaS and industrial tooling. Most of that time has been in Next.js and React with TypeScript underneath, and most of it has been spent on systems that other teams depend on — a clinical platform used by operations staff every shift, a national telecom storefront measured in revenue per hundred milliseconds, a configuration engine where a wrong quantity becomes a wrong delivery on a construction site.
At Segwitz I own the frontend of the Genomas health platform: three products — Novameds B2B, Reveal B2C and an internal Admin Portal — running out of a single Turborepo with shared UI, shared hooks and one typed contract against the backend. The same role pulled in the BT/EE storefront work, where the brief was bluntly commercial: make it faster, make it accessible, keep the conversion journey intact. That work landed at 40% better LCP, 35% better FCP and Lighthouse scores above 95 on the audited routes.
Before that, at Latitude Technolabs, I moved quickly between client platforms — e-learning, fraud analytics, insurance quoting, real-estate search, AEM-backed frontends and a headless Strapi marketing site. Different domains, same recurring problem: an interface that had grown faster than its architecture. Picking those up mid-flight is why I now spend the first week of any engagement on structure rather than screens.
I’ve worked fully remote for three-plus years with teams across the UK, EU and US. That means writing things down: architecture notes, convention docs, PR descriptions that explain the trade-off. It also means I’m comfortable being the person who says a feature is not finished because it isn’t keyboard accessible, or because it pushed LCP past budget.
What I’m accountable for
(b)
Performance budgets
Core Web Vitals set as acceptance criteria — measured in the field, guarded in CI, and defended during feature work.
(c)
Accessibility
WCAG 2.1 AA conformance built into shared primitives: keyboard models, focus management, contrast, honest labelling.
(d)
Data layer
React Query for server state, Zustand for UI state, typed GraphQL/REST clients, and invalidation modelled per domain.
(e)
Delivery & testing
Storybook-driven components, Jest and Cypress on critical paths, contract tests at the API boundary, CI that gives a clear answer.
(f)
Mentorship
Architecture reviews, PR walkthroughs, pairing sessions, and the written conventions the team onboards from.
Domains shipped in
- Healthcare
- Telecom
- E-commerce
- Fintech
- SaaS
- Industrial
- EdTech
- Insurance
- Real estate
02Experience
Four years, shipped in production.
Not a list of responsibilities — a record of what I owned, how it was structured, and what changed because of it.
Work experience
01 — 2023 — Present
Segwitz
Senior Frontend Engineer
Full-time · Patna / Remote
- Next.js
- TypeScript
- Turborepo
- React Query
- Zustand
- GraphQL
- +2
Frontend owner across a portfolio of enterprise products — the Genomas health platform, a UK telecom e-commerce build and a parametric scaffolding configuration platform. I sit between design, backend and client stakeholders, and I'm accountable for the architecture, not just the tickets.
- 01Restructured the Genomas frontend into a Turborepo monorepo with shared UI, config and type packages, so Novameds (B2B), Reveal (B2C) and the Admin Portal stopped diverging and started shipping from one design system.
- 02Set the data layer conventions: React Query for server state with typed query keys and invalidation maps, Zustand for transient UI state — which removed a large class of duplicated-fetch and stale-cache bugs.
- 03Owned Core Web Vitals on the BT/EE storefront: route-level code splitting, image pipeline hardening, font loading strategy and third-party script deferral.
- 04Introduced component-driven development with Storybook plus contract tests against backend schemas, so breaking API changes fail in CI instead of in production.
- 05Mentor two mid-level engineers through architecture reviews, PR walkthroughs and pairing sessions; wrote the frontend conventions doc the team still follows.
- 06Built the dynamic scaffolding configurator UI: parameterised rule-driven forms, a live material take-off (MTO) preview and a multi-role checkout flow spanning Super Admin, Member and Finance.
40%
LCP improvement
35%
FCP improvement
95+
Lighthouse (mobile)
02 — 2021 — 2023
Latitude Technolabs
Senior Next.js / React Developer
Full-time · Patna / Hybrid
- Next.js
- React
- AEM
- Strapi
- Redux
- Node.js
- +1
Delivered client platforms across e-learning, fintech, insurance and real estate — often picking up codebases mid-flight and being asked to make them faster, testable and shippable.
- 01Built the E-Learning Labs student and instructor experience: lesson player, progress tracking and assessment flows on a Next.js SSR/ISR architecture.
- 02Shipped the E-Fraud Detection analyst console — dense real-time transaction tables, risk scoring visualisations and filter state that survived deep links.
- 03Rebuilt the Latitude Technolabs marketing site with a headless Strapi CMS and a typed component layer the content team could extend without engineering.
- 04Delivered Builder.ai product surfaces and an insurance quoting portal, including multi-step forms with validation, persistence and document upload.
- 05Worked on AEM-backed frontends, integrating authored components with React views and keeping templates consistent across locales.
- 06Standardised the internal Next.js starter — lint config, folder structure, API conventions and CI pipeline — reused across subsequent client projects.
6+
Client platforms shipped
5
Industries covered
03 — 2020 — Present
Freelance / Contract
Frontend Consultant
Contract · Remote
- Next.js
- React
- TypeScript
- Tailwind
- GSAP
- Vercel
Short, focused engagements: performance rescues, design-system extraction, migration off legacy React, and building the first version of a product frontend properly.
- 01Audit-and-fix engagements where the deliverable is a measurable performance and accessibility report plus the implementation, not a slide deck.
- 02Migrated legacy Create React App frontends to Next.js with incremental route-by-route adoption and zero downtime.
- 03Built motion-heavy marketing pages with GSAP and ScrollTrigger that stay at 60fps on mid-range Android.
- 04Embedded with distributed teams across the UK, EU and US — three-plus years of fully remote delivery, async-first communication and written design docs.
3+ yrs
Remote delivery
UK · EU · US
Timezones covered
NEWRecent Highlighted Projects
Current work in motion.
Animation Showcase
Radiant Animated Site
A highly interactive frontend experience featuring complex micro-animations and smooth transitions. Check out my best animation work here.
AnimationsInteractionsFrontend
Personal Project
ToolyConvert
A personal utility platform built to solve real-world conversion tasks effortlessly.
ReactUtilityFull-Stack
03Featured work
Three platforms, owned from architecture to release.
Featured work and case studies
Each of these is written up as a full case study — the problem, what I was responsible for, how it was structured, the parts that were genuinely hard, and what changed as a result.
01 / 03Healthcare / Genomics · 2023 — Present
Genomas Health Platform
A Turborepo monorepo serving three healthcare products from one typed design system.
Full-time at Segwitz
Novameds B2B
Wholesale ordering surface for clinics and distributors: catalogues, negotiated pricing tiers, multi-cart checkout and order history.
Reveal B2C
Consumer-facing genetic testing storefront with kit selection, a guided sample-registration flow and result delivery.
Admin Portal
Internal operations console — patient and sample records, lab pipeline states, user roles, content and reporting.
The problem
Three healthcare products had grown from the same origin into three codebases, each with its own component library, its own fetch layer and its own idea of what a button does. Features shipped to one product had to be re-implemented in the others, healthcare-specific states (loading, empty, error, restricted-by-role) were inconsistent, and clinical reviewers were seeing different behaviour for the same data on different surfaces. Release risk was climbing faster than the roadmap.
My role
Frontend architecture and delivery lead across all three surfaces. I defined the monorepo structure and package boundaries, set the data-fetching and state conventions, built the shared component and type layer, reviewed every significant PR, and worked directly with product and clinical stakeholders to turn ambiguous healthcare requirements into typed interfaces.
Results
3
Products on one codebase
1
Shared design system
B2B · B2C · Admin
Surfaces covered
- Three products now ship from one design system and one type layer — a component built once appears on all three surfaces.
- Duplicated fetch and caching bugs dropped sharply once server state and UI state had enforced homes.
- Onboarding a new frontend engineer takes days rather than weeks: one repo, one convention doc, one component catalogue.
- CI time stayed flat through the migration thanks to Turborepo caching, even as the number of apps grew.
- Role-based access and audit behaviour are now consistent across B2B, B2C and internal admin.
Architecture
- 01
Turborepo monorepo
Three apps — novameds, reveal, admin — plus shared packages for ui, hooks, api-client, types and config. Task graph with remote caching means a change to a shared component rebuilds only what depends on it, and CI stays under control as the repo grows.
- 02
Server state with React Query
One query-key factory per domain, explicit stale times, and an invalidation map co-located with mutations. Optimistic updates only where the backend contract guarantees them. Prefetching on intent for the flows where perceived latency mattered most.
- 03
UI state with Zustand
Cart, filters, wizard progress and panel layout live in small Zustand slices with selectors, kept entirely out of the server cache. The rule enforced in review: if the server owns it, React Query owns it.
- 04
Typed contracts end to end
API response types generated from backend schemas and consumed by all three apps, so a field rename is a compile error rather than a runtime surprise in a clinical workflow.
- 05
Role-aware rendering
A single permission model drives navigation, row-level actions and route guards across Novameds, Reveal and Admin — implemented once in the shared layer instead of three times with drift.
Key challenges
- 01
Merging three design languages without stalling delivery
A big-bang rewrite was off the table — features kept shipping. I extracted the shared UI package incrementally, starting with the highest-usage primitives, and codemodded consumers app by app so each migration was independently shippable and revertible.
- 02
Healthcare-grade data handling
Clinical records mean PII, strict role boundaries and audit trails. Every list, export and mutation needed explicit permission checks, defensive empty states and no client-side caching of sensitive payloads beyond what the flow required.
- 03
Cache coherence across tabs and roles
An admin action can invalidate data a B2B user is looking at. Invalidation was modelled per domain rather than per screen, with targeted query invalidation instead of blanket refetches that would have hammered the API.
- 04
Long, stateful multi-step flows
Sample registration and wholesale checkout both span several steps with validation and resumability. A shared wizard primitive handles persistence, step validation and deep-linkable state so each product only writes its business rules.
Technologies
- Next.js
- React
- TypeScript
- Turborepo
- React Query
- Zustand
- Tailwind CSS
- Storybook
- Jest
- Cypress
- GraphQL
- Docker
Technical highlights
- Turborepo app/package topology designed for three diverging products
- Query-key factory + invalidation map as a team convention
- Shared wizard primitive with resumable, deep-linkable multi-step state
- Incremental design-system extraction with zero delivery pause
02 / 03Industrial / Construction tech · 2024 — 2025
Dynamic Scaffolding Configuration & Ordering Platform
Rule-driven configuration, live material take-off generation and multi-role ordering.
Full-time at Segwitz
Super Admin
Defines the configurable product catalogue: component rules, compatibility constraints, pricing, tax, stock and the templates members configure against.
Member
The configurator itself — dimensions, structure type and constraints drive a live bill of materials, saved configurations and checkout.
Finance
Order, invoice, payment and credit workflows tied back to generated MTOs, with approval states and export.
The problem
Scaffolding orders were assembled manually: a customer described a structure, someone with domain knowledge worked out which standards, ledgers, boards and couplers were needed, and priced it in a spreadsheet. The process didn't scale, was error-prone, and gave customers no visibility into what they were actually buying. The product needed a configuration engine that encoded expert rules and produced an accurate material take-off on demand.
My role
Owned the frontend of the configuration and ordering experience across all three roles: the rule-driven form engine, the live MTO computation and preview, saved-configuration state, and the checkout/order workflow that hands off to finance.
Results
3
Role-based surfaces
Dynamic
Configuration engine
Live
MTO generation
- Configuration that took an expert with a spreadsheet now happens in-product, with an itemised material take-off generated instantly.
- Super Admin can introduce new configurable product families without an engineering release.
- Order, approval and invoicing share one lifecycle model across Member and Finance, removing manual reconciliation.
- Constraint validation catches invalid structures before they become an order, instead of after they become a delivery problem.
Architecture
- 01
Rule-driven form engine
Fields aren't hardcoded — Super Admin defines configuration parameters, constraints and dependencies, and the Member UI renders and validates them dynamically. Adding a new product family is a data change, not a release.
- 02
Derived MTO state
The material take-off is treated as a pure derivation of configuration inputs. Inputs live in a Zustand slice; quantities recompute through a memoised selector pipeline so the preview stays in sync without a server round-trip on every keystroke.
- 03
Server-authoritative pricing
Client-side numbers are an estimate for responsiveness; the server recomputes quantities and pricing at checkout. The UI makes the authority boundary explicit so nobody ships on a stale client calculation.
- 04
Role-scoped routes and navigation
Super Admin, Member and Finance share an app shell but resolve navigation, guards and action availability from a single role model — no duplicated permission logic per screen.
- 05
Order lifecycle state machine
Draft → quoted → ordered → approved → invoiced → fulfilled, modelled as explicit states. Every screen reads from the same machine, which removed a family of 'impossible status' bugs.
Key challenges
- 01
Encoding domain expertise in constraints
Scaffolding compatibility rules live in people's heads. I worked through them with domain experts, turned them into declarative constraint data, and built a validation layer that explains *why* a configuration is invalid — not just that it is.
- 02
Live computation without UI jank
Recalculating a full bill of materials on every input change is expensive on large structures. Selectors were scoped per component family and results memoised, keeping interaction latency well inside a frame budget.
- 03
Three roles, one mental model
Finance sees an order that Admin configured and a Member placed. Keeping IDs, versions and snapshots consistent across those views meant treating the order as an immutable record with references rather than a mutable shared object.
- 04
Checkout that tolerates change
Configurations get edited mid-flow. The checkout re-validates against the current rule set and surfaces a diff of what changed before committing an order.
Technologies
- Next.js
- TypeScript
- Zustand
- React Query
- Tailwind CSS
- React Hook Form
- Zod
- Node.js
- PostgreSQL
- Jest
Technical highlights
- Declarative constraint engine driving dynamic form rendering
- Memoised MTO derivation from configuration state
- Explicit order lifecycle state machine shared by three roles
- Client estimate / server authority pricing boundary
03 / 03Telecom / Large-scale e-commerce · 2023 — 2024
BT / EE UK E-commerce Platform
High-traffic telecom storefront where Core Web Vitals and WCAG are release criteria.
Full-time at Segwitz
Storefront
Public catalogue and offer pages: mobile plans, handsets, broadband and TV, with comparison, eligibility and pricing logic.
Checkout journeys
Multi-step acquisition flows with address, credit and tariff selection — conversion-critical and heavily instrumented.
Content & campaign surfaces
Marketing-led landing pages and campaign templates rendered from a CMS with strict performance budgets.
The problem
A national telecom storefront serves enormous organic and paid traffic, ranks in a brutally competitive SERP, and converts on a multi-step journey. Every hundred milliseconds of LCP is measurable revenue, accessibility is a legal and brand requirement, and the frontend consumes a large GraphQL catalogue API owned by another team. Slow pages, janky journeys and inaccessible components were direct commercial problems.
My role
Senior frontend engineer on the storefront: rendering strategy per route, GraphQL integration, Core Web Vitals remediation, WCAG conformance work, and contract testing against the backend catalogue API. I also owned the frontend performance reporting that went to stakeholders.
Results
40%
LCP improvement
35%
FCP improvement
95+
Lighthouse score
- 40% improvement in Largest Contentful Paint on the targeted storefront routes.
- 35% improvement in First Contentful Paint over the same baseline.
- Lighthouse scores above 95 across performance, accessibility, best practices and SEO on audited routes.
- WCAG conformance issues fixed in shared primitives, propagating to every templated page rather than per-page patches.
- Breaking GraphQL schema changes caught in CI by contract tests instead of surfacing in production.
Architecture
- 01
Deliberate rendering strategy per route
Catalogue and offer pages are SSG/ISR with targeted revalidation so marketing changes go live without a deploy. Eligibility, pricing and checkout are dynamic and streamed. Nothing is server-rendered by default just because it can be.
- 02
GraphQL with a typed client layer
Operations colocated with the components that use them, generated types, and a normalised cache layer. Field-level selection kept payloads small — the catalogue API can return far more than a page needs.
- 03
Component-driven UI with accessible primitives
Storybook-backed components with keyboard and screen-reader behaviour specified in the component contract, so accessibility is a property of the primitive rather than something each page re-implements.
- 04
Contract testing at the API boundary
Consumer-driven contract tests verify the frontend's assumptions about the GraphQL schema. Breaking changes fail in CI, which matters when the API is owned by a different team on a different release train.
- 05
Performance instrumentation
Lab (Lighthouse CI) plus field (RUM) measurement, with budgets per route. Improvements were only claimed when the field data agreed with the lab.
Key challenges
- 01
LCP on image-heavy offer pages
Handset imagery dominates the viewport. Fixing it meant responsive srcsets at real device sizes, modern formats, correct priority hints on the single above-the-fold image, CDN cache configuration, and removing the layouts that caused images to be discovered late.
- 02
Third-party script weight
Analytics, tagging, chat and payment SDKs competed with the page. Scripts were audited, deferred or moved off the critical path, and their cost reported per tag rather than accepted as unavoidable.
- 03
WCAG conformance at catalogue scale
Thousands of templated pages inherit whatever the components do. Fixes had to land in the primitives: focus management in modals and mega-menus, honest labelling on price and tariff tables, contrast on promotional styling, and a keyboard path through every journey.
- 04
Layout shift from dynamic pricing and promos
Eligibility-dependent content arriving after render caused CLS. Reserved space, skeleton sizing matched to real dimensions and streamed placeholders removed the shift without delaying the content.
- 05
Another team's API, another team's release
Contract tests plus a defensive rendering layer meant schema drift degraded a component gracefully instead of blanking a revenue page.
Technologies
- Next.js
- React
- TypeScript
- GraphQL
- Tailwind CSS
- Storybook
- Cypress
- Jest
- AWS
- Docker
- Lighthouse CI
Technical highlights
- Per-route rendering strategy: SSG/ISR for catalogue, streamed dynamic for eligibility
- Image pipeline rebuilt around real device sizes and discovery order
- Third-party script audit with per-tag cost reporting
- Consumer-driven contract tests against an external GraphQL API
04More shipped work
Six more platforms, same standard.
Client work delivered at Latitude Technolabs and on contract — e-learning, fraud analytics, headless marketing, no-code SaaS, insurance and proptech.
E-Learning Labs
Student and instructor experience for a course platform, on SSR/ISR with resumable lessons.
2022Case study
E-Fraud Detection Console
Dense real-time transaction analysis for fraud operations teams.
2022Case study
Latitude Technolabs Website
Agency site on headless Strapi with a typed component layer the content team owns.
2021 — 2022Case study
Builder.ai Product Surfaces
Frontend delivery on app-builder product flows inside a fast-moving platform team.
2022 — 2023Case study
Insurance Quoting & Policy Platform
Multi-step quoting, policy comparison and document handling for an insurance product.
2022Case study
Real-Estate Search & Listings Platform
Map-linked property search with deep-linkable filters and fast listing pages.
2021 — 2022Case study
05Technology
The stack, mapped.
Technologies and tools
No percentage bars — a percentage of TypeScript means nothing. Every item here is something I have shipped with, what I actually use it for, and which project it appears in.
Hover · focus · tap
Select a technology to see how I use it and where it has shipped. On desktop, the rest of the wall dims so you can read one thing at a time.
Core
Where the day-to-day lives.
State & Data
Server state and UI state kept honestly apart.
Interface & Motion
Design systems, then animation as behaviour.
Quality
Confidence that survives a refactor.
Platform & Delivery
Frontend that deploys without drama.
CMS & Content
Where marketing meets engineering.
Craft
Non-negotiables on every build.
06Engineering philosophy
How I decide things.
Engineering philosophy
Eight positions I hold on every project. They are opinions formed by production incidents, failed refactors and the audits that followed.
- 01
Performance is a feature
core-web-vitals
Budgets are set before the first component is written, not negotiated after the audit. Every route gets a rendering strategy on purpose — static, incremental, streamed or dynamic — and third-party scripts have to justify their bytes.
40% faster LCP and 35% faster FCP on a production telecom storefront, measured in the field.
- 02
Architecture before components
scalability
A monorepo, a typed contract between client and server, and a clear boundary between server state and UI state do more for velocity than any component library. Structure decides how cheap the next change is.
Three Genomas products share one UI package, one config layer and one type system.
- 03
Accessibility is baseline quality
wcag-2.1-aa
Semantic markup, a coherent keyboard model, visible focus, honest labelling and sufficient contrast. If a component only works with a mouse, it isn't finished — it's a demo.
WCAG-conformant delivery on an enterprise UK e-commerce platform.
- 04
Component-driven development
storybook
Build components in isolation with documented variants and states, then compose. Storybook is where edge cases get found — empty, loading, error, overflow, long-label — before QA finds them.
Shared design-system package consumed by B2B, B2C and admin surfaces.
- 05
Readable code outlives clever code
maintainability
Small typed functions, explicit data flow, names that describe intent, and comments that explain why. I write for the engineer who inherits this in eighteen months, who is usually me.
Frontend conventions doc adopted across the team and used in onboarding.
- 06
Test the behaviour, not the implementation
jest · cypress · contracts
Unit tests on logic, integration tests on user journeys, contract tests on the API boundary. Coverage that breaks when behaviour breaks is worth more than coverage that breaks when markup changes.
Contract tests catching breaking schema changes in CI before release.
- 07
SEO is an engineering decision
metadata · structured-data
Render strategy determines crawlability. Server-rendered critical content, a deliberate metadata layer, canonical discipline, sitemaps and schema — decided at architecture time, not bolted on.
SSR/SSG storefront routes with structured data and stable Core Web Vitals.
- 08
Developer experience is delivery speed
dx
Fast builds, useful types, sane folder structure, working local environment in one command, and CI that gives a clear answer. Friction in the toolchain is friction in every feature that follows.
Turborepo caching and a standardised Next.js starter reused across projects.
07Numbers
Measured, not estimated.
Only figures I can point at: field Core Web Vitals deltas on a production storefront, Lighthouse on audited routes, and time actually spent doing this work.
- Years of frontend experience
- 0+
- Years fully remote
- 0+
- LCP improvement
- 0%
- FCP improvement
- 0%
- Lighthouse score
- 0+
- Industries delivered in
- 0
React & Next.js product engineering
Distributed teams across UK, EU & US
Largest Core Web Vitals gain shipped
Same production storefront baseline
Performance, a11y, best practices, SEO
Healthcare · telecom · fintech · SaaS · e-comm · industrial
08Contact
Have a product that needs a better frontend?
Contact Ashish Kumar
If you have a product where the frontend is the bottleneck — slow, inconsistent, hard to extend, or failing an accessibility or performance bar — that is exactly the conversation I want to have. Full-time senior roles and focused contract work both welcome.
- asshishkumar312@gmail.com
- GitHub
- Patna, Bihar · India
Remote-first · Overlapping hours with UK & EU teams
Typical reply — within two working days
Detailed CV and references available on request.