(WEB_PORTAL) Internal Attendance Management Service — The Day We Switched from a Low-Code Prototype to a Full Web Service

Overview

We began building a new hybrid-style attendance and leave management service for internal company use. The requirement was that the available features should differ depending on network location: clock-in/clock-out recording should only be possible from the internal network, while leave requests and lookups should also be available from outside the network.

Initial Approach and Same-Day Pivot

We started with a quick proof of concept using a spreadsheet-based low-code automation tool. However, the limitations of a low-code environment quickly became apparent when it came to handling requirements like network-based access control, login session management, and data consistency. We decided, within the same day, to switch to a proper stack built on a full web framework.

Why We Chose This Stack

• Framework: With built-in API route support, we could combine the frontend and API into a single project without running a separate backend server, which we felt would reduce the burden of initial setup and deployment.
• Database: Rather than standing up a separate DB server on our internal NAS environment, we chose a file-based embedded database that could be deployed alongside the application itself. Given our expected user scale, we judged that the benefits of running an external DB server wouldn't outweigh the cost.
• Session management: We adopted token-based authentication (HttpOnly cookies), which doesn't require maintaining separate server-side state, so that we wouldn't have to worry about session storage even if the deployment environment changed later.

Key Implementation Points

Feature Branching by Network Location

We designed the system to compare the incoming request's IP address against the internal network range to determine whether the request originated from inside or outside the company, and to show or hide specific features (like clock-in/clock-out recording) on screen based on that result.

Receive request → Extract request IP
Is it within the internal range? → Enable attendance-related features
Otherwise → Show only lookup/request-related features

How We Store Time Data

We standardized internal storage to UTC, converting to the company's local time zone only at display time. Storing data in a standard format means that even if the server moves or users in other regions are added later, only the display logic needs to change.

Retrospective

• Quickly validating the core requirements with a low-code tool in just one day actually helped us recognize its limits early — whether it could handle authentication and network segmentation — which let us decide to switch to a proper stack within the first day.
• Not over-engineering the database from the start, and instead choosing a lightweight option that matched our actual usage scale, helped reduce operational burden later on.