Background

Two questions come up constantly when running a project team: when will it be done, and how much will it cost. The answer usually comes down to a feeling, because all that gets recorded is which tasks are finished and which are not. The hours actually spent never enter the calculation.

I built MPTI Lab for my university journal research, titled "Implementation of You Only Look Once (YOLO) Technology and Reinforcement Learning for Web-Based Project Monitoring". The starting point was a plain PHP application called Startup Flow, which I audited first. Two findings changed the direction of the work. First, the old monitoring script recorded the screen of the machine running the web server. On localhost that happens to be correct, but installed on a real server it records the server's screen, not the employee's. Second, the YOLO weight files were stored neatly in two locations and never called by a single line of code.

Solution

I moved monitoring to a desktop program that runs on each team member's computer. The agent records the active window title every 60 seconds, holds it in a local outbox when the connection drops, then sends it to the server through a token-authenticated REST API. On the server, each title is matched against rules managed by the Project Manager to decide whether that hour counts as effective.

Those numbers are the input for estimation. One press of the Calculate Estimate button runs a queued job that aggregates the hours, calls a Python service holding a PPO model, then stores the result: the estimated days remaining, total cost against the original budget, a daily allocation plan, and a performance figure for each member. The old system demanded three buttons in sequence with no feedback at all.

Key features

• A desktop agent for Windows, macOS, and Linux X11, installed with a single-use pairing code valid for 24 hours
• A screen recording mode that can be switched off, limited to frames only, or full, with a disk capacity guard and 14-day retention
• Activity classification through 49 extracted rules, a triage page for unrecognised titles, and Naive Bayes as a second layer
• Time and cost estimation with two PPO strategies, complete with calculation history and CSV, Excel, and PDF export
• Member performance scoring from A to E along with a recommended follow-up
• A task flow from in progress, paused, submitted, revised, through to approval by the Project Manager or Team Leader
• Realtime text chat and a voice room, with a bilingual Indonesian and English interface

Technical challenges

The part that took the longest was making the journal figures reproducible. I rewrote the cost formula in both PHP and Python, then locked it with two anchor tests: 14,352,600 for the old system's dataset and 338,929,750 for the journal dataset. The second anchor also settled a long-standing doubt, namely whether pending_cost is added into the total. It is not. The version without pending_cost was only 250 rupiah off the published figure, while the version with it was off by 44 million.

The second problem: the journal's PPO turned out to read a single number, the average task completion rate. Effective hours, delays, and budget were all ignored. I kept that version as legacy_ppo so the journal figures can still be checked, then wrote v2_ppo, which reads all five inputs and produces a daily allocation plan. When the data is too thin and no task has been completed yet, the estimator deliberately falls back to the old behaviour and flags the result, rather than forcing out a number that merely looks convincing.

Naive Bayes sits as a second layer, not a replacement for the rules. Human-written rules always win, and a model guess with confidence below 0.60 is not used at all. Even accepted guesses still land on the triage page for confirmation, so no label quietly becomes the truth.

On YOLO I took the honest route. I built the object detection pipeline until it worked, then switched it off by default through an env flag. The claim can still be verified by anyone, without forcing every installation to carry hundreds of megabytes of vision dependencies for a feature that is not in use yet.

My role

I did this project alone from scratch to deployment: the Laravel application, the FastAPI service, the Python desktop agent, the Docker configuration, deployment to Coolify with four processes in one container (nginx with php-fpm, the queue worker, the scheduler, and Reverb), a CI pipeline on GitHub Actions, 65 Pest test files covering 684 cases plus pytest for the ml-service and the agent, and the documentation in the form of a PRD, decision notes, and a changelog.

Results and what comes next

The system is deployed and in use. The journal figures can be reproduced through tests, and the flow runs end to end, from the agent on a member's computer to a report ready for export.

Some things remain open. YOLO is not enabled by default, Linux Wayland is unsupported because there is no equivalent window title API, and the duration cap for long pauses is still disabled to preserve parity with the published figures. Estimation also requires the queue worker to stay alive. Next I want to add scheduled retraining for the classifier, and a trend chart of estimates over time so shifts in the forecast are visible, not just the latest number.