Most tools on the web ask you to make an account before they do anything useful. Type in your email, pick a password, confirm the email, and only then can you save a video you liked. I never understood that trade, so when I built ramrom.io I left accounts out entirely. There is no sign-up form, no login, and no database behind the site. That was not a feature I forgot to add. It was the first design decision, and it shaped everything else.
A downloader does one job: you paste a link, it finds the file, you save it. None of that needs to know who you are. If I kept accounts, I would need a users table, a password reset flow, and a way to look after the data people trusted me with. I run this on shared hosting as a side project. A user database would be the most valuable thing on the server and the thing I am least equipped to defend. Leaving it out is not laziness. It is the honest answer to the question of what a small tool can look after properly.
So there is nothing to store, and that keeps the code simple. The site has no database at all. The link you paste goes to a PHP script that calls the provider, gets the download URL back, and hands it to you. The provider answer is never written to disk. There is no history page, no "your recent downloads" list, and no cookie that remembers you between visits. Close the tab and the site forgets you ever came. That is the whole privacy policy, and it fits in one sentence on the site itself.
Not storing files is part of the same decision. The video is never saved on my server. The proxy streams it through to your browser and forgets it, or the browser fetches it straight from the provider's link. Keeping a copy would mean paying for storage, policing what sits on the disk, and answering for files I never wanted. Streaming costs a little bandwidth and keeps the server clean. It also means I cannot show you a download you made last week, because there is nothing to show. I think that is a fair trade, and I say so on the site rather than hiding it.
The part people miss is that no accounts makes the site harder to break in other ways too. There is no password to leak, no session to hijack, and no admin panel worth finding. The only secret on the server is the API key in a config file that the web server refuses to serve, and nothing in the browser ever sees it. Fewer moving parts means fewer ways for the site to fail, and when something does fail the error is usually honest: the provider is busy, the link is private, or the video is gone. A spinner that never stops is worse than a plain message, and a login wall in front of a one-off download is worse than both.
There is a cost, and I do not pretend otherwise. I cannot offer syncing across devices, saved favourites, or a queue that waits for you. If someone wants those, this tool is not for them, and that is fine. Most visitors paste one link, download one video, and leave. Building an account system for them would be like asking for ID at a public drinking fountain.
The lesson I took from it is a general one: before adding a feature, ask what it forces you to store. Every stored field is a promise to look after it, and a small project should only make promises it can keep. A downloader that keeps nothing is a downloader with nothing to lose, nothing to leak, and nothing to maintain. That is the whole design, and it has held up well so far.
