A year ago, Wasteer had two live installations. Today we have thirty-plus. Here's what the engineering looked like on the way there.
What scaled without modification
The inference pipeline. The YOLO inference architecture was designed for horizontal scaling from the start. Adding an installation means provisioning the edge hardware, deploying the model, and connecting it to the data pipeline. The per-installation setup time has come down from about a day to about two hours. The core inference code hasn't changed.
The data pipeline. Raw inferences from each installation flow into a central processing layer that aggregates, stores, and serves the data to the application layer. We built this with multi-tenancy from day one: each client's data is isolated, the processing is shared. The architecture handled thirty times the data volume without structural changes.
The alerting system. Fill-level alerts, anomaly notifications, maintenance triggers: the alerting logic was built generically enough that new installation types required configuration, not code changes.
What didn't scale
Installation onboarding. For the first ten installations, onboarding was a manual process: someone from the team drove to the site, mounted the camera, ran the calibration, confirmed it was working. This was fine at ten. At thirty it's a bottleneck. We've built remote onboarding tooling that handles most of the process with an on-site contact who doesn't need to be a technician. It works. We should have built it earlier.
Per-installation monitoring. At two installations, you can watch dashboards. At thirty, you can't. We didn't have automated anomaly detection on the installation health metrics (camera availability, inference latency, data freshness) until we were at twenty installations. Before that we found problems when clients reported them. That's too slow.
The model update process. Updating the model across thirty installations at different hardware specs in different connectivity environments is more complex than updating it across two. We're managing it now with a staged rollout system. The staged rollout was built reactively, not proactively.
The pattern
Scale reveals the things you built for yourself. Manual onboarding, manual monitoring, manual model updates: all of these worked when the team had hands-on contact with every installation. They break when the number of installations exceeds what the team can track manually.
The discipline is to ask, for each manual process: what's the breaking point? At what number of installations does this process stop working? Then build the automation before you hit that number, not after.
We hit the number before building the automation on two of the three processes above. Thirty installations was where it became urgent. We should have built for a hundred when we were at ten.
Where we are
The infrastructure now supports the growth plan. The roadmap to a hundred installations is clearer than the roadmap to thirty was. Each operational problem we hit and solved at thirty has been systematically addressed. The next problems will be different ones.
With gusto, Fatih.