Under the cut: my story of how I decided not to pay for a VPN, but to deploy my own instead. Then I thought: why not make a full-fledged service? And then... well, the rest is business as usual.

I set up servers, hired a designer, launched ads, and tried not to get disappointed. Spoiler: The clients are happy, I'm not yet.

дизайн: artogrannik — design: artogrannik

Disclaimer!
I anticipate a lot of hate regarding OpenVPN. Yes, I know it's not the best choice. It just happened that way historically. I plan to add support for other protocols (specifically, XRay).
Nevertheless, at the moment OpenVPN is proving to be stable (at least I haven't received any complaints).

How it all began

Part of the original article's text has been deleted (for reasons you can guess) and replaced with:

Every year I think more and more about traffic security — especially on public Wi-Fi networks.

I wanted an extra layer of security in the form of a VPN, but connecting to third-party VPN services was too boring for me. I decided to set up my own server on a rented virtual machine.
A nice bonus was the fact that I could provide access not only to myself but also to my loved ones at no extra cost.

How it continued

Time went on. The number of friends and relatives I gave access to grew. Gradually, the idea of creating a full-fledged public VPN service crept in.

I started analyzing the current market. The picture was not encouraging:

There are already a large number of VPN services, both well-known and no-name ones.
Most users who need a VPN have already found "their" VPN.
Those who haven't found "their" VPN yet probably just don't have a high need for it.

It became clear that I needed to be different in some way

pay-as-you-go

Free VPNs aren't stable enough, and you're not ready to pay 500 rubles a month if you only use it a couple of times a week? I have an idea!

Yes, I decided to focus on users who don't need a VPN that often. Users won't pay a monthly subscription fee. They will buy time that is only consumed when using the VPN. And this time will never expire.

Example

A user bought 30 hours for 100 rubles. If they use it for an average of 20 minutes a day, that 100 rubles will last them for 3 months.

Or they could buy 100 hours and use them up in 1 month with active use. But even in this case, they would benefit: there will be a discount for buying a large number of hours.

What about the name?

I didn't overthink the name. I wanted something that reflected my pricing policy. After a little thought, I came up with "VPN-Time".

The idea of creating branding with references to "Adventure Time" came to me right away. Fortunately, I had a designer in my circle who quickly picked up the idea, created a logo, and designed the layout for the Telegram bot (each menu has its own picture, one of which I used as the cover for this article).

Infrastructure:

Server for the Telegram bot, database, and DNS
custom-written billing on the same server
VPN server in the Netherlands
VPN server in Luxembourg
The monitoring system consists of three Telegram bots (one for each service), which regularly send me telemetry, load, and information about the main running services.

That's enough for now. As the user base grows, I plan to add new locations.

But why DNS?

Well, first of all, in case I have to move the servers to another IP or hosting provider. The configs sent to users specify the server name, not the IP. Therefore, if the IP changes, users won't have to generate new configs.

Secondly, although I don't plan to build a user base of several thousand, some form of load balancing is needed. I implemented a primitive scheme:

there is a location: Netherlands. It has several subdomains: neth1, neth2, neth3...
when generating a config, the user is given the subdomain with the fewest users.
currently, these subdomains point to one server
when the server load becomes significant, a new server is created and half of the subdomains are moved to it
later, additional subdomains are expected to be added

What user information I store

telegram-id, list of user keys, balance history - the necessary minimum for the billing system to function
email - purchase receipts are sent to it. Unfortunately, this is a mandatory requirement of YooKassa
IP addresses from which users connected - they are stored only within the OpenVPN logs. These logs are regularly cleared.

What about the money

I spent a long time analyzing existing VPN services, conducting surveys, and comparing rates. And in the end, I picked the prices almost out of thin air.

But! I added a small margin so I wouldn't have to raise them.

10 hours — 50₽
30 hours — 100₽
100 hours — 200₽

In the future, when a decent user base is gathered, I really want to make it 1₽ = 1 hour. It looks cheap and ~~angry~~ nice

According to my calculations, my servers can handle up to 500 man-hours per day (in theory). If there are at least 100 hours a day, I break even. 300 hours a day is already a small profit.

Launch

I found the first few clients through word of mouth. Later, I launched ads on several small channels (with a total audience of about 35,000 people). There were many clicks. But 80% of the people just entered the bot to "poke the buttons". They didn't even try to connect, let alone generate keys. It turned out that word of mouth worked better.

What I spent

13,000 rubles - design and logo development
15,000 rubles - advertising
2,500 - monthly server fee

What I got

8 active users (who have already made payments) (only two of them from advertising)
16 users who are still on their trial period
52 users who visited but never started using the service
1,350 rubles in revenue
and a little hope that the best is yet to come

A couple of funny incidents

1. An interesting client.

There was one client. On the very first day, he used up the free 5 hours. Not all at once, but in parts. He immediately bought 10 hours and hasn't logged in since. Three weeks have passed, and those 10 hours are still on his balance. I hope he's doing well.

2. False alarm.

One time I was testing updates and suddenly found that I couldn't connect from my test account. The servers were running normally. They were pingable. Everything was clean in systemctl. I sent a notification to all users that technical work was underway and there might be access problems. I started digging deeper.

It turned out there were no failures. The test account had simply run out of balance. This motivated me to implement automatic low-balance notifications as quickly as possible.

What's planned for the future

Add support for XRay (although it's not a VPN in the classic sense)
Revisit the advertising policy
Within this service, there's an idea to create a neural network to act as first and second-line technical support specialists. It's not that there's a huge need for it. I just have an idea I'd like to test. And such a small service would be an excellent testing ground.
Learn to more effectively gather feedback from potential users to understand what's deterring them or what they're missing.

Can I try it?

Yes, and it's even free (link).

You can also use the promo code HABR.

UPD

We now have a website. It's still in the draft stage, though; for the most up-to-date information, please check the Telegram bot

How I Made My Own VPN Service