Mach9 Replaces Founder-Run FileZilla Deliveries With Files.com S3 Syncs

Mach9 builds AI software that turns mobile LiDAR scans into finished engineering deliverables. Its product, Digital Surveyor, reads the point clouds collected by scan vehicles and extracts the curbs, paint lines, utility poles, and signs that surveying teams used to trace by hand, then exports them to AutoCAD, Microstation, or an Esri feature service. Founded by researchers from Carnegie Mellon's Robotics Institute, the company serves state departments of transportation and national engineering firms, automating mapping work traditionally done by hand.

The raw material is enormous. A mobile mapping run produces terabytes of LiDAR and imagery, and Digital Surveyor ingests data from scanner makers, so files arrive in whatever form a counterparty's hardware produces. All of Mach9's processing ran on its own AWS platform. So the company's entire business depended on moving very large files between its own S3 storage and outside organizations it did not control. Mach9's production storage and its client-facing exchange were two systems joined by a human, and the join cost more with every client signed.

Terabytes in S3, Delivered by Hand

The production side worked. Raw datasets sat zipped in S3, where Mach9's pipeline processed them. The exchange side did not. When a dataset had to go out to a client, someone at Mach9—in practice co-founder Michael Mong, who administered the whole estate—downloaded the zip from the bucket to his own machine and re-uploaded it through FileZilla to the endpoint the client could reach.

That was a person hand-carrying terabyte-class files between two systems, on every delivery. Each transfer tied up a founder's time and bandwidth, and a delivery could not start until someone was free to move it.

An AWS Org That Could Not Move Its Storage

The obvious fixes did not fit. Mach9 could not relocate production data onto a transfer platform's storage: the processing pipeline was built on S3, and the company described itself flatly as an AWS org. It could not push the problem onto its counterparties either. Surveying firms and public agencies sent and received data as-is, in their own formats, and an early-stage relationship did not survive being asked to adopt someone else's tooling.

“For more developmental or early relationships with customers, they just want to send us the data as is without going through our specific export formats.”

Meanwhile, the exchange already carried multi-terabyte volumes across dozens of outside firms: national engineering companies, scanner OEMs, and state transportation agencies, each with its own scoped folder and login. What Mach9 needed was an exchange layer that gave every counterparty a simple folder reachable in a browser or over SFTP, and that reached into S3 natively on the other side. Native S3 integration was, in Mong's telling, the reason he chose Files.com in the first place.

A Three-Click Connection to Production Storage

Mach9 connected its S3 buckets to Files.com using Remote Servers, a credential handoff Mong described as a three-click setup. The bucket contents appeared as folders inside the Files.com site, while the source files remained in S3. Files.com could work against the storage Mach9 already ran rather than requiring a production data migration.

On top of that connection, a Files.com sync now copies ready datasets from S3 into the scoped folder of the receiving client. The first delivery sync was built for a national engineering firm, whose Files.com user now downloads in a browser or over SFTP. Nothing changes on the counterparty's side: same folder, same login, no visibility into the storage behind it. What changed is who does the carrying.

What a Delivery Takes Now

With the S3 connection in production, Mach9 replaced a delivery path that ran through one person's laptop with a sync between two systems. Production datasets now reach the client's folder with nobody downloading and re-uploading them, removing FileZilla and the founder-operated shuttle from the path.

Because the bucket is already connected, standing up the next delivery means defining another sync—not creating a new manual routine that grows with the client list. The pattern that replaced the shuttle applies to every delivery that follows.

The Storage Stayed Put

Mach9 is still an AWS org. The processing pipeline runs where it always ran, the raw zips land in the same buckets, and nothing about the production architecture bent to accommodate a transfer product. What changed is the seam: a delivery used to begin with a co-founder pulling terabytes out of S3 by hand, and now it begins with the file already moving toward the client's folder on its own.

That is the takeaway for any company whose product runs on S3 and whose deliverables have to leave it. Mach9 never faced a choice between where its data lives and how it moves. Files.com connected to the storage instead of replacing it, and the manual work between the two disappeared.