Valérian de Thézan de Gaussan 
Starting with a real teaching project
Two years ago, I had a script that could summarize Youtube Videos by making calls to OpenAI. It was local and usable through CLI.
At the time, I wanted a small project to teach my brother Grégoire the basics of the web, but I did not want a fake tutorial, another todo app, or an abstract demo that only exists to explain a framework.
I wanted something real enough to be useful and small enough to understand: a project with an input, an output, a page, a server, a few moving parts, enough to make the lessons stick. That became YouTubeSummary.
The first version was built with FastAPI and Jinja2 templates, and it was about as simple as it sounds: a small web server, a form, a YouTube URL, and a result page with a summary. That was the product, and for that moment, it was enough.
I promoted it a little, mostly to see if people would care. Some did, not massively, and certainly not in a “we are so back” kind of way, but enough to make the project feel alive.
Then I kept using it myself, which matters more than I realized at the time.
Staying alive by being useful
A lot of side projects die because, after the launch excitement is gone, even the person who built them stops opening them. The landing page stays online for a while, the domain renews once or twice, a few dependencies break, and the project slowly becomes dead.
YouTubeSummary did not become that because I kept using it, kept noticing small annoyances, and kept fixing them, sometimes because users needed it, but often because I needed it too. The product stayed close to me, and because it stayed close, it stayed alive.
For more than two years, the basic version did its job. It was not impressive, it was not built around a beautiful product architecture, and it did not have accounts, payments, dashboards, teams, folders, analytics, or any of the things you start imagining once you convince yourself your small tool needs to behave like a company.
It had one simple job: paste a video and get a summary. That was enough to teach Grégoire, enough for me, enough for strangers to use, and enough to keep improving.
The ads paid for the AI models, good equilibrium between the two, so I wasn’t bleeding money.
Outlasting the trend
Over the years, I saw many YouTube summary websites appear, which made sense because, with the AI boom, summarization became one of the obvious use cases. Everyone understood the promise immediately: videos are long, time is limited, and a summary is useful. The product almost explains itself.
So for a while, I felt like one project among hundreds, until I recently went back to a directory where I had submitted YouTubeSummary in 2024 and it felt like walking through a cemetery. So many projects were gone, abandoned, broken, or frozen in place that I would guess around 80% did not last.
Some looked more serious than mine, with better landing pages, cleaner branding, more ambitious copy, and more features on the surface, but they disappeared.
I do not know exactly why. Maybe the founders moved on. Maybe traffic never came. Maybe maintenance became boring. Maybe the products were built for a trend, submitted to a few directories, and left alone when they did not grow quickly enough.
My guess is that many of the builders were not users of their own product, and that changes everything.
When you do not use what you build, every improvement is a guess. Every bug is just another task. Every maintenance problem feels like debt. You can keep going for a while on excitement, ambition, or the hope that traffic will arrive, but once that energy fades, the project has nothing pulling it forward.
YouTubeSummary survived for a simpler reason: I was still using it. That does not make it a great product or a special one, but it gave the project a pulse because I had reasons to come back, reasons to care about small improvements, and reasons to keep the thing working even when it was not growing fast.
Earning the rewrite
Then, recently, the situation changed. YouTubeSummary started growing organically, Google began sending real traffic, and the app reached more than 200 summaries generated per day.
For a long time, rewriting the app would have been a wasted effort. I could have spent weeks setting up a more serious frontend, a cleaner architecture, account management, payments, user dashboards, and all the other machinery that feels responsible when you are building a product.
But responsible for what? At that stage, the project did not need all of that; it needed to exist, work, be used, and spend time in the real world.
A simple FastAPI and Jinja2 app was not a compromise; it was the correct shape for the stage the project was in. Now the stage is different.
With more traffic, more usage, and more things I want to build, the old structure started to feel limiting. I want to add features that are harder to support with a few server-rendered templates, including accounts, payments, pro features, better user flows, and more room for the product to evolve without every change becoming awkward.
So I rewrote YouTubeSummary with FastAPI and SvelteKit. FastAPI stayed because it still fits the backend well, but the frontend needed more space, and SvelteKit gives me cleaner components, better routing, and a better foundation for the kind of product work I want to do next.
The timing matters because two years ago this rewrite would have been premature. It would have been me building infrastructure for a product that had not yet earned it, while now, with organic traffic and real daily usage, the work makes more sense.
The lesson
That is the main lesson I take from this: when you are building something, it is very easy to get distracted by the machinery, including the framework, the stack, the architecture, the auth system, the database design, the hosting setup, the queue, the billing layer, the admin panel, and the future version of the product that exists mostly in your head.
AI makes this even easier because you can generate code faster, scaffold features faster, produce a polished-looking product faster, and imagine ten extensions before one person has used the first version. That speed is useful, but it works best when there is traction.
That speed is useful. It can also pull you away from the only question that matters early on:
Does this simple thing deserve to exist?
Most projects do not need much at the beginning: they need a page, a flow, one useful action, someone to use them, and time in the real world.
A simple web server can teach you more than a perfect architecture with no users, and that was true when I built the first version of YouTubeSummary. It is still true now, even with AI.
So, to conclude:
Ship only products you would use yourself.
Start simple enough to ship.
Watch what happens. Don’t kill something after 3 weeks.
Then add complexity when the project has earned it.