A second printer doubles your output. A tenth one does not. Somewhere past a handful of machines the constraint stops being print speed and becomes everything around it — who slices the files, which machine is free, which one failed at three in the morning and spent six hours extruding into open air, whether there is filament left on the spool, and who is going to pull four hundred parts off beds and finish them.
Most businesses discover this after buying the machines. The farms we build are the answer to the problem that follows.
What we built
A farm is mostly software and process wearing a rack of hardware. The physical layer comes first and is the least glamorous part of it: racking and airflow, stable ambient temperature, filament kept genuinely dry, resin handled and vented properly, and power distributed so thirty machines are not sitting on one hopeful circuit.
Above that sits the thing that makes it a farm rather than a room of printers. Jobs go to a queue, not to a machine. A scheduler assigns work by capability, by what material is already loaded and by what is actually free, so operators stop playing Tetris with a spreadsheet and nobody walks a file to a USB stick.
Every printer carries a camera and reports telemetry. Spaghetti, bed adhesion loss and filament run-out are detected in minutes, the job is stopped and re-queued automatically, and the machine goes back into rotation — instead of the failure being discovered the following morning along with the wasted material.
Underneath it all runs the accounting nobody sets up and everybody needs: spool and resin tracking by batch, consumption per job, machine hours, failure rate by printer, and a true cost per part. Quoting becomes arithmetic instead of instinct, and it becomes obvious which machine is quietly losing money.
How it is engineered
Printers are brought under one control plane regardless of make, with per-machine telemetry streamed rather than polled, so the dashboard reflects the farm as it is rather than as it was a minute ago. The scheduler is the interesting part: it has to understand that machines are not interchangeable, that a material change costs time, and that an urgent small job should not wait behind an eighteen-hour build.
Failure detection runs vision inference on the camera feeds close to the machines, so a farm does not depend on an uplink to notice it is wasting filament. Detections are deliberately tuned to over-report slightly — a false stop costs minutes, a missed failure costs a night.
Everything lands in Postgres behind a dashboard built for the person walking the floor, not for a screenshot: what is printing, what failed, what needs material, what is due.
What it took
The hard lesson was that uniformity is a trap. The instinct when building a farm is to buy thirty identical machines, and it is almost always wrong — the right mix is usually several types, because part geometry and material vary far more than machine specifications do. We size farms against the client’s own files now, not against a catalogue.
The second lesson was that a farm is only as good as its worst routine. Calibration, maintenance and material handling decide throughput more than machine choice, so the handover is documentation and drilled routine as much as it is hardware.
We run our own farm, which is why the design is not theoretical. Most of what we steer clients away from is something we got wrong on ours first.
This case study describes work in active development.