Finoo Admin - Partners, Users, and Dashboard Modules in Vue 3

Summary

• Delivery: shipped Partners, Users, and Dashboard modules with complete internal-operational screens (list, detail, create).
• Scalability: consolidated the data layer and standardized server state (cache, invalidation, loading/error) to keep behavior predictable per module.
• Reuse: strengthened shared UI building blocks (table and form patterns) to reduce “feature spaghetti”.

Over ~3 months, I owned a key slice of a Vue 3 + Vite + TypeScript admin SPA, unblocking internal workflows with consistent UX and a technical foundation that enables continued delivery with less rework.

Context

• The project is a web admin for internal operations: managing partners/users and providing an overview with KPIs and charts.
• The app consumes an internal REST API and uses token-based authentication (JWT via backend).
• In this period, there wasn’t a clearly established automated testing + CI pipeline, so I reduced risk through typing, component patterns, and review discipline.

Key Challenges

• Scaling real CRUD UI (tables, filters, empty/loading states, modals, and forms) without creating hard-to-maintain code.
• Data reliability across multiple resources (cache, invalidation, pagination, typing) without inconsistencies between screens.
• Data visualization: shaping API responses into readable charts without misleading representation.
• Operating without tests: keeping speed while reducing regressions with TypeScript, a structured data layer, and shared components.

What I did

• Partners (partner management)

  • Built list/create/detail screens and components, including forms and structured detail sections (e.g., legal, banking, balance).

• Users (user management)

  • Improved the data layer (API integration + typing) and wired it into list/detail UI to reduce operational friction.

• Dashboard (KPIs and charts)

  • Evolved the home dashboard with KPIs and charts, handling loading/empty/error states and transforming data for visualization.

• UI Core (shared components)

  • Contributed to high-leverage shared building blocks (table and form patterns) to improve consistency, reuse, and predictability across modules.

Decisions & Trade-offs

• Server-state per resource > global store for everything

  • Why: standardizes caching/invalidation and loading/error states per feature with less coupling between screens.
  • Trade-off: requires clear conventions to avoid inconsistencies and hard-to-track invalidations.

• Headless UI + composition > rigid pre-styled components

  • Why: flexibility to build admin tables/forms/modals with good accessibility and consistent UX.
  • Trade-off: greater responsibility to maintain standards, especially for tables and form flows.

• Specific example (reducing regressions without tests)

  • I standardized cache/update conventions per module (lists vs details) and ensured consistent table states (loading/error/empty) to avoid “half-broken” screens in edge cases.

Results

• Measured (engineering): 82 commits attributed to me (~39% of the repo), concentrated on Partners/Users/Dashboard and shared UI.
• Concrete technical proxies:
  • 3 core modules delivered with complete operational flows (list/detail/create).
  • Expanded data layer + typing to support multiple resources with less repetition.
  • Dashboard improved with KPIs/charts, including data shaping and predictable UI states.
• Operational impact: the admin supported internal workflows with fewer external workarounds (spreadsheets, ad-hoc requests), increasing day-to-day predictability.

Note: product metrics (time saved, ticket reduction, efficiency) weren’t publicly available; redacted evidence can be organized upon request.

What I’d do differently

• Add tests + minimal CI: build/type-check + lint on PRs, plus component tests for critical tables/forms.
• Document data conventions: caching/invalidation/pagination patterns to scale contributions consistently.
• Frontend observability baseline: error tracking and essential events to surface failures and operational bottlenecks.