Build vs Buy for File Transfer, Asked Honestly

"We should just buy a proper transfer product." "We have a proper transfer system. I wrote it." It is Monday morning, in a hallway, and a scheduled script failed over the weekend. Or an auditor asked a question nobody could answer quickly. Or a new partner arrived with requirements the current setup strains to meet. The first speaker has a bad weekend behind them. The second has five years of invoices quietly delivered and would like that noted. Both are right, and they will now spend an hour arguing past each other. Each is answering a different question. I have been both people, occasionally in the same week.

Our Build vs Buy series is an attempt to referee that argument properly. That begins with admitting it is the wrong argument. This opening article reframes the question so it can be decided at all: not "build or buy?" but "which parts, for which flows, given this team?" The rest of the series argues each side at full strength. It covers the genuine case for homegrown scripts, the costs that hide in them, what dedicated tools actually add, and a worksheet for finding your own tipping point. It finishes with how to move between the models without regret.

One thing must be said before any of it, because it colors everything: Sysax sells transfer software. We are a vendor writing about whether you should buy from vendors, which is roughly a barber writing about whether you need a haircut. We think the analysis below survives that bias — it recommends keeping your scripts in several common situations. But you should discount our enthusiasm accordingly and check the reasoning rather than the conclusions. Notice that the strongest article in this series is deliberately the one arguing against us.

The Argument Everyone Has, and Why It Stalls

Listen to the hallway argument carefully and you will hear two sets of true statements colliding. Nobody in it is wrong, which is why it never ends.

The script author's claims are real. The scripts fit the business exactly, because they were written against the business rather than adapted to it. They cost nothing to license. Every line is readable, changeable, and owned. When the partner renames a folder on a Tuesday, the fix ships Tuesday afternoon — no ticket, no release cycle, no waiting on anyone. The team's scripting skill grew while building them and now pays dividends everywhere else. All of this is true, and we argue it at full strength in the build case.

The buyer's claims are also real. The scripts have one author, and the author has one resignation letter in them. Nobody else can answer for the system in an audit. Retry logic, alerting, and credential handling were each built once, badly, under deadline, and never revisited. Every new flow costs a bespoke build instead of a form fill. The hours spent nursing the estate are invisible because nobody tracks them. All of this is true too, and it gets its own fair hearing in the hidden-costs article.

The argument stalls because both parties treat these as opposing answers to one question. They are not. They are correct answers to different questions. "Is a well-fitted script excellent at moving this file?" Yes. "Is a pile of well-fitted scripts an operable, auditable, survivable system?" That depends on facts about your team and your flows that neither debater has put on the table. Until those facts are on the table, the argument is a taste contest. Taste contests are won by whoever has more organizational weight, which is a terrible way to design infrastructure. Org charts make poor load-bearing walls.

You Are Already Doing Both

Nobody builds transfer infrastructure from scratch, and nobody buys all of it, and that observation dissolves the binary. The most defiantly homegrown setup in the world is already a tower of bought and borrowed components. It includes an operating system someone else maintains and an SSH implementation someone else patches. It includes a scheduler someone else wrote and network gear someone else firmware-updates. The script author did not implement the file transfer protocol; they composed tools that did. Meanwhile, the most product-committed shop still writes glue — a renaming step here, a pre-send validation there — because no product anticipates everything. Ours included; we have the feature requests to prove it.

The real question was never build versus buy. It is: at which layer does your building stop? Everyone draws that line somewhere. The hallway argument is actually a disagreement about where the line belongs. Once you see that, you can argue about the line layer by layer. That is a discussion facts can settle.

The Which-Parts Reframe

Transfer infrastructure separates into distinct capability layers, and the build-or-buy answer can differ at every one. The table below names the layers and what each choice looks like there. (For the fuller picture of how commercial suites bundle these layers, see the managed file transfer pillar; here we only need the separation.)

Run down the right-hand column and a pattern appears: the deciding factors are almost never technical. They are facts about consequence, headcount, growth, and outside scrutiny. That is why the hallway argument between two technologists stalls — the missing evidence is organizational, and neither debater brought it.

The reframe also legitimizes mixed answers, which is where many healthy estates land. Buying one layer while building another is not indecision; it is precision. A team might run a bought server for partner-facing accounts. This is where a product such as Sysax Multi Server typically enters an estate, handling SFTP and FTPS endpoints, per-account authentication, and activity logging. Meanwhile, the team's own scripts might continue to drive internal collection and validation. That layer is where the scripts' exact fit earns its keep. The reverse mix exists too: homegrown server-side landing zones with a bought automation client doing the scheduled moving. Per-layer, per-flow decisions like these outlive ideological ones.

The Two Cost Shapes

The second reframe is about time. Build and buy do not just cost different amounts; they cost in different shapes. Most bad decisions come from comparing a snapshot when the real difference is the curve.

Building is cheap to start and accumulates cost. The first script costs an afternoon. But each flow added, each partner onboarded, and each year passed adds care. There are failures to triage, changes to absorb, credentials to rotate, questions to answer, knowledge to transfer. The slope is gentle when flows are few and stable, steeper as they multiply. The cost arrives diffusely, as nobody's line item, which is why it goes unmeasured until someone finally counts it. The drip has never once appeared on a purchase order.

Buying is expensive to start and flattens. Adoption is a visible step — license spend, migration effort, learning the tool. That is exactly why it triggers scrutiny that the drip of script maintenance never faces. After the step, adding a flow costs a configuration exercise rather than a build. In an automation tool like our Sysax FTP Automation, that is a wizard-defined task that arrives with scheduling, retry, and failure notification already attached. The vendor carries the protocol patching and feature upkeep. The line never reaches zero: license renewals recur, upgrades take occasional projects, and the tool itself needs an owner. But its slope stays flatter as flow count grows. We would say that; check it anyway.

Three honest cautions about this picture, because a vendor showing you this chart is showing you the chart that sells software. First, the build line's slope varies enormously with discipline. A small, version-controlled, monitored script estate — the practices in hardening transfer scripts for production — can hold a shallow slope for years. Second, the buy line has its own hidden risers: license growth as flows and users expand, upgrade projects, and the exit cost you accept the day you adopt. Third, the crossing point is not a constant of nature. It is a fact about your flow count, failure stakes, and team. That is why this series ends in a worksheet rather than a verdict — one that can and does output "keep building."

The Questions That Actually Decide

The layers table tells you where to look, and the cost shapes tell you what to compare. These six questions supply the organizational facts the hallway argument was missing. Answer them in writing before anyone argues a conclusion.

1. What breaks when a transfer fails? A missed internal report costs an apology. A missed payroll feed, a late regulatory submission, or a stalled production handoff costs real damage. The higher the stakes, the more the decision hinges on recovery design, evidence, and the ability of whoever is on duty — not just the author — to intervene. Stakes are the strongest single mover toward buying; low stakes are a genuine license to keep building.

2. Who cares for the scripts, plural? Not "who wrote them" — who else can diagnose them at three in the morning, and does that person know it? If the honest answer is one name, you have a bus-factor problem that no product feature fixes but a product's uniformity substantially blunts. The article on the hit-by-a-bus test puts a number on it. I have watched a three a.m. failure wait politely until nine for the only person who could read it. If the honest answer is a real team with shared ownership, the build side just got stronger.

3. How many flows, and which direction is the count moving? Five stable flows are a different universe from thirty growing ones. Volume and growth steepen the build curve faster than anything else, because homegrown cost scales with flows while bought cost scales, more slowly, with the tool. Count your flows honestly — most teams that run the census in an automation inventory find more than they expected. Flows breed in the dark, like most infrastructure.

4. Does anyone outside the team need proof? Auditors, regulators, customers with questionnaires, partners with service commitments. Producing delivery evidence from a drawer of per-script log formats is hours of labor per question; producing it from uniform records is minutes. If nobody ever asks, this factor is worth little. If audits recur, it quietly dominates.

5. Who needs to operate flows without reading code? If helpdesk staff, operations shifts, or business users must be able to rerun, pause, or inspect a transfer, the operator-interface layer stops being optional. If the only operators are the authors, a shell is a fine interface.

6. How strange are your flows? Unusual protocols, exotic partners, judgment-heavy steps, deeply entangled business logic — the weirder the work, the better bespoke code fits and the more a product would fight you. Boring flows commoditize; weird ones resist. Weirdness is the most underrated argument for building, and we say so as the party with the opposite interest.

Who Belongs in the Room

One more reason the argument stalls: the wrong quorum. This decision is routinely made either by the script author alone (verdict: build, forever) or by a manager alone after one bad weekend (verdict: buy, immediately). Both verdicts are coin flips dressed as strategy.

The room needs four perspectives. Include the author, because only they know where the bodies are buried and which flows are secretly hard. A transition executed against the author's will fails in a dozen quiet ways. The covering operator — whoever handles failures when the author is away — because their experience is the truest measure of how operable the estate really is. The evidence answerer — whoever faces auditors or partner questionnaires — because audit labor is invisible to everyone else. And the budget owner, because the trade is ultimately engineer-hours against license spend, and only one person sees both sides of that ledger. If reading that list surfaces the fact that three of the four roles are the same overloaded person, that is not a problem with the list. That is the decision beginning to make itself.

Northgate Retail ran the wrong-quorum version and caught it just in time to learn from it. After one bad weekend, a manager approved a purchase on Monday; the script author heard about it on Tuesday, from procurement. Before the order went out, someone thought to ask the covering operator. She produced a list of the four flows she could not run alone and the eleven she could. The person who answered the auditors produced the two questions that took a day each. The purchase shrank to the partner-facing layer, monitoring got funded for the rest, and the author drove the trial. The weekend outage, it turned out, had been a single flow with no alert on it. Nobody had needed a product for that; they had needed a room.

A Decision Brief You Can Copy

Turn the hallway argument into a one-page document. The template below forces the missing facts onto the table, defines what evidence would settle the question, and schedules the decision's revisit. This is a decision organizations should re-make as facts change, not a tattoo. The honest way to fill in the "what buying must prove" line is a hands-on trial against your own two ugliest flows. Vendors, ourselves included, publish free trials precisely so that claim-checking costs you an afternoon instead of a purchase order.

BUILD VS BUY - ONE-PAGE DECISION BRIEF

Flows in scope:      [list them, or link the inventory]
Stakes:              [what actually breaks when each flow fails]
Team reality:        [who besides the author can fix a 3am failure - names]
Current build cost:  [hours/quarter on care: triage, changes, rotations,
                      audit answers - measured or honestly estimated]
Growth:              [flows and partners expected next year vs today]
Outside scrutiny:    [who demands evidence, how often]

What KEEP BUILDING must prove:
  [ ] every flow in version control, monitored, documented
  [ ] a named second person has handled a failure alone
  [ ] care hours are tracked and tolerable

What BUYING must prove (in a trial, against our own flows):
  [ ] handles our two ugliest flows end to end
  [ ] failure alerting reaches the on-call path we already use
  [ ] evidence for one delivery produced in under ten minutes
  [ ] the author agrees it does not lose capability we rely on

Decision:            [build / buy / mixed - which layers, which flows]
Owner of decision:   [name]
Revisit date:        [when flows double, the author leaves, or one year]

Where the Series Goes From Here

The next four articles argue the question properly, one side at a time. What homegrown scripts genuinely do well makes the build case at full strength. It is the article to hand a manager who thinks scripts are inherently unprofessional. The hidden costs of homegrown infrastructure then counts what the build case omits, with a fair-accounting method rather than scare stories. What dedicated tools actually add states the buy case plainly, including the list of problems no tool solves. And the tipping-point worksheet turns all of it into a score you can defend in front of exactly the room described above.

Related decisions live in neighboring series and should not be tangled into this one. Whether an automated flow should exist at all is the automation question, and it comes first. Whether a bought tool should run on your servers or a vendor's is the self-hosted versus SaaS question, and it comes after. Keep the three questions separate and each becomes answerable; merge them and you get the hallway argument back. Same hallway, same two people, one more hour gone.

Frequently Asked Questions