kargulstudio/calender-app-design

This is a design prototype to evaluate, not a tool to adopt for real scheduling. It is worth looking at if you want a working reference for a calendar and leave-management interface; it is not a place to store actual team data.

The problem

A team designing a people-ops workspace usually starts from a Figma file, then rebuilds the same calendar grid, event popovers and request dialogs in code before anyone can click through them. The friction is that visual decisions stay static until enough implementation work exists to test interactions such as dragging an event across days or counting working days for a leave request. Here the design has already been carried into a running web app: the Time off page reproduces the source dashboard design, and the sidebar's other pages follow the same visual language. That changes the starting point from "review a mockup" to "click a working prototype", but it does not change what the artifact is.

What's different

The distinguishing part is the amount of interaction detail the README says is implemented on the front end. The calendar has week, day and month views, drag-to-create, drag-to-move across days, resize-by-bottom-edge, side-by-side layout for overlapping events, an all-day lane with public holidays and a live now-line. Time off adds a request dialog that skips weekends and holidays when counting working days and shows the balance after the request, plus a filterable requests table and a manager approve/decline preview. A command palette, keyboard shortcuts and dark mode round out the shell.

The mechanism is deliberately simple: there is no backend, and state is kept in the browser with Zustand's persist middleware writing to localStorage. That makes the prototype easy to host as a static demo and easy to reset, but it also means the data model, permission model and server-side validation are not exercised. The README states plainly that the seed data reproduces the design's week of Nov 8–14, 2026, and points to Settings → Data → Reset demo data for returning to the exact design state. Treat the approve/decline view as a UI preview rather than evidence of a working approval workflow.

Who should try it

Front-end developers and designers building an internal scheduling or leave-management interface are the clearest audience: the live demo gives them a concrete interaction reference for drag behavior, overlapping layout, and keyboard navigation. Teams looking for a demo skeleton to fork for their own visual language are also a reasonable fit, since the README maps Figma variables to Tailwind design tokens and separates UI primitives, shell, calendar and time-off components.

The poor fit is anyone who needs an actual calendar or time-off tracker for a team. Because all data persists only in the browser, there is no shared state between people, no accounts and no durable record. Someone evaluating full leave policy logic will also find this a thin surface: the README describes working-day counting and allowance arithmetic, not a policy engine.

Requirements and limitations

The setup is a standard Node-based Next.js workflow: install dependencies and run the dev server, then open localhost. The stack is modern and tied to current versions — Next.js 16, React 19, Tailwind CSS v4 and shadcn/ui with Radix primitives — so anyone integrating the code into an older app should expect adaptation work. There is no database, authentication or API layer, and the README does not describe any path to adding one, so backend-related work is entirely left to the reader.

The ongoing limitation is state scope. localStorage survives reloads in the same browser but is not a shared or authoritative source, and cross-device or multi-user behavior is outside what the prototype provides. The demo can be restored to its designed state through the reset control, but that is a prototype convenience, not a data management strategy. Anyone who wants to reuse this should decide up front which parts are visual reference and which parts they are prepared to rebuild with a real backend.

HotRepo's take

HotRepo's only recorded observation is a NEW-REPOSITORY board placement for TypeScript at #11 on 2026-10-27, with 113 total stars; that is not an overall Trending rank or a daily growth measure. The repository was created on 2026-10-26, so the tracked evidence covers a single date and cannot establish whether interest persists. Given that, the sensible verdict is to treat this as a design reference: open the live demo and read the project instructions to judge whether the interaction details match what you need, and verify the license before lifting components into your own codebase, rather than evaluating it as a production calendar.