SoldNest
Frontend engineer across multiple production Nuxt applications, contributing to SSR/SSG architecture, shared design system migration, GraphQL integrations, and platform stability across a growing multi-repository ecosystem.
Overview
Worked as a frontend engineer across multiple production Nuxt applications handling SEO-sensitive marketing pages, shared component infrastructure, and GraphQL-connected data layers. The work covered SSR/SSG rendering, implementing evolving product experiences, design system migration, Apollo integration, and cross-repository frontend development — across several codebases sharing conventions and components.
A meaningful part of the role involved production debugging: tracing hydration mismatches between server and client renders, investigating rendering inconsistencies in generate mode, and addressing design token drift that had accumulated across repositories over time. Feature delivery and platform stability ran in parallel, which required knowing when to fix root causes versus apply targeted workarounds.
Engineering Scope
Marketing Platform
SEO-sensitive pages running in SSR and generate modes. Rendering had to be consistent between server and client — mismatches caused visible flicker and metadata issues in production. Structured page metadata and hydration correctness were ongoing concerns.
Shared Design System
Tailwind-based component library shared across production repositories. Implemented new and refactored product experiences from evolving design requirements while keeping components aligned with the shared token system. Migration involved normalizing diverged patterns incrementally across codebases.
GraphQL / Apollo Layer
Apollo client integration across production applications. Data-fetching behavior differed between SSR and client-side rendering contexts, requiring attention to query timing, cache initialization, and fetch policy choices that worked correctly in both environments.
Multi-Repository Codebase
Frontend work spanning multiple production repositories with shared dependencies and conventions. Changes to shared components or tokens had to be coordinated across codebases — context switching and downstream awareness were part of the daily work.
Representative Engineering Initiatives
Design System Migration Across Repositories
Context
Multiple production repositories had independently diverged from shared styling conventions — token values, spacing scales, and component patterns had drifted enough to make cross-repo UI work inconsistent and error-prone.
Work
Audited diverged patterns, mapped them to shared token equivalents, and migrated components incrementally to a normalized Tailwind-based system. Built reusable components consumed across applications and coordinated rollout to avoid breaking visual consistency mid-migration.
Token normalization · Reusable component architecture · Cross-repository consistency
SSR / SSG Production Stabilization
Context
SSR and generate-mode behavior differed meaningfully from local development. Hydration mismatches caused visible DOM flicker in production, and generate-mode pages had rendering inconsistencies that only appeared in the built output — not in dev mode.
Work
Traced mismatches to component logic reading browser-only values during server render and conditional rendering sensitive to environment. Fixed per component and validated against production SSR output — dev mode masks a meaningful subset of these issues.
Hydration debugging · Server/client rendering boundaries · Production verification
Nuxt 2 → Nuxt 3 Migration
Context
The upgrade introduced breaking changes across the Options API → Composition API transition, SSR lifecycle hooks, plugin registration, and module compatibility.
Work
Contributed to migration across production applications — refactored lifecycle hooks to Composition API equivalents, resolved plugin registration breakage, and identified components with environment-specific assumptions that broke under Nuxt 3 SSR. Validated production parity in staging before releasing.
Composition API migration · SSR lifecycle compatibility · Migration stability
GraphQL / Apollo Integration
Context
Data-fetching behavior differed between SSR and client-side rendering contexts — cache initialization, fetch timing, and query behavior had to work correctly in both.
Work
Integrated Apollo client with consistent query and cache patterns across production applications. Debugged SSR-specific data-fetching issues — fetch timing relative to server render, cache hydration mismatches, and fetch policy differences between environments.
Apollo SSR integration · Cache initialization · Data-fetching reliability
Technical Challenges & Solutions
Hydration mismatches in SSR
Problem
Components produced different HTML on the server vs. client, causing visible DOM flicker and Vue hydration warnings in production. The causes were not always obvious from the error output alone.
Solution
Traced mismatches to component logic that read environment-specific values during render — window references, conditional rendering based on browser state, and data initialized differently on server vs. client. Fixed per component, then validated against production SSR output rather than dev mode, which masks some of these issues.
Design token drift across repositories
Problem
Different repositories had independently adjusted spacing, color, and component patterns over time. Working across codebases meant constantly reconciling differences that looked subtle but caused real inconsistency in shared interfaces.
Solution
Audited diverged patterns against the intended token system, migrated components to shared Tailwind config values, and normalized the most widely used patterns first. Reduced the surface area of inconsistency without requiring a full rewrite across every codebase at once.
Nuxt 3 migration breakage
Problem
The Nuxt 2 → 3 upgrade introduced breaking changes across lifecycle hooks, SSR plugin behavior, and the Options API → Composition API transition. Several components had subtle assumptions baked in that only surfaced at runtime in an SSR context.
Solution
Approached the migration incrementally — identified high-risk components first, refactored lifecycle hooks to Composition API equivalents, and tested SSR behavior in staging before merging. Components with environment-specific logic were the most fragile and required the most careful validation.
Technologies & Systems
Engineering Growth
- Strengthened SSR debugging instincts — production hydration bugs require reasoning about what exists on the server vs. the client at render time, not just reading component code in isolation.
- Improved platform-level frontend thinking: shared components and design tokens are infrastructure. Changes propagate across codebases, and careless migrations create inconsistencies that are expensive to clean up later.
- Developed better multi-repository awareness — tracking which changes have downstream dependencies, when to coordinate across codebases, and when it's safe to move independently.
- Built more disciplined tradeoff judgment around stability vs. velocity: some production issues warrant a root-cause fix immediately; others are safer to contain and schedule properly.
- Gained practical understanding of Nuxt internals that only comes from debugging production: how SSR hydration works, how generate mode differs from server mode, and where each breaks under real conditions.