dzugg VPN
Simple and private VPN access without proprietary apps
A few months ago I launched Dzugg, a small VPN service I built from scratch.
The technical part was the fun part.
WireGuard servers, automated provisioning, Stripe payments, emails, monitoring, multiple European locations… even a real-world test from China recently worked successfully.
I thought getting the infrastructure right would be the difficult part.
It wasn't.
Getting people to actually discover and trust a new VPN brand is much harder.
So far I've tried:
Product Hunt
Reddit
Instagram ads
SEO/content
Direct outreach
Affiliate proposals to YouTubers
One Instagram campaign generated around 1,000 link clicks.
Sales from it: basically zero.
Reddit actually started looking promising , some posts were indexed by Google almost immediately and generated interesting conversations, until my account got caught by Reddit's filters and most of my posts disappeared.
Meanwhile, the few paying users I've had mostly came from people who already knew me or through personal connections.
That's probably been my biggest lesson so far:
Building something that works and building a distribution channel are two completely different products.
I'm not giving up on it. The infrastructure is already running, costs are low, and I don't need Dzugg to explode overnight.
So now I'm treating distribution as the next technical problem to solve: test channels, measure what happens, discard what doesn't work, repeat.
For those of you who built a SaaS or subscription product without an existing audience:
What was the first acquisition channel that actually started working consistently for you?
I’m a systems administrator based in Barcelona, and during evenings and weekends I’ve been building [dzugg](https://dzugg.com), a small WireGuard-based VPN service.
The infrastructure works, the service is automated and real users are already using it.
But the biggest lesson so far is that building the product was easier than finding customers who are willing to trust it.
How the project started
dzugg was not originally conceived as a startup or as an attempt to compete with the large VPN providers.
I wanted a simple and reliable VPN for myself, relatives and friends, including people with very little technical knowledge.
I also wanted to avoid forcing them to install another proprietary VPN application with its own background processes, account system and features they would probably never use.
Instead, dzugg generates standard WireGuard configuration files and QR codes that users import into the official open-source WireGuard clients.
The name has a personal meaning too.
dzugg was the name of an older project created by my late brother. Bringing the name back was my way of preserving a small part of that legacy while building something new.
Keeping the product deliberately simple
dzugg does not have a proprietary desktop or mobile application.
Users install the official WireGuard client and either scan a QR code or import a standard configuration file.
This decision has several advantages:
I do not need to maintain applications for every operating system.
Users rely on mature open-source clients.
There are no additional dzugg background services.
The configuration is portable and relatively easy to inspect.
Connections are established quickly.
But it also creates some friction:
The initial setup is not completely one-click.
Some non-technical users need help importing their configuration.
There is no graphical server browser.
There is no automatic country selection.
Split tunnelling depends on the operating system and client.
A custom application would improve onboarding, but it would also add a huge amount of development and maintenance work.
For now, I prefer keeping the service small and understandable.
From manual connections to an automated service
The first VPN connections were created manually for relatives and friends.
That was fine when there were only a few users, but I eventually automated the process from purchase to configuration delivery.
The system can now process an order, provision access and send the user everything needed to connect without me manually creating each configuration.
Reaching that point was technically satisfying.
It was also the moment when I realised that having a working and automated product does not mean people will suddenly appear and buy it.
A failure in Iran
One of my first external customers needed a VPN connection from Iran.
I prepared a connection through one European server, but it did not work from the network he was using.
I then tried another server in a different location with a different public IP address.
That also failed.
Since the service did not fulfil the purpose for which it had been purchased, I issued a full refund.
This was one of the most useful experiences I have had with the project.
A VPN server can be correctly configured, secure and perfectly reachable from Europe, while still being unusable from inside a heavily restricted network.
The issue may have been WireGuard traffic filtering, UDP restrictions, datacenter IP blocking or something specific to the local network.
I did not have enough access from inside Iran to diagnose it properly.
The lesson was clear: access from censored countries cannot be marketed as a guaranteed feature. It has to be treated as best effort and tested under real conditions.
A successful test in China
Some time later, my brother travelled to China and used one of the standard dzugg WireGuard configurations.
To my surprise, it worked.
He was able to connect and confirm that his traffic was passing through the European VPN server.
I do not interpret one successful trip as proof that it will always work in China. Restrictions can change depending on the provider, region, network and endpoint IP.
Still, it was interesting that essentially the same architecture failed in Iran but worked during a real-world test in China.
## Shared and dedicated connections
Most users connect through shared servers, but I also offer the option of assigning an entire server to one person or household.
One of my nephews uses a dedicated server because he regularly makes Telegram calls and wants the connection to be as stable and predictable as possible.
A dedicated server cannot eliminate problems caused by his local connection, international routing or Telegram itself.
However, it gives him a consistent public IP address and avoids sharing server resources with unrelated users.
It is a niche option, but it may eventually become a more meaningful differentiator than trying to compete with large providers through the number of available countries.
Applications that do not like VPNs
Another unexpected lesson has been that a working VPN tunnel does not guarantee that every application will behave correctly.
I have experienced problems with Wallapop and, somewhat ironically, Gemini.
Sometimes the application does not load correctly while the VPN is active, but immediately works again after disabling it.
This may be related to:
Datacenter IP classification.
A mismatch between the account and IP locations.
Shared IP reputation.
Anti-fraud or anti-bot systems.
DNS, IPv4 or IPv6 behaviour.
A dedicated IP may help in some cases, but it cannot solve services that reject entire hosting-provider IP ranges.
The technical part is now easier than finding customers
The product works.
The infrastructure is ready, provisioning is automated and users can receive a working connection without manual intervention.
The difficult part is convincing strangers to trust a small VPN provider.
Most of my current users are relatives, friends or people who arrived through personal recommendations.
That makes sense. A VPN user is effectively choosing who will operate an important part of their internet connection. Trust matters more here than in many other products.
Large providers already have:
Recognised brands.
Large advertising budgets.
Proprietary applications.
Hundreds of servers and locations.
Thousands of public reviews.
I cannot compete directly with that.
What dzugg can offer instead is:
A small and controlled infrastructure.
Standard WireGuard configurations.
Native open-source clients.
Shared or dedicated servers.
Transparent limitations.
Direct personal support.
Today I published a short post about the project in the WireGuard community on Reddit. It received almost 4,000 views in several hours and generated noticeable traffic to the website, despite receiving almost no votes or comments.
That small experiment showed me that the audience exists, but reaching it without becoming repetitive or excessively promotional is difficult.
The question I am trying to answer
Should I keep dzugg deliberately small and focus on a specific niche, such as dedicated VPN servers and personal support?
Or should I gradually invest in custom applications, more locations and the features people expect from mainstream VPN providers?
I would be interested in hearing from other indie founders:
How did you earn the first customers who did not already know you?
How would you build trust around a product as sensitive as a VPN?
Would you focus on the minimal shared service or the dedicated-server niche?
At what point would you invest in a custom application?
Is remaining small and personal a real differentiator, or simply a limitation?
-
1
You’ve collected enough real-world evidence here that the decision seems bigger than whether to add a custom app.
Of the people who chose dzugg without already knowing you personally, what specifically made them trust a small provider enough to try it — and has that been consistent enough to tell you what kind of VPN business they actually want from you?
-
1
Hi Aryan! Thanks a lot for your comment.
That’s a good question. Honestly, I don’t have enough external customers yet to see a consistent pattern.
Most current users already knew me or came through personal recommendations. The only completely unrelated customer found dzugg because he needed a VPN for Iran, but it did not work there and I refunded him.
So I still don’t know what specifically would make a stranger trust dzugg, or which part of the service they would value most. That is probably the next thing I need to learn.
Based only on the information currently available on the website, would you personally trust dzugg enough to consider using it? If not, what information, proof or reassurance would be missing? And what would ultimately make you choose dzugg over another VPN provider?
-
1
That’s helpful context. The distinction between people who already trust you and strangers deciding whether to trust the service is an interesting one.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
-
1
Thanks Aryan. Happy to continue the conversation here for now.
Just to be transparent, dzugg is fully bootstrapped and I’m not in a position to budget for consulting or strategy services at the moment.
That said, I’d genuinely value your perspective here, especially on what you see on the website that would make you trust, or not trust, dzugg as a small independent VPN provider.
-
1
Thanks for being transparent, I appreciate that.
The trust question is the interesting part here — especially when a small independent provider is asking strangers to rely on a service where credibility matters.
I understand the budget constraint. I’ll be interested to see what you learn as you get more customers outside your existing network.
-
-
-
-
Comment