Upnova.app

I joined when the product had traction but no unified frontend architecture. Dashboards looked different from module to module. State logic was duplicated. New features took weeks because every screen started from scratch.

The traditional approach — 'just ship the next ticket' — wasn't failing loudly. It was failing quietly: slower releases, growing regression risk, and a team that spent more time aligning in meetings than building.

Before writing a single component, I asked one question: What system would let this product scale for the next two years — not just the next sprint?

I audited every major user flow: onboarding, dashboard navigation, settings, and reporting. I mapped where components were reused, where they were forked, and where UX broke consistency.

Parallel to the UI audit, I ran lightweight stakeholder sessions — product owners described goals in outcomes, engineers described constraints in APIs, and support described pain in user tickets. Three languages, one product.

The output wasn't a Figma file. It was a decision document: what we would standardize, what we would deprecate, and why a component-first architecture was the only path that reduced long-term cost.

I structured the frontend in four layers: foundation tokens (spacing, color, typography), primitive components (inputs, buttons, modals), composite modules (dashboard cards, data tables, onboarding steps), and page templates that orchestrated layout only.

Routing and data-fetching lived in Next.js App Router patterns. Server components handled initial load; client components handled interactivity. State was scoped — global only where truly shared.

Every new feature followed the same path: define the data contract → identify existing modules → compose → test → ship. What used to be a guessing game became a repeatable pipeline.

Product thought in user stories and KPIs. Backend thought in endpoints and schemas. Design thought in flows and visual hierarchy. When these stayed in silos, meetings ran long and decisions evaporated.

Instead of forcing everyone into a single format, I created parallel communication channels that met each discipline where they were — then converged into one shared artifact.

For product: outcome-based roadmaps tied to component milestones. For backend: OpenAPI-aligned TypeScript interfaces both sides could trust. For design: a living component catalog that replaced static handoff PDFs.

When friction appeared — and it did — I didn't retreat into solo execution. I facilitated short, focused syncs with clear agendas: 'What blocks shipping this module?' Not 'Why isn't this done yet?'

We introduced a structured QA pass: component-level checks before page integration, accessibility sweeps on every composite module, and performance budgets on dashboard routes.

Regression frequency dropped. New module delivery accelerated. Onboarding for developers joining the project went from 'read the whole codebase' to 'start with the component catalog.'

Most importantly, the team stopped treating the frontend as a bottleneck. It became a predictable engine — think first, build once, compose everywhere.