Back to projects
lumir-erp
Stage 4 (in-role · adapting to 4 domains)

Lumir-ERP (internal back office)

Four domain workstreams together — full-stack CMS + frontend for resource scheduling, LRIM, and interview management

Workstreams
4 domains
CMS
Solo full-stack
Public exposure
Applicants
AI-written
100%
Architecture · data flow
Architecture · data flow
Forward requestResponse · write-backExternal system

A 4-domain back office serving every employee plus external applicants. The frontend orchestrates external APIs (AMS·CMS·LRIM) and MongoDB for UAM; only CMS is solo full-stack (planning · BE · tests). The Plan (mock) / Current (real API) split (inherited from the team lead) is applied consistently across all four — the real asset is adapting to four domains at once.

Problem

We needed full-stack delivery of four internal back-office domains (resource scheduling · CMS · LRIM hiring · LRIM interview management). It's the company's broadest-user project — every employee, plus recruiters, interviewers, evaluators, and external applicants.

System

Next.js 14/15 (App Router) + TypeScript + Tailwind + shadcn/ui + SWR + Playwright. A Plan (mock) / Current (real API) environment-split pattern (inherited from the team lead) + per-domain Context + (cms)/(sms)/(ams)/(uam) domain separation + UAM uses MongoDB directly. The two LRIM apps form a pnpm + Turborepo monorepo (@repo/ui · common · modules). 100% AI-native: AI writes code; I review the UI planning, code connections, and own the e2e tests.

Impact

A 4-domain back office running in production for every employee plus external applicants. CMS is solo full-stack (planning · backend · tests; frontend tests are being improved). For the other three, I own all frontend functionality. The real asset isn't 'four projects' — it's the ability to adapt to four domains in parallel and the full-cycle solo experience on CMS.

My contribution

All four workstreams (scheduling · CMS · LRIM · interview mgmt) implemented end-to-end. CMS is solo full-stack (planning · backend · tests). The Plan/Current pattern is applied consistently across all four.

Inherited scope

The Plan/Current split + domain-context patterns like WikiContext (designed by the team lead). My role: applying them across the four workstreams.

Honesty note (for interviews)

The Plan/Current and domain-context patterns are the team lead's design, not mine. The CMS frontend tests are still being improved. For scheduling and LRIM, only the frontend is mine — the backend is owned elsewhere.

Interview Q&A prep

Q.Can you explain the Plan/Current environment-split pattern?+
A.It's a frontend architecture set up by the team lead. 'planning' finishes UI and planning with mock data; 'current' connects to the real backend API. _services/ holds v1·v2 versioning. I applied it consistently to the four workstreams.
Q.How did you run four workstreams in parallel?+
A.AI-native, plus consistent team patterns (Plan/Current · domain Context) and domain separation (API path rules). Individual domain knowledge was absorbed via AI as a thinking partner.
Q.What did you design vs. inherit?+
A.Inherited: Plan/Current + domain-context patterns + the monorepo structure. Mine: all four workstreams' features + the CMS backend and tests.
Q.What are you most proud of?+
A.Solo full-stack CMS (planning through backend tests) — the only full-cycle workstream of the four. Or, the adaptability of running all four domains simultaneously.
Keywords
Next.js App RouterPlan/Current environment splitSolo full-stack CMSLRIM hiring & interviewsExternal applicants100% AI nativePlaywright E2Eshadcn/ui
📊 Quantitative metrics pending (not yet measured)
  • ·Start date of each workstream
  • ·Cumulative hours across the 4 workstreams
  • ·Internal user count
  • ·Cumulative external applicants