2,400 drivers.
No reliable payday.
No way out.
When your payroll system is a black box you don't own, every week is a risk.
Queens Medallion Leasing runs one of New York City's largest taxi medallion fleets.
Every week, thousands of drivers needed to know what they earned — and what was taken out. Medallion lease fees, EZ-Pass tolls, tickets, repairs. Instead, they were getting a wall of text. No clarity on which charges were theirs. No consistent delivery. And an accounting team spending half their week answering questions that a working system should have answered automatically.
The system nobody could leave
The legacy platform — built on proprietary ASP.NET — had been running QML's fleet operations for years. It handled driver records, medallion assignments, trip logs, toll imports, ticket tracking, and payment exports. On paper, it did everything. In practice, it was a closed box.
"Every report lived behind a browser. There was no API, no database access, no exit path the vendor was willing to hand over."
There was no API. No direct database access. No data export that didn't require a human clicking through a browser. Every report the business needed lived behind authenticated pages, generated on demand via implicit POST requests — the kind of system that was never designed to be integrated with, audited against, or migrated away from.
The vendor had no interest in making an exit easy.
One medallion. Two drivers.
A thousand ways to get it wrong.
The payroll problem wasn't just about getting data out of the legacy system. It was about what to do with it once you had it.
Two drivers, one cab
In New York's taxi industry, a single medallion is typically worked by two drivers in rotation — a main driver and a co-driver sharing the same vehicle across different shifts.
Charges against the medallion
Every toll, ticket, repair, and lease fee attached to that medallion had to be attributed to the right person — based on who was behind the wheel when the charge was incurred.
The system had no concept of this
The legacy platform recorded charges against medallions, not drivers. Reconciliation — figuring out who owed what — happened manually, by people cross-referencing shift logs against charge records line by line.
Lost every week by one person just answering driver inquiries about charges that a working system should have handled automatically.
"Charges were recorded against the medallion. Who actually owed them — that was someone's manual job to figure out."
If there's no door,
you build one.
The only way into the legacy system was through a browser. So that's where the solution started.
Codesushi built a headless browser automation layer using Puppeteer that navigated the legacy platform exactly as a human would — logging in, setting filters, triggering exports, and catching the downloaded files before they hit a desk. Eight separate data sources scraped, converted from XLSX to structured data, and loaded into a purpose-built PostgreSQL database on AWS.
On top of that foundation Codesushi built the reconciliation engine. Every charge matched to the shift it belonged to. Every shift matched to the driver who worked it. Main driver and co-driver correctly separated on a single payslip. The business logic that had previously lived in someone's head — or not lived anywhere at all — was now codified, automated, and running on a schedule.
The output was a clean, itemized PDF payslip — every charge labeled, every deduction explained, main driver and co-driver on the same document each seeing only what was theirs. The system scraped and reconciled daily but delivered once a week, matching QML's actual payroll cycle. No portal, no login — the complete weekly statement landed directly in the driver's inbox. For the accounting team, charges that previously triggered inquiries were now self-explanatory. The 12 to 16 hours Salomi spent weekly fielding ticket and toll questions didn't get reduced. It disappeared.
"For the first time, QML had their own copy of their own data — independent of the vendor, running on infrastructure they controlled."
Before and after.
The same data. A completely different experience.
For years QML's drivers received their weekly statement as a raw data dump — every line item from the legacy system printed in sequence with no grouping, no explanation, and no clear total. A driver looking at their payslip couldn't tell at a glance what their gross earnings were, which toll charges were theirs, or whether the ticket deduction on line 34 happened on their shift or their co-driver's. The document wasn't a payslip. It was an export.
The replacement wasn't just a technical upgrade. It was a different philosophy about what a payslip is for — a document that gives a driver confidence in their number, not questions about it.
The outcome.
A fleet of 2,400 drivers. A financial operations system built from nothing. Running every week without anyone touching it.
Queens Medallion Leasing went from a broken manual process held together by people's time and goodwill, to a fully automated financial operations pipeline running on infrastructure they owned and controlled. The legacy vendor no longer had leverage. The data no longer lived in a black box. And every driver, every week, got a payslip that actually made sense.
Running the same kind of operation?
Whether you're trapped in a legacy system with no exit, or your financial ops are held together by manual effort and goodwill — we've been here before.
Let's talk about your situation