← All Python Projects

Python Project

Cleaning Service Tracker

pythonreactfastapisqlalchemyaiogram

How It Started

This project started when my mom was working as a cleaning supervisor. Every month she had to manually calculate wages for all workers, and the challenge was that her final sum had to match the CEO's total and each individual worker's self-reported earnings. In practice, it almost never lined up on the first try. Someone would forget a $30 bonus, or write down the wrong amount for a house. Tracking down those discrepancies took her 8 to 10 hours every reporting cycle, delaying final numbers and pushing back everyone's paychecks. One day I stepped in to help. The goal was clear: reduce that 8-10 hour process to something manageable. I built a centralized tracking system where workers could log their own records and supervisors could view, verify and report on everything from one place, cutting that process down from a full day's work to a matter of minutes.

Functionality

Throughout the brainstorming process I kept two things in mind: logging a record had to be as fast as possible, and the solution had to be simple enough for workers who were not particularly tech-savyy. Web application could work, but it would require teaching everyone how to log in, where to click, and remember to use it consistently. Creating a standalone application would probably be a bit less painful for everyone, but it felt like overkill for the problem at hand.

The solution was hiding in the chat messenger. Telegram was already the company's primary communication tool because everyone had it, and everyone used it daily. I had prior experience building Telegram bots, so the path was clear. Worker would simply open the chat with chatbot, and send a single line: house number - price. Right after finishing the job, before even leaving the property they could log it in seconds. This approach wins over the regular writing on paper, as it's quicker, stored in one place, and feedback can be instant. Win-win for both sides. The moment record is submitted, the supervisor receives an instant noitification that the house was cleaned, so there is real-time visibility into the day's progress.

The system grew from there. At first, it was only admin who could view the records and totals. With the next update, workers gained access to their own stats: total earned, houses completed, and similar. Later, a full web-based admin panel was built alongside the bot to handle everything in one place: earnings breakdowns, long-term statistics, user management, record management, and customizable report generation. Admins could request fully customized reports exported as Excel files, sent directly to their Telegram chat.The interface supports both English and Ukraininan throughout.

Functionality imageFunctionality imageFunctionality imageFunctionality imageFunctionality imageFunctionality image

Tech Stack and Approach

The Telegram bot was built using aiogram, a Python library for the Telegram Bot API. When a worker submits a record, the bot validates the format, pushes the entry to the database, and sends a notification to the admin group confirming the new record including the worker's username, house number, and price. This gives the admin real-time visibility and an easy way to catch mistakes like incorrect amounts or unrecognized house numbers.

Both workers and admins can request reports directly through the bot: workers see only their own records, while admins can pull individual or full-team summaries delivered as formatted messages. The admin panel is a React JS web application backed by a FastAPI (Python) REST API, with SQLite as the database. Data flows between the frontend and backend through a clean API layer. The application is deployed on a cloud VPS, served securely over HTTPS with a custom domain.

One of the more interesting technical decisions was authentication. Rather than managing a separate login system, the admin panel authenticates through Telegram itself. When the admin opens the panel, a request is sent to Telegram to verify the user's identity so access is not controlled by a simple flag or hardcoded ID, but confirmed by Telegram directly. A JWT token is then issued for the session. This offloads security to a trusted third party and eliminates the need to manage passwords entirely.

Challenges and Learning Experience

Several meaningful challenges came up across the project.

  • The most significant early barrier was security, specifically, ensuring the admin panel was properly locked down before going live. Implementing Telegram-based authentication with JWT was something new, and getting it right required careful research into how Telegram's authentication flow works and how to validate it server-side without trusting the client.

  • Deploying to a production server for the first time brought its own learning curve: configuring a reverse proxy, setting up secure HTTPS, and managing a live environment where mistakes have real consequences.

  • Testing on an actual iPhone rather than a browser emulator also surfaced issues that wouldn't have appeared otherwise: network-level errors from a real device, and a range of IOS-specific behaviours around keyboard types, native date pickers, and layout constraints that each required deliberate solutions.

  • As the dataset grew over time, client-side filtering became a bottleneck. Migrating to server-side filtering with cursor-based pagination was a deliberate architectural decision to keep the app performant long term.

  • Database migration on a live system was another first. Adding new columns without disrupting existing data sounds like a straightforward process, but when real users depend on the system staying up, you want everything right on the first attempt.

Overall, this was the first project I took from an idea all the way to a live production environment with real users depending on it, and that shift in responsibility changed how I approached every decision, from code quality to deployment to user experience.

Conclusion

This project represented a full product development cycle: from sitting down with the client to understand their daily workflow, all the way to deploying and maintaining a live system they depend on. The most measurable outcome is the time saved: what used to take 8 to 10 hours of manual reconciliation now takes 1 to 2 hours. Yes, sometimes people still make mistakes, as human errors will never go away, but mistakes are now visible the moment they happen, and fixing them takes seconds. What started as a small effort to make my mom's job easier grew into a fully deployed field service management tool, still actively used and supported across the company. The project continues to evolve and there are planned updates on the roadmap, and knowing that real people rely on it every day remains the best motivation to keep improving it.