Right, this is a really good question. Dropbox Transfer achieves the same purpose as WeTransfer with a few differentiators. Unpacking this a bit, there are two parts here:

1) For a company with an established sharing model (shared folder, live-updating links), a departure or addition to this needs to be thoughtfully orchestrated. Moving to snapshotting content, gathering content inside and outside your Dropbox, and enforcing expiration in this tool is a very different paradigm.

2) However, specifically because we are also a storage provider, we can provide a much faster sending experience for them as we can remove the upload step, which is especially important for folks sending really large files. We have a large user base storing their content in Dropbox, this is a net new added value/functionality for them.

Even if the internal discussions were "other services do this and we want a piece of that pie", no company is going to come out in a product launch announcement and directly say "another service is doing this and we want a piece of that pie".

And in this case, I would still hope they did do market validation internally, even if it is just a copy of wetransfer. Just because some other company is doing something doesn't automatically mean it's a good fit for your company to do it, too.

As for the design, it's pretty hard to say that "a generic file selection panel in the middle of a page and a Sign Up button at the top right of the page where it typically is on most sites" is a "straight up clone". The color schemes are similar, but that's just because the main color branding of both companies happens to be light blue.

Same issue on Windows. If you are adding new context items automatically, please have decency to add option to remove them, without hacking the registry. Also, please do not add it back in later update, which happen quite often.

If you use 7zip on Windows or just split/cat on macOS/Linux, you can split without compressing or archiving, saving you unnecessary CPU cycles (and space).

You gotta wonder how much easier it would be to put a stamp on a letter with an SD card in it sometimes

No Syncthing, rsync, or multi-connection FTPS/SFTP with split archives?

Hi! Sending groups of files was definitely one of the focus areas here so hope Transfer can be helpful in this role.

Re: Tracking content, we actually do provide this in Transfer. If you specify a set of email recipients, rather than copying a shared link, we provide a few tracking features for you.

1) Record who has viewed or downloaded your content. 2) Remind your recipient if the content you sent is about to expire. 3) (Optionally) notify you to let you know when your recipient has downloaded your content.

The most technically challenging part was probably wiring the storage & sharing side up to not behave like a traditional Dropbox shared folder or shared link (e.g. not take up storage quota or sync down to your machine). There were certainly a long tail of internal reliability work to get that operating smoothly (there are many internal services to work with here).

In terms of tricks at handling failures:

The first (and probably most important) thing is finding the failures. Bug bashing sessions and also just reading failure logs can help catch the trickier transient problems our integration or unit tests do not catch.

In terms of mitigating them, retries and correct error handlers in code are essential (e.g. Promise.catch case should not be ignored!). Retries on the client side are made a bit easier as we chunk uploads into 4mb blocks so any upload errors of actual content can be retried piecemeal.