DTRCam●

Attendance that keeps up
with the workday.

DTRCam keeps the attendance flow focused: employees record a time-in or time-out, while administrators can review punch records and manage the people behind them.

THE IDEA: Make daily attendance practical
MY WORK: Interface, API & deployment
BUILT WITH: SvelteKit · Supabase · Docker
EXPLORE: Source on GitHub ↗

DTRCam sign-in, employee attendance, and administrator overview on three phones. Sample content only. — Employee and administrator views · Presentation mockup with sample content

01 / THE PROBLEM

A task that should feel
uneventful.

Attendance should fit into a workday—not ask people to work around it.

DTRCam is designed around a narrow, repeatable flow: sign in, select the right attendance action, and capture the record. The employee-facing view stays straightforward while the admin area gives the team a clearer place to review activity.

The project also considers what happens beyond the ideal connection: records can be kept locally and synchronized when the application is able to reach the server again.

02 / THE EXPERIENCE

One clear action.
A useful record.

Built around the everyday employee
and the person reviewing the data.

Time in, time out

Employees have an uncomplicated view for recording arrival or departure, including a camera-based attendance flow.

Records to review

Punch history gives administrators a dedicated place to inspect attendance entries and follow up on exceptions.

Built for real connectivity

Local capture and a sync queue help preserve attendance records when the network connection is temporarily unavailable.

03 / BEHIND THE APPLICATION

An application is more
than the happy path.

Browse the code

Web application, mobile-first

SvelteKit provides the interface and routes, with the layout designed to be comfortable to use from a phone. Supabase supports the application’s data and authentication needs.

Keeping records resilient

An IndexedDB-backed queue holds locally captured records until the application can synchronize them. The aim is simple: a temporary network problem should not lose someone’s attendance record.

Deployment that stays understandable

The project can run through a Docker build and Compose setup, with environment values kept outside the source repository. It is exposed on the local network through a Caddy reverse-proxy route.

The screens above use generated sample names, locations, and profile images. They illustrate the application’s workflow, not real employee data.

Different problems.
The same curiosity.

Back to selected work