DEVHuman Resources · demo kitEverything built so far, one section per module: 18 modules, 77 pages and 104 screenshots at 1600 by 900 (73 of the current build on sample data and 31 more with live data). Click a picture to see it full size. Every name, number and date is sample data. The modules below run on sample data held in the page (nothing is saved and there is no sign-in); the last section, Live data, shows the same app reading and saving to a database.
npm start in the project folder, then use the “Open live” links (they open the shell at 127.0.0.1:4180 as the right sample user). Pictures were taken 2026-11-06 with npm run demo-shots.The sidebar is built from each person’s permissions. A page or module someone may not use is not greyed out: it is simply not there. Same app, three different people:
The HR manager: every module, and the controls to change things.
18 of 18 menu groups
A manager sees their team: attendance, leave approvals, contracts, performance.
9 of 18 menu groups
An employee sees only their own leave, timesheet and notices.
4 of 18 menu groups
What an employee sees about themselves and nobody else: profile and documents, leave and balances, this week’s timesheet, notices to read, onboarding and goals.
Daily registers for showroom and warehouse casuals: hours, present or absent, submit for review, approve or return.
One directory of everyone who has worked for Hisense, whatever the arrangement, with every engagement over time.
Intern and National Service placements: host department, supervisor, daily days-worked sheet, end-of-placement summary.
From job requisition to hire: candidates, pipeline stages, interviews, offers and hire conversion.
The employee directory and profile, plus onboarding: plans, day-one checklist, orientation and compliance documents.
Work permit and visa cases with expiry dates, so renewals are started in time.
Employment contracts, renewals and expiry, with approval of each renewal decision.
Who is expected and who came in, by team and day, and the weekly shift schedule with hours limits.
Weekly timesheets: submit, approve by the team lead, chase missing ones, lock periods, manage time codes.
Vehicles, drivers and trip bookings with service, insurance and licence dates; double-booking is refused.
Leave requests and approvals with team cover, balances in days, who is away, leave policy and public holidays.
Appraisal cycles, self-assessments, manager evaluations, probation reviews and improvement plans.
Exit cases from notice to last day: department clearance checklist and exit interviews.
Notices to staff: inbox, announcements, policy notices with read tracking, and delivery rules.
Headcount, attendance and absence, leave taken, expiring contracts and permits, recruitment funnel, review completion.
Phone extensions for staff, the call log, missed calls that need a call back, and phone settings. Calls are listed, never recorded.
Roles and permission sets, the audit log, access reviews and system settings.
Everything above runs on sample data held in the page. These screens were taken with the app reading and saving to a real database (a local scratch copy, sample people only), signed in as people with different permissions. The banner at the top of each page says so. The database, not the page, decided what each person could see and do.
The same page, three different sample people. The database decides which rows come back; the page only draws them.
Reading and saving through the database. Whole-batch actions report exactly what was refused and why.
Lists read from the database, paged and filtered on the server, with the sensitive details withheld.
Who is expected, who came in and the weekly schedule, read from and saved to the database. Every save carries the version it saw, so a row someone else changed comes back stale.
Requests, approvals and who may ask on whose behalf are decided by the database.
Not shown live: the pages not listed above still read sample data, and nothing has been applied to the shared DEV database yet.
