A Construction Software Provider Embeds Files.com as Its Customer-Facing SFTP Exchange—Without Building a Second Product

A construction software provider sells a program management platform for capital program owners including universities, health systems, and public agencies.

An owner running its capital program on the provider's software keeps the program's record there: contracts, budgets, invoices, vendors. But the owner's money does not live in that software. It lives in the owner's own ERP, behind the owner's own firewall, on the owner's own schedule. So project and financial data had to cross between the provider's cloud and each customer's environment, in both directions, every day. That crossing was a file exchange, and the provider had to deliver it as a working part of its product.

There was no product to replace here. The alternative was for the provider to build and operate its own multi-tenant SFTP infrastructure: servers, key management, per-customer isolation, logging, and continuous reliability, maintained forever, for every institutional client. That is a second product, staffed alongside the real one.

A File Exchange That Carries Its Customers' Money

The files that move through that exchange are not attachments. At one major research university's facilities department, which runs hundreds of millions of dollars in construction every year, the financial transactions behind that program flow through the provider's drop on Files.com: procurement out, invoicing out, vendor master data out, all of it collected on the far side by SAP.

That is what failure costs. A transfer that does not arrive, a delivery that silently overwrites the one before it, or a pickup nobody can confirm is not an IT ticket. It is an owner whose invoices are not moving and whose vendors are waiting. There is no tolerance for interruption: the exchange has to work, without delays, because every one of those transactions rides on it.

And the provider controlled only one end of it. Each institutional customer connected with its own automated systems and scheduled jobs, on its own key requirements, behind its own security review. Files with identical names landed daily. The traffic ran year round. The provider had to deliver a machine-to-machine exchange reliable enough for a customer's finance operation, into environments it did not manage.

The Transfer Platform the Provider Chose Not to Build

What the exchange had to do was clear before any of it was built. Fence every customer into its own space. Speak the SFTP and FTP their automation already spoke, with public and private key authentication and more than one key per user, because that is what production integrations required. Survive a file arriving every day under the same name. Prove, afterward, that a file was actually collected. And run without interruption.

The provider made Files.com that exchange. Files.com was not a tool the provider used internally. It was a service the provider delivered to its customers.

One Home Directory, One Set of Keys, per Institutional Customer

Files.com gave each institution a home directory visible only to its scheduled jobs, while the provider uploaded under the same client identifiers. One reusable exchange pattern isolated each institutional customer without new infrastructure per client.

Two Files.com behaviors carried the daily grind. Where a customer's system dropped an identically named file every day, Files.com appended a timestamp on upload, so today's delivery could never destroy yesterday's. And the platform's file history recorded uploads, overwrites, downloads, and pickups, so when a customer asked whether a named user or IP actually collected a file, the provider answered from the log.

Many Years on a Single Integration

By mid-2024, that university's integration had run for many years. A daily delivery could not overwrite the one before it, so a whole class of silent data loss was off the table. Whether a file was collected became a lookup, down to the user and the IP, not an investigation.

The immediate result is an exchange the most demanding customers accept and keep using. The compounding one is that every institutional customer since has cost the provider configuration, not construction.

File Exchange as a Product Feature, Not a Second Product

Today, the provider's customers connect to the provider. What they see is a directory that belongs to them, keys their automation holds, and files that arrive and get picked up on schedule, year after year. What they do not see is a file transfer platform that the provider built, because there isn't one. Files.com is the exchange, embedded in the product, and the provider's engineers build construction software instead of operating SFTP infrastructure.