Muzaini Autoworks

The operational problem

An independent automotive workshop was running its day-to-day operations through a mix of paper job cards, manual ledgers, and disconnected records. Customer and vehicle history was hard to retrieve, parts usage was tracked inconsistently, and reconciling invoices, payments, and end-of-day totals took significant manual effort at the close of each business day.

The workshop needed a single system that could follow a vehicle through its entire lifecycle at the shop — from check-in and inspection through to technician work, parts, checkout, billing, and collection — while keeping an auditable record of who did what, and when.

My role

I owned the project end to end: studying the workshop's actual workflow, defining the requirements and role structure, designing the interface, building the application, and preparing it for deployment on the workshop's own hardware.

• Process mapping and requirements definition
• Interface design and the light/dark theme system
• Backend development, data modelling, and business logic
• Role-based access control and audit trails
• Windows packaging, installer, and deployment
• Backup tooling and operational documentation

How I mapped the workflow

Rather than imposing a generic structure, I modelled the system directly on the workshop's real job-card lifecycle. Every status the workshop already understood became a first-class state in the software, with rules about what could and could not happen at each stage.

Check-in → Inspection → Approval & Work → Quality Check → Checkout & Invoice → Payment → Collection

I defined four roles — administrator, manager, front desk, and technician — each with access scoped to the parts of the workflow they actually use. Technicians see only their assigned job cards; front desk handles intake, billing, and collection; inventory and purchasing are restricted to authorised roles. The authorisation boundary is enforced on the server, not just by hiding UI.

Major technical & product decisions

A movement-based inventory ledger

Instead of storing a single "current stock" number, every stock change is recorded as a movement — opening balance, direct receive, purchase receipt, job usage, usage reversal, and adjustments in and out. Stock on hand is calculated from the ledger. This makes part usage auditable and allows cancelled jobs to return parts to stock through traceable reversal records.

Connected billing, not isolated invoices

The billing flow is a direct progression: job services and part usage lead to a checkout and billing summary, which produces an invoice, which collects payments, which generates a consolidated receipt once fully paid, which then permits vehicle collection. Each step blocks the next until its preconditions are met, so the workshop cannot accidentally collect a vehicle with an unpaid invoice.

Safe corrections and cancellation

Job details, inspection findings, and even whole job cards can be corrected or cancelled — but only in eligible states, and never in ways that would silently rewrite financial history. Invoices and receipts are preserved as snapshots; cancellations require a reason and return unreversed part usage to stock through auditable movements.

End-of-day reporting built around the business day

Daily Business Reports summarise invoices, payments, outstanding balances, and stock intake for the Kuala Lumpur business day, split across cash, card, e-wallet, bank transfer, and other methods. They can be generated manually or refreshed automatically, and they're print-ready.

Challenges I solved

• Designing cancellation and correction rules that preserve financial audit history without locking the workshop out of legitimate fixes
• Keeping part usage, reversals, and stock-on-hand consistent across concurrent job cards and inventory changes
• Building role-based access that is enforced server-side rather than relying on hiding frontend controls
• Producing print output (job cards, invoices, receipts, reports) that is clean and consistent regardless of the screen theme
• Packaging a Flask/PostgreSQL application into a single-PC Windows installer that a non-technical operator can set up

How it's deployed

The application runs as a local-first Windows program. The Flask application is served by Waitress, PostgreSQL holds the runtime database, and the operator accesses it through a browser on the same machine. The whole stack — application, database, and browser — runs on one workshop PC, with no internet dependency for normal use.

It's packaged with PyInstaller and Inno Setup into a Windows installer that handles first-run database configuration, migration, and administrator creation. A tray application provides restart, backup, log viewing, and update checks. Local PostgreSQL custom-format backups can be created on demand and verified without restoring.

Current status

Muzaini Autoworks is running in production today, handling the workshop's real daily operations across job cards, inventory, purchasing, billing, payments, and reporting. The system continues to evolve as the workshop's needs grow.