Building VidFixa: A Video Downloader Built with Go, Nuxt, PostgreSQL and Bachs
I built VidFixa as a real project to learn, experiment, and actually ship something instead of building another tutorial project that never leaves my computer. VidFixa is a video downloader that supports Instagram, TikT
I built VidFixa as a real project to learn, experiment, and actually ship something instead of building another tutorial project that never leaves my computer.
VidFixa is a video downloader that supports Instagram, TikTok, Facebook, X, and LinkedIn. The idea is simple: paste a video URL, let VidFixa process it, and download the video without a watermark.
You can try it here:
VidFixa β Download videos. Simple. Fast. Β· VidFixa
Save videos from Instagram, Facebook, X, and LinkedIn in seconds. High quality, no watermark, secure and private.
The source code is public on GitHub:
Why I built it
I wanted a project that would force me to work on more than just CRUD APIs.
I wanted to deal with things like:
β’ Background processing
β’ Concurrency in Go
β’ External processes
β’ PostgreSQL
β’ Authentication
β’ Subscription management
β’ Payment webhooks
β’ Deployment
β’ Error handling
β’ Production issues
That made a video downloader a good project for me because the download itself is only one part of the system.
The stack
The backend is built with Go and Chi.
The frontend is built with Nuxt.
For data storage, I use PostgreSQL.
Video processing uses yt dlp, with FFmpeg where needed.
For payments and subscriptions, I integrated Bachs.
The application is deployed on Render.
How the download flow works
The basic flow looks like this:
User submits a video URL.
VidFixa identifies the request and checks the user's download allowance.
The download job is then placed into the background processing system.
A worker picks up the job and runs the download process.
The resulting file is stored and made available to the user.
One of the things I wanted to avoid was tying up the HTTP request while a video was being processed.
That pushed me toward using background workers and Go's concurrency features.
Learning concurrency with Go
One of the biggest reasons I chose Go for the backend was to get more comfortable with concurrency.
VidFixa uses background workers to process download jobs instead of trying to do everything inside the request handler.
This gave me practical experience with goroutines, channels, worker pools, context cancellation, timeouts, and controlling concurrent work.
Building these features into a real application helped me understand them much better than simply reading about them.
Authentication and anonymous users
I also wanted people to be able to try VidFixa without immediately creating an account.
Anonymous users are tracked with a signed cookie, while registered users have authenticated accounts.
This created an interesting problem because the application still needs to enforce monthly download limits without requiring every visitor to register.
Subscriptions and payments
VidFixa currently has three plans:
Free: 15 downloads per month
Plus: 85 downloads per month
Pro: 200 downloads per month
The monthly limits reset automatically and unused downloads do not carry over.
Bachs handles the subscription checkout and payment processing.
The backend also listens for payment events through webhooks so subscription state can be updated from payment events rather than relying only on the frontend.
This was another part of the project that taught me how different a real payment integration is from simply adding a payment button.
Some of the problems I encountered
Getting the application running locally was only part of the work.
Deployment introduced its own problems.
At one point, the backend deployed successfully but the environment did not have yt dlp available. Since the application depends on it, downloads could not work.
I had to update the Docker setup so the required dependencies were installed during the image build.
I also had to deal with routing problems, CORS configuration, favicon deployment, webhook testing, authentication, database connections, and platform specific download behaviour.
Some problems were caused by my code.
Others were caused by the environment.
That was probably one of the most useful parts of the project because production development is not just about writing code. You also have to understand the environment your code runs in.
What I learned
The biggest lesson from VidFixa was that building a complete product forces you to understand how different parts of software fit together.
I learned more about:
β’ Go concurrency
β’ HTTP APIs
β’ Authentication
β’ PostgreSQL
β’ Background workers
β’ External processes
β’ Docker
β’ Deployment
β’ Payment integrations
β’ Webhooks
β’ Error handling
β’ Production debugging
More importantly, I learned what it feels like to take an idea from a local development environment to a publicly accessible application.
What's next
There are still things I want to improve.
I want to continue improving the download pipeline, monitoring, error handling, user experience, and overall reliability.
There is also more I want to learn around scaling background jobs and handling larger workloads.
For now, the important part is that VidFixa is live and people can actually use it.
Final thoughts
VidFixa started as a project for learning Go and backend development.
It became a much bigger learning experience once I started dealing with payments, subscriptions, background processing, deployment, and production problems.
I am still learning, but I wanted to build something real instead of waiting until I felt ready.
If you want to see the implementation, the entire project is public on GitHub.
And the live application is here:
VidFixa β Download videos. Simple. Fast. Β· VidFixa
Save videos from Instagram, Facebook, X, and LinkedIn in seconds. High quality, no watermark, secure and private.
Built by Tino Ctemz.
Go #Golang #Nuxt #PostgreSQL #WebDevelopment #SoftwareDevelopment #BuildInPublic
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.

