DEV Community: Giorgi Mgebrishvili

VideoFloppy: Five Years, Ten Users, One Dollar

Giorgi Mgebrishvili — Sun, 30 Aug 2026 12:56:15 +0000

I built it because something I loved disappeared. Five years later it has a handful of users, one paying customer, and it taught me more than any tutorial.

In 2017 I was preparing for IELTS, and somebody gave me the advice everyone gives: watch films with subtitles.

That advice sent me looking for a specific kind of tool. Not a streaming service — a search engine for phrases. Type a sentence, and see it spoken, in context, in whatever film happened to contain it. I found one. An Estonian site, judging by the .ee domain, whose name I have completely forgotten.

It did not host anything. It collected embedded players from video hosts elsewhere and made them searchable. That distinction mattered technically and it mattered legally, and at the time I did not think much about either — I just thought it was clever.

Then it closed. No announcement, no explanation. I looked for an alternative for years and never found one.

In 2021 I decided to build my own.

The name

I asked a friend, because naming things is not my strength.

His logic was that the site is light. It stores nothing itself — no video files, no uploads, no gigabytes sitting on a disk. It holds pointers to things that live elsewhere, the way a floppy disk holds very little and is proud of it.

VideoFloppy. It stuck.

What it actually is

A place to save, organise, and share videos that already exist on the internet.

You bookmark a video from YouTube or another host, put it into an album, and share it or keep it. You can follow other users. The content today is mostly YouTube trailers, music videos, and whatever people have collected — my own albums are largely seventies and eighties disco, and an unreasonable amount of Modern Talking.

Nothing is uploaded to my server. Every video plays from the host it already lives on, which means their CDN carries the bandwidth and my VPS stays cheap and idle. That was a deliberate architectural choice, and it is the single reason the project has survived five years without costing me anything meaningful.

I take DMCA seriously. There is a takedown form, and when complaints have arrived — around eleven videos over the years — I removed them. That is the entire dispute history of the project.

Building it around two jobs

I was working at an international company and at one of the Ministry of Healthcare's agencies at the same time. VideoFloppy was built in the gaps.

The MVP took roughly two months: registration first, then albums, then video saving. A fully working version took about half a year. Not because the work was hard, but because there were four or five hours a week to give it.

I mention this because side project articles usually skip it. The interesting constraint was never technical. It was that I had two employers and the project got whatever was left.

The technical part

The backend is N-tier Architecture in .NET, which was the point of the whole exercise as much as the site itself. I wanted to build something properly layered from scratch, with nobody reviewing it and nobody rushing me. That part I am genuinely proud of.

The frontend is Blazor Server. I came from Razor Pages, and the syntax was familiar enough that the transition felt natural.

The one thing that caught me out was IP addresses. Blazor Server executes on the server, so requests to my backend API carried the hosting IP rather than the user's. Obvious in hindsight; not obvious at 1 a.m. The fix was to capture the client IP in the Blazor layer and pass it through to the API in encrypted form. It is the kind of problem you only meet by building something real.

I added alertify.js for the notifications, because default browser alerts are depressing and I wanted the site to feel a little friendlier.

Later I migrated from .NET Core 3.1 to .NET 6. Less painful than expected: the main structural change was Startup.cs disappearing and everything moving into Program.cs. Mostly careful copying, not rewriting.

The whole thing runs on the cheapest Contabo VPS I could find, which has enough headroom to host several projects at once.

And I built all of it manually. ChatGPT existed by then. I did not use it, not out of principle, but because it did not occur to me. If I revisit the project, the first thing I will do is run an AI-assisted pass over it looking for vulnerabilities.

Seven languages, chosen on purpose

The interface exists in English, Polish, Russian, Spanish, German, French, and Italian. The translations came from Google Translate and an Excel file of strings, so I make no claims about their elegance.

The selection was not sentimental. Those are languages spoken across many countries rather than one, and they map onto regions where video platforms actually pay for views. There is no Chinese, because the internet there is restricted enough that neither my site nor the hosts it embeds would reach anyone, and because those views are worth nothing commercially.

That is a strange thing to reason about for a site with almost no users. But I wanted the structure to be correct even if the scale never arrived.

The economics

There is a VIP tier. It gives ten times the normal limits — a hundred albums instead of ten, and so on.

The model, in theory, is a two-sided one: more viewers make the platform more attractive to people who share videos, and more shared videos attract viewers. Three groups exist on paper — administrators, uploaders, and viewers — although uploaders and viewers are usually the same people.

In practice, here is the complete revenue history.

A user from Italy once paid one dollar via PayPal. The transaction failed for technical reasons on my side, so he never got what he paid for. I gave him a year of VIP for free, then fixed the payment flow. PayPal later changed something about their API and I moved payments to cryptocurrency.

One dollar. That is it. And I remember it clearly, because someone I have never met, in a country I have never lived in, found a site with no marketing budget and decided it was worth paying for. That was the moment it stopped being an exercise.

Where it stands

Registered users number in the tens. Real traffic is close to zero — most of what the analytics show is bots. I have never advertised it. I have never seriously tried to promote it.

The project is in maintenance now, not development. The last thing I remember fixing was a CORS error. Someday I may rewrite the frontend in Angular, mostly to see what that feels like.

The interface is unfinished, which is the honest word for it. The architecture is not.

Was it worth it

I never built VideoFloppy to make money, so it has not disappointed me by failing to.

What I got instead: a N-tier Architecture implementation I designed entirely myself, real experience with Blazor Server before it appeared on any job description I applied for, a migration between .NET versions on a system I fully understood, and a small collection of problems — client IPs, CORS, payment APIs, localisation — that I met as an owner rather than as an assignee.

Every one of those has been useful in paid work since.

And somewhere out there is a man in Italy with a lifetime of goodwill from me, who paid a dollar for a website that a stranger in Tbilisi built because a different website disappeared.

The site is still online at videofloppy.com. It does not need anything from you. But it is there, and it works, and after five years that feels like the point.

This article was originally published on Medium.

Have you built something nobody uses — and kept it running anyway? I'm curious how other people justify their side projects to themselves. 👇

What a Decade in Software Taught Me About Technology

Giorgi Mgebrishvili — Wed, 29 Jul 2026 19:40:08 +0000

Reflections from a full-stack engineer who started with small websites and ended up building systems for banking, government, and marketplaces.

Ten years ago, I wrote my first lines of production code for small business websites in Tbilisi. Since then, I’ve built platforms serving hundreds of thousands of users at the Ministry of Healthcare, contributed to some of Georgia’s biggest online marketplaces, worked with international distributed teams — and today I’m rebuilding a bank’s installment platform as a Senior Software Developer at Credo Bank.

Somewhere along the way, the technology changed completely. .NET Framework became .NET Core. Server-rendered pages gave way to SPAs, then partially came back. Teams that once sat in one room became distributed across continents. And yet, looking back, the most important things I learned have surprisingly little to do with any specific framework.

Here are the lessons that stuck.

1. Technology changes. Fundamentals don’t.

When I started, I worried constantly about learning the “right” stack. I’ve since worked with ASP.NET MVC, .NET Core, Web API, Blazor, Vue.js, and half a dozen database systems — and every single one of them has been reshaped or replaced by newer versions during my career.

What never changed: understanding how HTTP actually works, how databases index and query data, how to model a problem before coding it, how to name things so a stranger understands them. Engineers who invest in fundamentals ride every wave. Engineers who invest only in frameworks start over every three years.

2. The database is where projects live or die.

Almost every serious performance problem I’ve been asked to fix — in banking systems, in government platforms, in enterprise software — turned out to be a data problem. A missing index. A query fetching ten times more than it needed. A schema designed for how the data looked on day one, not day one thousand.

Frontend frameworks get the conference talks. Databases get the 2 a.m. incident calls. Learn SQL deeply, even if you never plan to be a “database person.” Especially then.

3. Boring technology is a feature, not a weakness.

Early in my career, I wanted every project to use the newest tools. Then I watched systems built on “boring” technology — SQL Server, plain ASP.NET, straightforward architectures — quietly run for years while trendier projects collapsed under their own complexity.

There’s a reason banks and government institutions choose mature technology. When 300,000 people depend on a platform, “exciting” is not a compliment. Now, when I evaluate a tool, my first question isn’t “is it modern?” but “will this still be maintainable by whoever inherits it in five years?”

4. Full-stack doesn’t mean knowing everything. It means understanding the whole picture.

I’ve built a Vue.js project from zero and spent years deep in backend code. Being full-stack didn’t make me the best frontend developer or the best backend developer in any room. What it gave me was more valuable: the ability to see where a problem actually lives.

Half of the bugs that get ping-ponged between “frontend team” and “backend team” exist precisely because nobody is looking at the system as a whole. The engineers who can trace a request from a button click to a database row — and back — are the ones who unblock everyone else.

5. Reading code is a bigger skill than writing it.

Over a decade, I’ve probably spent three hours reading code for every hour writing it. Legacy banking systems. Government platforms written by teams long gone. Codebases where the documentation was a rumor.

Nobody teaches this at university, but the ability to open an unfamiliar project and build a mental map of it — what talks to what, where the danger zones are, what the original authors were thinking — is one of the most employable skills in our industry. New code is easy. Understanding existing code is the job.

6. Communication is an engineering skill.

I’ve worked in hybrid teams, fully remote teams, and international teams where a colleague’s morning was my evening. The engineers who thrived weren’t necessarily the strongest coders — they were the ones who wrote clear messages, asked questions early, and made their work visible without being asked.

In distributed teams, a well-written Slack message or a precise Jira ticket is engineering work. Code that nobody understands the context of is a liability, no matter how elegant it is. If I could give one piece of advice to junior developers, it would be this: your writing skills will compound just like your coding skills.

7. Users don’t care about your architecture.

I’ve worked on platforms used by job seekers on a government portal, car buyers, and bank employees. Not one of them ever cared whether the backend was elegantly layered or whether we used the latest pattern. They cared whether the page loaded, whether the data was correct, and whether the system was there when they needed it.

Good architecture matters — but only as a means to that end. The moment architecture becomes the goal itself, you’re building for your own satisfaction, not for the people the software exists to serve.

8. Every domain teaches you something no tutorial can.

Banking taught me what “secure” really means when real money moves through your code. Government work taught me how to build for scale and for users who never read instructions. Marketplaces taught me that performance is a feature users feel instantly. And rebuilding a legacy banking platform is teaching me that some systems are so intertwined with the business that the hardest part of the job is understanding the problem, not writing the solution.

Technology skills transfer between jobs. But domain knowledge is what turns a developer into an engineer someone trusts with important systems. Don’t just learn the stack — learn the business.

9. Remote work rewards discipline, not hours.

I’ve been working with distributed teams since before it was mainstream. The uncomfortable truth: remote work doesn’t make anyone a better or worse engineer — it amplifies whoever you already are. Organized people become highly effective. Disorganized people quietly drown.

What worked for me was treating self-discipline as part of the profession: clear working hours, honest status updates, and the humility to say “I’m stuck” on day one instead of day four. Trust in a remote team is built in small, boring, consistent moments.

10. A decade in, the goal is no longer to seem smart.

The biggest shift in ten years happened in my head. As a junior, I wanted to prove I was clever — complex solutions, obscure tricks, defending my code in reviews. Now I measure myself differently: Is the solution simple? Can a teammate maintain it without me? Did I make the people around me more effective?

The best engineers I’ve met share this trait. They’ve stopped optimizing for looking impressive and started optimizing for being useful. Ironically, that’s exactly when people start considering you impressive.

What the next decade looks like

The industry I entered no longer exists. The one I work in today won’t exist in 2036 either. AI is already changing how we write code, and honestly, I find that more exciting than threatening — because if this decade taught me anything, it’s that our real job was never typing code. It was understanding problems, designing solutions, and working with people.

Those skills don’t get automated. They get more valuable.

This article was originally published on Medium.

Which of these lessons matches your own experience — and which one would you push back on? I'm curious how this looks from other corners of the industry. 👇