Building a WeTransfer Alternative: Three Architecture Decisions That Decide Whether It Survives

File transfer looks like a solved problem and is not. The incumbents — WeTransfer, Smash, Send Anywhere — are built for people who move files constantly, and they are priced and designed accordingly: accounts, storage, subscriptions, teams. The far larger group sends one large file a handful of times a year, to a client or a relative or another one of their own devices, and every one of those services asks them to sign up first. That gap is the product. Whether the product survives contact with real traffic comes down to three decisions made before the first screen is designed.

TL;DR:

  • The opening is occasional users, who are asked to create accounts and hold subscriptions for something they do four times a year.
  • Decision one: file bytes must never transit your API. The client gets a short-lived signed URL and writes straight to object storage, so compute cost stays flat as volume grows.
  • Decision two: expiry deletes the object. A database flag that hides a file is not deletion, and recycled share codes let an old link resolve to someone else's file.
  • Decision three: link passwords are salted hashes, never recoverable. With no accounts there is no recovery flow, so the password is the only thing guarding the file.
  • Prepaid credits beat subscriptions for occasional use — no renewal decision, no cancellation moment, no support load.

Table of Contents

Why This Category Is Still Open

Every established file-transfer service has the same business incentive: convert a one-off sender into a recurring subscriber. That incentive produces the same interface everywhere — a sign-up wall, a storage quota, a plan comparison — and it is precisely wrong for the person who just needs to get a 600 MB video to a client this afternoon.

The opening is not a better transfer engine. It is the removal of everything that is not the transfer. Pick a file, upload, get a link, send it. No sign-up, no email, no password, no profile: the device generates an anonymous identity on first use and the user is transferring within seconds.

This is a small product by design, and that is the point. It has no social graph, no moderation burden and no team-permissions model, which means a very small operation can run it well.

Pro Tip: The competitive advantage in this category is subtraction. Every feature that implies an account walks the product back towards the incumbents, who will win that fight.

The No-Account Decision

Going accountless is not merely a sign-up screen you skip. It propagates into everything.

There is no identity to attach a transfer to, so the device holds an anonymous identifier generated on first launch, and purchased credits are linked to that. There is no password reset, because there is no account to reset. There is no support path for "I lost my link", because there is nothing to look it up against. And there is no personal data to hold, which turns a compliance surface into a paragraph.

Each of those is a trade. You accept that a user who wipes their device loses their remaining credits unless you give them a way to move the identifier, and you accept that you cannot email anyone about anything. In exchange the product starts working for a stranger in about four seconds, which in this category is the whole proposition.

Decision One: Uploads Never Touch Your Server

This is the decision that determines whether the economics work.

The naive build has the client POST the file to your API, which streams it into object storage. It is simple, it works in development, and it fails as a business. Every concurrent upload occupies a request handler for the duration of the transfer — which for a multi-gigabyte file on a domestic connection is measured in minutes, not milliseconds. Your compute cost scales with the number of bytes moved, your function timeouts become a ceiling on file size, and one user on a slow connection is indistinguishable from an outage.

The correct build inverts it. The client asks your API for a short-lived signed upload URL, and then writes the bytes directly to object storage. Your API handles two small JSON requests per transfer and never sees a single byte of the file. Compute cost stays flat regardless of volume, file size is bounded by the storage provider rather than by your runtime, and a slow client costs you nothing.

Every serious storage provider supports this — it is standard practice, not an optimisation — and retrofitting it later means rewriting the upload path, the progress reporting and the client on every platform at once. It is the first decision for a reason.

Decision Two: Expiry Means Deletion

A transfer service makes an implicit promise: after the expiry window, the file is gone. Most of the cheap implementations do not keep it.

The lazy pattern sets expired = true in a database row and returns a 404 from the download endpoint. The object is still sitting in the bucket. You are still paying to store it, you are still holding data a user believes was deleted, and the file is one authorisation bug, one leaked object key or one misconfigured bucket policy away from being readable by anyone. If a regulator or a customer ever asks what happens to their data after seven days, "it is hidden" is a materially different answer from "it is deleted".

The second half of this decision is quieter and worse when it goes wrong: never recycle share codes. If the code in an expired link can be reissued to a later transfer, then an old link — sitting in a chat history, an email, a bookmark — can one day resolve to a stranger's file. The fix is to treat share codes as permanently spent. The cost is a few bytes per expired transfer. The alternative is a privacy incident with a perfectly clear audit trail leading back to a design decision.

Decision Three: Passwords With No Way Back

Optional passwords on share links are a standard feature, and an accountless product has to be stricter about them than a normal one, not more relaxed.

In a service with accounts, a password sits behind an identity, an email address and a recovery flow. Here there is none of that. The link password is the only thing between a URL and the file, and there is no second factor, no login attempt log tied to a user, and no way to notify anyone that something was accessed.

So it is stored as a salted hash from a memory-hard function — scrypt, argon2 or bcrypt — and never as recoverable plaintext or reversible encryption, in line with the OWASP password storage guidance. The temptation to store it recoverably is real, because without accounts there is no "reset password" button and a sender who forgets theirs is stuck. Resist it: the correct answer to a forgotten link password is to re-upload, and the incorrect one hands over every protected transfer in a single database leak.

Pro Tip: These three decisions are the ones to audit first if you are buying an existing file-transfer product. All three are invisible from the outside and expensive to retrofit.

Credits Versus Subscriptions

The monetisation should match the usage, and the usage here is bursty and infrequent.

A subscription asks an occasional user to make a recurring decision about an occasional need. They will cancel, and the cancellation will be the last interaction they have with the product. Worse, they will have spent several months paying for nothing, which is the kind of value-for-money story that produces one-star reviews long after the refund.

Prepaid credits invert every part of that. The user buys when they have a reason to buy, the credits do not expire so there is no urgency and no waste, and there is never a renewal decision to regret. No cancellation flow, no dunning emails, no failed-payment support queue. The buyer feels they paid for what they used, because they did.

What you give up is a recurring revenue line, which makes the model right for a utility and wrong for anything that wants to be a workspace tool. Tiered packs — a small one that is nearly an impulse purchase, a middle one most people take, and a large one that makes the middle look reasonable — are the standard shape.

Where to Draw the Free Line

The free tier has one job: let a stranger complete a real transfer without paying, so they learn the product works before they are asked for anything.

That argues for a size limit generous enough to cover documents, images and short clips, and a link lifetime long enough for a recipient to get around to it — around a week is the norm, because a link that dies in 24 hours dies over a weekend. The paid line then sits where the genuine pain is: the large video, the design archive, the folder of raw photographs that email and chat both refuse.

Setting the free ceiling too high is the more common mistake. If the free tier covers the case people would have paid for, there is no product underneath it.

Build or Buy

Built new, this is a real engineering project rather than a weekend: two clients, a shared backend, a credit ledger, an in-app purchase integration, signed-URL upload flows with resumable progress, a deletion job, and an App Store submission. Commissioning it lands in the tens of thousands of euros, and the parts that take longest are the unglamorous ones — the ledger and the expiry job, not the upload screen.

Buying one already live skips the two things that cost time rather than money: the store approval, and the discovery that your first upload architecture does not survive a 3 GB file. Our cost calculator will price the new-build version if you want the comparison.

A Finished One, as a Worked Example

The three decisions above are not hypothetical — they are the ones taken in FileFly | Share & Upload Files, a project in our catalogue that is live on the App Store in the Productivity category, with a deployed web app alongside it.

The flow is the one this article argues for: pick a file, upload, get a share link, send it — no sign-up, no email, no password, no profile, with an anonymous device identity generated on first use. Free transfers cover files up to 10 MB with links that stay available for seven days; larger transfers, up to 5 GB, are unlocked with prepaid credits that never expire, sold in three tiers configured in App Store Connect.

Architecturally it takes all three positions. Uploads bypass the API entirely via short-lived signed URLs, so file bytes never transit the application server. Expiry deletes the object rather than hiding it, and share codes are never recycled, so an expired link can never later resolve to another user's file. Link passwords are stored as salted scrypt hashes rather than recoverable values.

What is included in the sale: the iOS app (React Native, iOS 15.1+, with Apple Silicon Mac and Vision Pro compatibility), the web application built with Next.js and deployed on Vercel with feature parity for upload, link management, credits and settings, the shared backend and API serving both clients, the credit ledger and anonymous device-linking system, full source for all three, the brand assets and App Store screenshots, the in-app purchase products already configured, and the existing domain and deployment.

The panel below reads the catalogue row directly, so the price and availability shown there are current.

Sources

FAQ

What is the best WeTransfer alternative?

It depends on whether you transfer files constantly or occasionally. Heavy users are well served by subscription services with accounts, storage and team features. Occasional users — the majority — are badly served by all of them, because they are being asked to create an account and hold a subscription for something they do a few times a year. For that use case the better shape is no account at all and prepaid credits that do not expire, so the cost tracks actual use rather than calendar months.

How do you build a file sharing service that scales?

Keep the file bytes away from your application server. The client asks your API for a short-lived signed URL and then writes directly to object storage, so your compute cost stays flat no matter how much data moves. Routing uploads through the API is the single most common architectural mistake in this category: it turns every large transfer into held server memory and connection time, and it makes your hosting bill scale with traffic in a way the revenue does not.

In a correctly built service, the stored object is deleted. In a lazily built one, a flag is set in a database and the file stays where it is — which means the data you promised to delete is still there, still costing storage, and still one bug or one leaked identifier away from being readable. The related rule is never to recycle share codes: if an expired code can later be reissued, an old link can resolve to a stranger's file.

As salted hashes from a memory-hard function such as scrypt, argon2 or bcrypt — never as recoverable plaintext or a reversible encryption. This matters more, not less, in a product with no accounts: there is no identity to verify and no recovery flow, so the password is the only thing standing in front of the file. Storing it recoverably means a database leak hands over every protected transfer at once.

Do credit packs work better than subscriptions for file transfer?

For occasional use, yes, and the reason is churn rather than price. Someone who sends a large file four times a year will cancel a monthly subscription and remember the cancellation as the last thing your product did. Prepaid credits that never expire produce no renewal decision, no cancellation moment and no support load, and the buyer feels they paid for what they used. The trade-off is no recurring revenue line, which makes the model right for a utility and wrong for a workspace tool.