Digitising a City’s Waste Weighbridges: The DSCC Waste Management System

In short: For years, Dhaka South City Corporation had no dependable way to prove how much waste its contractors actually delivered — the record lived on paper slips and in memory. Algoramming Systems Ltd. replaced that with the DSCC Waste Management System (DSCC WMS): an offline-first platform that captures every weighing straight from the weighbridge scale, prints a tamper-resistant slip on the spot, and rolls each record up into auditable, per-client statements the corporation can reconcile its contractors against. It runs on the transfer-station floor and in the management office at once, keeps working when the internet does not, and enforces who-can-do-what at the database layer rather than in the interface. A single Flutter codebase serves five staff roles across desktop and mobile, in English and Bengali. The result is a paper-and-clipboard process turned into a verifiable digital record for a city of millions.

The business problem

Dhaka South City Corporation moves an enormous volume of waste every single day. That waste travels from wards and zones across the city to transfer stations, where trucks are weighed, unloaded, and weighed again. For years the record of what came in, from whom, on which vehicle, and how heavy it was, lived on paper slips and in memory. Paper does not reconcile. It gets lost, it gets rewritten, and it gives a city no reliable way to answer a simple question: how much waste did this contractor actually deliver last month, and can we prove it?

The corporation needed to replace that process with something trustworthy. The requirements were unusually demanding for a piece of municipal software:

• It had to work with no internet. Transfer stations sit at the edge of the network. A system that stops when connectivity drops is worse than paper, because paper never goes offline.
• It had to read the physical scale directly. A weight that an operator types by hand is a weight that can be fudged. The number had to come from the weighbridge itself.
• It had to produce a physical, tamper-resistant slip at the moment of weighing, so the driver leaves with proof and the corporation keeps a matching record.
• It had to stop a single operator from quietly editing a weight after the fact, without blocking legitimate corrections.
• It had to run on the hardware the city already owns, which meant Windows desktops on the weighbridge floor as well as phones and tablets for supervisors.
• It had to give management a clean, exportable statement per client, because those statements are what the corporation reconciles its contractors against.

This is not a content app or a dashboard. It is an operational system that sits between a truck, a scale, a printer, and a government's books — a chain in which every link has to hold. If any single point in that chain is unreliable, the whole record is worthless, and a city loses its ability to hold contractors to account.

Problem, approach, outcome

• The problem. Dhaka South City Corporation's weighbridge records lived on paper and in memory, leaving the city with no reliable way to prove how much waste a contractor actually delivered. The setting was hostile to easy fixes: transfer stations sit at the edge of the network, run on Windows PCs and phones the city already owns, and are staffed by people at very different levels of trust — from field operators to owners.
• The approach. Capture the weight from the scale itself, commit every record to an encrypted local database before the network is ever involved, and let PowerSync reconcile with Supabase in the background. Make integrity a property of the data — a live-read weight field, net computed from gross minus tare, a controlled edit window, and roles enforced at the database layer — rather than something the interface merely hides.
• The outcome. Every weighing now carries a matching physical slip and digital record that reconciles cleanly per client. The station never stops for the network, silent tampering is blocked while honest corrections stay possible, and access is a property of the system rather than a hidden button — all on the hardware the city already runs.

The solution: one platform, three faces

Algoramming delivered the DSCC WMS as a single Flutter codebase that behaves like a different product for each kind of user, all backed by the same encrypted local database and the same cloud. One architectural decision shapes everything else: the record is read from the scale and committed locally before anything touches the network — which is what makes the number both trustworthy and outage-proof. In practice, it is one ecosystem with three faces:

• The weighbridge capture app runs on the transfer-station PC. This is where Operators stand next to the scale, pull the live weight, and print the slip.
• The management portal is the same application seen through an Owner, Admin, or Manager account. Here staff manage the master data (clients and vehicles), review the full wastage book, generate statements, and administer users.
• The customer and rider layer is the data spine that connects everyone: every client is a paying customer or tender holder whose deliveries are tracked, and every vehicle carries a rider or driver whose trips are recorded against a registration number. That layer is what turns individual weighings into an accountable, per-customer history.

Architecture: local-first, cloud-synced

The foundation of the whole system is a deliberate decision: the app talks to a local database, never directly to the cloud in the critical path. Every screen reads from and writes to an on-device SQLite database. PowerSync then handles the two-way sync between that local database and Supabase Postgres in the background.

This is what makes the platform usable at a transfer station. When a truck is on the scale and the network is down, the operator does not know or care. The weighing is saved locally in milliseconds, the slip prints from the local record, and the row quietly uploads later when connectivity returns. There is no spinner, no failed request, no lost weighing.

A few engineering choices are worth calling out, because they are the difference between a demo and a system a city can trust:

• The local database is encrypted at rest. The app bundles SQLite3MultipleCiphers instead of stock SQLite, so the entire on-device store is encrypted with a cipher key. A lost or stolen transfer-station laptop does not leak the city's records.
• Sign-out wipes the device. When a user signs out, the local database is disconnected and cleared, so a shared weighbridge PC does not carry one operator's synced data into the next operator's session.
• The database is also the security boundary. Access is not enforced only in the interface. Supabase Row-Level Security and PowerSync sync rules decide, per role, which rows a device is even allowed to download. An Operator's device only ever receives the weighings that operator created, and only from a defined cutoff date forward, which keeps field devices lean.
• A custom sync gate covers first load. Every page is wrapped in a guard that shows a friendly syncing screen until the local database has caught up, so the app never renders half-populated data on a fresh install.

The heart of it: weighing a truck

The core transaction in the whole system is a single weighing event, called a wastage record. Watching one happen end to end is the clearest way to understand the product.

1. The truck arrives and the operator identifies it. In the capture screen the operator selects the client, which the system calls the Tender Id, and the vehicle by its registration number. Both fields use type-ahead search against the local database, so selection is fast even with thousands of vehicles on file. Choosing the vehicle auto-fills its ward and zone, because those belong to the vehicle's record.

2. The scale, not the operator, provides the weight. The truck sits on the weighbridge. The app opens the scale's serial port at 9600 baud and listens to the byte stream. The scale wraps each reading between two control characters, so the parser waits for a start marker, reads until the end marker, strips out any non-numeric noise, and scales the raw number into kilograms based on the unit the scale reports. That live gross weight streams straight into a weight field that ordinary operators cannot type into. Only elevated roles can hand-enter a value, and even then it is the exception, not the rule.

3. The system computes net garbage automatically. The value on the scale is the gross weight, truck plus load. The vehicle's own tare weight is already stored against its record. The app subtracts the two to get the net garbage weight, and it refuses to save a weighing lighter than the vehicle's own tare, which catches an obvious class of bad readings before they ever reach the database.

4. The record is saved locally and, if configured, held for review. Here the double-check workflow comes in, and it is one of the most important business rules in the system. When double-check is enabled, a new weighing is saved with an unconfirmed status and no slip is printed yet. The record sits in a pending state, visibly flagged as temporary, until someone confirms it.

5. Confirmation prints the slip inside a controlled window. An operator can confirm and print a pending weighing, but only between five and thirty minutes after it was created. Too soon is blocked, too late is blocked, and an already-confirmed slip cannot be reprinted by an operator at all. That single rule, expressed in a few lines of code, is what prevents the two abuses a manual weighbridge is prone to: printing before the truck has settled, and quietly rewriting a weight hours later. Legitimate corrections stay possible; silent tampering does not.

6. The slip prints over the network. Confirmation sends an 80mm receipt to a network thermal printer using the ESC/POS protocol. The slip carries the corporation's name, the Tender Id, the vehicle registration number, the garbage collected in kilograms, the ward and zone, a timestamp, and a footer. The driver leaves with a printed record that matches the digital one exactly.

A subtle but important design decision sits under all of this: the weighing record stores its own snapshot of the client and vehicle details at the moment it is written. If a client's name or a vehicle's ward changes later, historical slips and statements do not silently change with them. The record is a photograph of that moment, which is exactly what an auditable system needs.

From weighings to accountable statements

Individual weighings only matter if they roll up into something the corporation can reconcile. That is the job of the wastage book and the statement generator.

The wastage book is the full ledger of weighings, filterable by client, by vehicle, and by date. From there, staff generate a wastage statement for a chosen client set over any date range, as a PDF or an Excel file. Two rules make these statements trustworthy:

• Only confirmed weighings are included. Pending or unconfirmed records are filtered out, so a statement never bills for a weighing that was never verified.
• Totals are computed in both kilograms and tonnes, which is how the corporation and its contractors actually talk about volume.

Because a statement can span thousands of records, the generation runs in a background isolate rather than on the interface thread. On the web, where isolates are not available, it falls back gracefully to the main thread. Either way, the person generating a month-end statement never watches the app freeze.

The five roles and why they live in the database

The DSCC WMS recognises five roles: Owner, Admin, Manager, Operator, and Dispose. What matters is not that these roles exist, but that they are enforced at the layer that cannot be bypassed.

• Owner has full reach, including a live SQL console for direct database inspection.
• Admin and Manager run the portal: master data, the wastage book, statements, and user administration.
• Operator is the field role. Operators capture weighings and work with clients and vehicles, but they cannot see the global wastage book or administer other users, and their devices only ever sync their own recent records.
• Dispose is a deliberately locked-down role, effectively a decommissioned account that can reach almost nothing.

Every one of these boundaries is expressed twice: once in the interface, so people only see what they should, and once in the database through Row-Level Security policies and PowerSync sync rules, so a device physically cannot download or write rows it is not entitled to. That belt-and-braces approach is what makes the access model defensible rather than cosmetic.

Engineering challenges worth telling

The interesting problems in this project were all at the seams, where software meets hardware, an unreliable network, or a real government's expectations.

Two apps, one physical scale

Problem. A transfer station often runs two builds of the platform on the same Windows PC at the same time, an Outside build and a sister Inside build. But a serial port is exclusive: only one process can hold the scale at once, so the two apps could not both read the weighbridge.

Approach. Rather than rewrite the apps to fight over the port, Algoramming solved it at the operating-system level. A signed virtual-null-modem driver creates paired COM ports, and a small multiplexer, installed as an auto-restarting Windows service, copies every byte from the one real scale port to two virtual ports. The Outside app reads one virtual port, the Inside app reads the other, and neither app needed a single line of code changed.

Outcome. Both apps show the same live weight at the same time. The setup survives a reboot and survives one app crashing, because the other keeps reading its own clean copy of the scale feed. It is the right trade-off for a fixed-purpose weighbridge PC where the city's IT team controls the machine image.

Making the weighbridge database fast on cheap hardware

Problem. Field devices are modest, and a transfer station accumulates thousands of weighings. PowerSync creates its local tables with only a primary key, which meant every query that filtered by operator, client, or vehicle, and every list sorted by date, was scanning the entire table. The dashboard made it worse by running four separate aggregation queries on every refresh, and debug logging serialised entire result sets on every query in both debug and release builds.

Approach. Algoramming added targeted SQLite indexes to the hot columns, declared in the schema so they are created automatically when the database opens, with no migration script to run on live devices. The most valuable is a composite index on operator plus creation date, which lets an operator's own list resolve as a single index seek instead of a scan followed by a sort. The four dashboard aggregations were collapsed into one query using conditional sums, and the heavy logging was gated behind a compile-time flag so it is stripped entirely from production builds.

Outcome. A dashboard refresh now runs two queries instead of five, hot lists resolve as index seeks rather than table scans, and logging costs nothing in release. This was the single biggest performance win in the project on the hardware the app actually runs on.

Syncing only what a field device needs

Problem. Left unbounded, an operator's device would try to pull an ever-growing history of weighings, which slows initial sync and wastes storage on modest field devices. PowerSync's sync rules cannot express "the last five hundred records," because rules are evaluated one row at a time.

Approach. The pragmatic fix was a date cutoff in the operator's sync bucket, so field devices only download recent weighings rather than the entire history. The cutoff can be moved forward with a small change when needed.

Outcome. Operator devices stay lean and initial sync stays fast, while Owner, Admin, and Manager accounts still receive the full record for reporting.

Normalising messy real-world master data

Problem. The vehicle master data arrived as spreadsheets full of the inconsistencies real operations produce: capacities recorded in tonnes where kilograms were expected, tare weights left as placeholders, and phone numbers missing a leading zero. Bad master data would quietly corrupt every net-weight calculation downstream.

Approach. Algoramming built a CSV and Excel importer that cleans as it ingests, and wrote a careful set of database migrations to backfill and correct historical rows, each one with a preview step so a human could eyeball exactly what would change before committing. Those migrations also renamed the core weight field and derived a proper net-versus-gross model, coordinated so the app update shipped before the schema change to avoid breaking live devices mid-sync.

Outcome. Historical records were corrected without downtime or data loss, and the net garbage weight on every new weighing is computed from clean, consistent tare values.

Built to run everywhere the city works

The platform is a single Flutter codebase that ships to Windows, Android, iOS, macOS, Linux, and the web. Windows is packaged as an auto-updating MSIX installer, which matters because the weighbridge PCs need to update themselves without an IT visit. The web build gracefully drops the features that make no sense in a browser, such as direct scale and printer access, and the whole interface is fully bilingual in English and Bengali, with a bundled Bengali font so the corporation's staff can work in the language they actually use.

Results

The platform changed what the corporation can prove, not just how it works. A weighing floor that once ran on paper now produces a record that stands up to reconciliation, survives a network outage, and cannot be quietly rewritten — in concrete terms:

• Weighings are captured from the scale, not from memory. The number on the slip is the number on the weighbridge, computed as net garbage automatically, which removes an entire category of human error and dispute.
• The transfer station never stops for the network. Because the app is offline-first, an internet outage is invisible to the operator, and every record still syncs to the cloud when the connection returns.
• Every weighing has a matching physical and digital record, printed at the moment of confirmation, with a controlled edit window that allows honest corrections and blocks silent tampering.
• Management gets reconcilable, per-client statements in PDF and Excel over any date range, generated without freezing the app, and containing only confirmed weighings.
• Access is enforced where it counts. Five roles are constrained at the database layer, so what a device can see and do is a property of the system, not a hidden button.
• The platform runs on the hardware the city already owns, across desktop and mobile, in the language its people speak.

Tech stack

Client: Flutter and Dart, one codebase across Windows, Android, iOS, macOS, Linux, and web. State management with Riverpod, local settings in Hive, navigation with Beamer.

Data and sync: PowerSync as the local-first sync engine, an on-device SQLite database encrypted with SQLite3MultipleCiphers, syncing to Supabase Postgres. Access control through Supabase Auth, Row-Level Security policies, and PowerSync sync rules.

Hardware integration: RS-232 serial weight-scale reading over the serial port, network thermal printing over the ESC/POS protocol, plus a virtual-COM-port multiplexer at the OS level to share one scale between two apps.

Documents and media: PDF and Excel statement generation in a background isolate, image handling and avatars in Supabase Storage.

Key takeaways

• Offline-first is not a feature, it is the architecture. Building the app around a local encrypted database with background sync is what makes it dependable at the edge of the network, where a waste transfer station actually lives.
• Trust comes from the seams. Reading the scale directly, computing net from gross and tare, and enforcing a controlled edit window are small pieces of logic that carry most of the system's integrity.
• Put access control in the database, not the interface. Row-Level Security and sync rules make the role model a property of the system rather than a suggestion.
• Respect the hardware the client already runs. Sharing one physical scale between two apps at the operating-system level, and shipping an auto-updating Windows installer, meant the software fit the city's reality instead of asking the city to change for the software.
• Performance on cheap field devices is a design goal. Targeted indexes, collapsed aggregations, and bounded sync are what keep the app fast on the machines it actually runs on.

Algoramming Systems Ltd. builds offline-first, hardware-integrated software for operations that cannot afford to stop. If you are digitising a weighbridge, a warehouse, a field operation, or any process where the network is unreliable and the record has to be trusted, get in touch with Algoramming.