Half the trade still works the old way: the read, the logs, the photos and a note all bundled into a single archive and sent over as one attachment. RemapDash unzips known archive formats natively on arrival and sorts what is inside onto the job — and when you are finished, a single drop area zips everything back up for return. No WinRAR, no desktop full of loose folders.
It would be easy to treat the zipped submission as a bad habit to be trained out of customers. That would be a mistake, because there are good reasons it persists — and a portal that fights how the trade actually works is a portal that loses dealers.
A master sending work down to a tuner is rarely sending one file. There is the read itself, often more than one. There may be a data log from the last attempt, a photo of the ECU label or the sticker, a previously flashed version for reference, an original from before someone else touched it, and a text note describing the fault. Bundling that into a single archive is not laziness — it is the sender being organised. One attachment, one upload, nothing left behind, and everything about that job travelling together.
It is also how the trade has worked for twenty years. Email attachment limits taught everybody to zip. WeTransfer and Dropbox links taught everybody to zip. Anybody who has been supplying files since before portals existed has the habit burned in, and they are frequently your best and highest-volume customers. Telling them to change is a strange way to thank them.
The customer uploads their zip exactly as they always have. From that point on it stops being your problem:
The practical difference is small per job and enormous per month. Opening an archive takes a tuner perhaps a minute, plus the mental cost of deciding where the pieces go and the small ongoing mess of a downloads folder that is never quite clean. Multiply by every zipped submission you receive and the minute stops being a minute.
The return trip has the same problem in reverse, and it is the one that actually causes arguments with customers.
A finished job is often more than one file. The tuned file, maybe a second variant, maybe the re-encoded slave, maybe a note or a log for the customer's records. Sent as loose attachments they arrive as a jumble — and there is a real chance the customer downloads two of the three, flashes the wrong one, or comes back a week later asking for the file they never noticed.
So there is a single drop area on completion. Everything you want the customer to receive goes into it, and it is zipped into one archive for return. One download for them, one clearly bundled deliverable from you, and no ambiguity about what constituted "the finished job".
None of this is an argument for zipping. If your customers are willing to use the portal properly, they should — and most will once they see it.
RemapDash has dedicated upload handling: the read goes in as the read, data logs are uploaded separately as data logs, and supporting files are attached as supporting files. Everything is typed correctly from the moment it arrives, which means the job is immediately legible to whoever picks it up, and your file history stays clean and searchable rather than being a pile of archives you would have to open to understand.
There is a longer-term argument here that is worth taking seriously. Clean, correctly typed data at intake is what makes your library useful later — it is the difference between finding the right past job in five seconds and not finding it at all. Archives are convenient at the moment of sending and slightly costly forever after. Native unpacking is what lets you accept the convenience without inheriting the cost.
On its own, archive handling is not the headline feature of a portal. Nobody switches platforms over unzipping. It belongs to a category of small frictions that individually sound trivial and collectively decide whether running your file service feels smooth or feels like wading:
Remove them one at a time and each removal looks minor. Remove all of them and the job becomes: read the request, do the tuning, send it back. Which is what you thought you were signing up for when you started a file service.
Yes. RemapDash recognises known archive formats on upload and unpacks them natively inside the portal, attaching the contents to the job. You do not download the archive, open it in an extraction utility, or sort the contents by hand — the read, logs, photos and notes are simply there on the job when you open it.
Yes, and deliberately so. Many masters and long-standing dealers bundle the read, data logs, photos and notes into a single archive out of habit and organisation. RemapDash accommodates that older workflow by unpacking the archive natively and sorting the contents onto the job, while also offering separate upload slots for customers who prefer to submit each item individually.
Yes. There is a single drop area on completion — everything you want the customer to receive goes into it and is zipped into one archive for return. The customer gets one download instead of several loose attachments, which removes the common problem of a customer downloading only part of a finished job or flashing the wrong file.
Yes. Data logs can be uploaded separately from the read, and supporting files attached as supporting files, so everything is correctly typed from the moment it arrives. This keeps job history clean and searchable. Zipped submissions are supported as well, for customers who prefer the older way of working.
Yes. Once the archive is unpacked, a slave file that came out of it follows the same automatic decode path as one uploaded on its own. Being inside an archive does not stop the automation.
Because bundling a job into one archive is usually the sender being organised rather than careless, and because the habit is common among the highest-volume, longest-standing customers in the trade. A portal that refuses to handle the way its users actually work loses those users. RemapDash offers a better submission method and supports the old one.
Native archive handling, automatic slave decode, WinOLS LUA bot, branded portal, mobile app, Telegram and invoicing — £74.50/month for your first 6 months, then one flat £129/month. No per-file charges, no VPS bills, no contract.