Lessons from building a small VPN service around standard WireGuard clients instead of a proprietary app When you look at a commercial VPN product, the app seems to be the product: a polished interface, a country list, and a large Connect button.
I chose the opposite approach.
Instead of building another VPN client, I decided to give users a standard WireGuard configuration that they could import into an existing client.
That decision removed a lot of client-side work — but it also exposed where the real complexity of a VPN service actually lives.
Why build another app if WireGuard already has one?
The usual commercial VPN flow is straightforward: install the vendor's app, sign in, choose a location, and connect.
A proprietary client can manage server selection, subscriptions, kill switches, automatic reconnects, diagnostics, updates, and support in one place.
But for a small service with one or a few locations, I had to ask a more basic question: do I really need to build and maintain a separate Windows, macOS, Android, and iOS client just to establish a WireGuard tunnel?
WireGuard already has mature clients across the major desktop and mobile platforms.
A user can import a configuration file or scan a QR code and get a normal VPN toggle.
On paper, that looked like a very attractive tradeoff: less client code, fewer update mechanisms, fewer installers, and a smaller attack surface to maintain.
What I underestimated was that the app was never going to be the hardest part.
A .conf file is not just a settings file The first architectural lesson was simple but important: a WireGuard configuration is effectively a credential.
It contains the client's private key.
A QR code that represents the same configuration contains the same sensitive material in another form.
That immediately creates product problems that have nothing to do with the tunnel itself.
How do you show the configuration safely?
What happens if the user loses it?
Can you issue a replacement without leaving the old peer active?
How do you revoke access reliably?
What should happen when a user creates more than one configuration?
Once payments are involved, the configuration also becomes part of a lifecycle.
It may be pending, active, expired, replaced, revoked, or associated with a failed payment.
A payment provider can deliver callbacks asynchronously, and the moment a peer is added to the VPN host, that is real network access — not just a row in a database.
The supposedly simple flow of “generate a config and show a QR code” quickly turns into a small state machine.
WireGuard is simple.
The service around it is not.
One thing I like about WireGuard is that it stays focused.
It creates an encrypted tunnel between cryptographic identities and works with routing.
It does not try to solve subscriptions, account recovery, customer support, payment state, key distribution, or user experience.
That separation is good architecture, but it can be misleading during early prototyping.
You can bring up a working tunnel very quickly and feel as if most of the project is done.
In my case, the tunnel was the easy part.
Making the surrounding system behave predictably was the real work.
The user should never need to know that there is a VPN host, a web service, a database, a configuration generator, and asynchronous payment callbacks behind the scenes.
Their mental model should stay simple: payment succeeds, access works; payment fails, access is not active; renewal succeeds, nothing else is required. “Connected” is not the same as “configured correctly” Another group of problems appeared around routing and leaks.
A client can display “Connected” while the overall network behavior is still wrong.
The public IPv4 address may change while DNS requests still go somewhere unexpected.
Or IPv4 may use the tunnel while IPv6 leaves through a direct route.
That changed the way I test the service.
A successful WireGuard handshake is necessary, but it is not sufficient.
I also check the publ