DEV Community: Vlad (Volodymyr Shiyan)

The Honest Ceiling of Offline License Verification

Vlad (Volodymyr Shiyan) — Mon, 07 Sep 2026 12:30:00 +0000

Originally published on lockmargin.com

Last weekend I asked myself an uncomfortable question: could someone post my app and a valid license key on a torrent, and anyone use it for free? The answer is yes. That question sat with me all weekend.
I couldn't build anything else until I mapped it, so this is the map.

Context: I'm building LockMargin, a local-first invoicing app for
freelancers. $49 once. No account. No telemetry. No phone-home of any kind. The license is a signed token the app verifies locally.

The threat model

First, I narrowed the problem. I'm not trying to stop professional cracking crews or commercial resellers. I'm trying to survive the casual kind: a key shared in a chat, an installer plus key on a torrent, "send me your key" between friends.

Then I drew a hard line. If a mechanism breaks on a new laptop, a
wiped disk, a VM - it's out. If it needs a server - out. If it needs an account - out. The app has to keep working even if my company disappears. Every option on my list had to pass that test.

The honest ceiling

Here is the fact most DRM marketing hides: if an application can
locally answer "this token is valid," then anyone holding the same token gets the same answer. Copying the authorization is always possible when verification is local.

That is not an implementation flaw. It is the architecture.

Two different things get conflated here. Authenticity: did I publish this binary? Code signing answers that. Authorization: does this person own a license? A signed local token answers that. Neither prevents a buyer from handing a valid token to somebody else.

And two different threats. Sharing is when a buyer gives their key to another person - the contractual and social layers help with that.
Cloning is when the installer and a valid key travel together. That is where the hard limit appears: if a real installer plus a real key spreads, an offline application cannot tell the new user from the owner. I say that plainly, because pretending otherwise is how DRM theater starts.

Four layers of friction

Cryptographic. Each purchase gets its own signed key. There is no master key. The buyer's name from the payment record is embedded in the signed payload; changing it invalidates the signature. The email stays optional metadata, because the app never requires it. The key is scoped to the major version: a v1 key opens v1.x forever and simply doesn't grant v2. A leaked key identifies one purchase rather than compromising the product, and its value depreciates when v2 ships. For the honest customer, friction is zero: paste the key on any machine you own.
Contractual. The license says one person, the machines they own and control. A desktop and a laptop are fine. Passing the key around is not. A contract, not a checkpoint. The application doesn't need to phone home to enforce it.
Economic. The free tier removes the biggest reason people
pirate small software: "I just want to try it." Start is free to try - up to 5 clients, 5 projects a month, unlimited invoices. No
account, no card, same encryption, same offline database. And the
paid version is $49 once. For a freelancer billing $50 an hour,
fifteen minutes hunting for a crack already costs more than the
software. There is also a hardship path: if someone genuinely cannot pay, they write to me. That's a personal decision, not a policy.
Social. The app shows "Licensed to: your name" in Help.
Passing an abstract key is easy; passing a key with your own name
signed into it is a different social operation. And transparency
works as soft enforcement: the people who care about the no-DRM
promise are probably not the people I'm trying to stop in the first place.

The snake oil I refused

Hardware binding was on my first shortlist. Then I pictured the
support email: "I wiped my disk and now your app thinks I'm a
pirate." I would be my own first support ticket, while a determined pirate just removes the check. I killed it that afternoon.

An offline lease - "the key remains valid for 90 days offline" -
would effectively turn my perpetual license into a subscription, and it still clones with the disk.

An activation counter without a server is a local variable. Whoever clones the state clones the count. Without an authority outside the copied state, the counter isn't enforcement. It's theater.

Obfuscation and anti-tamper raise the cost of cracking for hours and add antivirus false positives and VM problems for years. For a solo developer, the support bill exceeds the benefit.

Every one of these buys a little piracy resistance and charges it to the honest user. Some of them are reasonable choices for other
products. For my constraints, all four failed.

What I took from the products I studied

Sublime Text gave me the closest precedent: a per-user license
entered offline, no connectivity prerequisite, an honor system that has survived for years. BBEdit showed me that a version boundary can be explicit without pretending an upgrade is the same entitlement - perpetual license, paid major upgrades, usable free mode. Affinity showed that one-time, version-scoped ownership can work at scale, and that I don't want the account machinery they use to run it.
Plasticity is my opposite example: once you introduce seat
management, you're back to managing activation state - the thing
ownership promises to abolish.

None of them satisfies all five of my constraints. That's fine. The combination I ended up with - perpetual, version-scoped, locally verified, zero activation state, zero account, zero telemetry - is deliberately unusual.

The calculation

I kept coming back to one conclusion: if I make piracy harder by
adding friction, my honest customers are the ones who pay for it.
Piracy exists; I'm not pretending otherwise. I just won't make every honest customer pay in friction to stop a small number of casual pirates.

The stack I shipped

Unique per-order signed tokens with the buyer's name and the major version in the payload, verified locally. A license that reads like a contract. The free Start tier as the legal alternative to a leaked key. "Licensed to: your name" in Help. No activation server, no revocation server, no telemetry.

Five layers - and after that weekend, no sixth. I'll admit I kept
looking for one more technical trick, some way to make a copied key less useful without a server. I spent more time on that search than I probably should have. There wasn't one.

And one principle above the stack: a valid license should never
depend on the continued existence of the company that issued it.
Servers vanish, founders vanish; the copy you bought keeps working. That's not a feature - that's the product.

If you ship offline software, where do you draw the line between
protection and punishment - and what did I miss? I'd especially like to hear from people who tried hardware binding or offline production: what actually happened?

Why I Chose SQLite Over PostgreSQL

Vlad (Volodymyr Shiyan) — Mon, 24 Aug 2026 12:47:16 +0000

Why I Chose SQLite Over PostgreSQL

I chose SQLite over PostgreSQL because LockMargin is a desktop app that runs on the user's machine — not on a server. SQLite is embedded, zero-config, single-file, and requires no administration. PostgreSQL is a server database. For a freelancer who just wants to send an invoice, asking them to install PostgreSQL isn't a product. It's a sysadmin job.

The Decision Point

December 2025. I had the basic app working — create a client, generate an invoice, export to PDF. But I needed a database. Two options:

SQLite — embedded, single-file, zero-config
PostgreSQL — server-based, multi-user, enterprise-grade

I'd spent 20 years building systems with PostgreSQL. I knew it. I loved it. But I chose SQLite. Here's why.

The Conversation

Vlad: I was leaning toward PostgreSQL. It's what I know. It's what I've used for factories, retail chains, service companies. It handles concurrency, transactions, complex queries. Why would I downgrade to SQLite?

Jon: Because you're not building a factory system anymore. You're building a desktop app for one person. PostgreSQL is a server. Where's the server going to run?

Vlad: On the user's machine?

Jon: Then you're asking freelancers to install PostgreSQL, configure it, manage backups, handle updates. That's not a product. That's a sysadmin job. I wouldn't install it myself, and I'm a backend engineer. Imagine an accountant from Zhytomyr who last saw a command line in 2009.

Vlad: Fair point. But SQLite — isn't it just for prototypes?

Jon: No. SQLite is in every phone, every browser, every operating system. It's the most deployed database in the world. Apple uses it. Google uses it. Every Android phone has dozens of SQLite databases. It's not a toy. It's a tool. I lost three days in 2019 trying to set up PostgreSQL replication for a startup that shut down a month later. SQLite would have saved those days.

Vlad: What about concurrency? Multiple users?

Jon: Your app has one user. The freelancer. They're not sharing the database with 50 colleagues. SQLite handles single-user workloads perfectly. For multi-user, you'd need a server — which brings us back to PostgreSQL. But you don't want a server.

Vlad: Right. Offline-first. No cloud. No server.

Jon: Exactly. SQLite is the database for offline-first apps. I'd say — for people who are tired of Docker Compose.

The Technical Comparison

Let's get specific. Here's how SQLite and PostgreSQL compare for LockMargin's use case:

Dimension	SQLite	PostgreSQL
Installation	Zero (embedded)	Required (server)
Configuration	None	Complex (pg_hba.conf, postgresql.conf)
Administration	None	DBA needed for production
Storage	Single file (.db)	Multiple files, tablespaces
Backup	Copy the file	pg_dump, WAL archiving
Concurrency	Single-writer, multi-reader	Multi-writer, MVCC
Scalability	Limited to one machine	Unlimited (clustering, replication)
Cost	$0	$0 (self-hosted) or $5-50/month (managed)
Performance (single-user)	Faster (no network)	Slower (network overhead)
Performance (multi-user)	Limited	Excellent
Offline support	100%	Requires server connection
Data portability	Copy the file	Export/import required

For LockMargin, SQLite wins on every dimension that matters.

The Benchmarks

I ran some tests. Here are the results for typical invoicing workloads:

Test Setup

Hardware: M2 MacBook Pro, 16GB RAM
Database: 1,000 invoices, 500 clients, 200 recurring invoices
Operations: SELECT, INSERT, UPDATE, complex JOINs

Results

Operation	SQLite	PostgreSQL	Winner
Simple SELECT (1 row)	~0.3ms	~1.2ms	SQLite (~4x faster)
Complex JOIN (5 tables)	~2.1ms	~3.8ms	SQLite (~1.8x faster)
INSERT (1 row)	~0.5ms	~2.1ms	SQLite (~4x faster)
UPDATE (1 row)	~0.4ms	~1.9ms	SQLite (~4.7x faster)
Backup (full database)	~5ms (copy file)	~2.3s (pg_dump)	SQLite (~460x faster)
Restore	~5ms (copy file)	~1.8s (psql)	SQLite (~360x faster)

Why SQLite is faster: No network overhead. No server process. No connection pooling. The database is in the same process as the app. I checked three times because I didn't believe it. The third time I just used a stopwatch — copying the file in Finder took less time than opening a terminal for pg_dump.

Why PostgreSQL is slower: Every query goes through a socket, even on localhost. Connection setup takes time. MVCC adds overhead. It's like calling your neighbor through long-distance.

The Trade-offs I Accepted

Choosing SQLite means accepting some limitations:

Trade-off 1: Single-writer concurrency

Problem: Only one process can write to the database at a time.
Reality: LockMargin is a single-user app. The freelancer is the only writer. This is not a limitation — it's the correct model. I once tried opening the database from two windows simultaneously. Got an error. Thought: "Why would I need two windows?" Closed the second one. Problem gone.

Trade-off 2: No built-in replication

Problem: Can't replicate the database to another server.
Reality: Backup is a file copy. Sync is a file copy. Replication isn't needed. I copy lockmargin.db to a USB stick once a week. That's my "replication." Been doing it since 2012, when I saved tax returns the same way.

Trade-off 3: Limited data types

Problem: No JSONB, no arrays, no custom types.
Reality: Invoicing data is relational. Clients, invoices, line items, payments. SQLite's type system is sufficient. I spent three days wondering if I needed JSONB for settings. Then I just made a separate table. Works fine.

Trade-off 4: No stored procedures

Problem: Can't write complex logic in the database.
Reality: Business logic belongs in the app, not the database. This is a feature, not a bug. I've seen what happens when logic is smeared between SQL and code. Don't want to repeat that.

The Migration Story (What If We Switched?)

Vlad: What if we needed to switch to PostgreSQL later? Could we migrate?

Jon: Yes. SQLite to PostgreSQL migration is straightforward. The SQL is 95% compatible. The main differences: data types (SQLite is flexible, PostgreSQL is strict), some functions (date handling, string operations), concurrency model (WAL mode vs MVCC). I did one myself in 2021. The hardest part was explaining to the client why "just migrate" took a week.

Vlad: How long would migration take?

Jon: For LockMargin's schema? Maybe 2-3 days. Most of the work is testing, not rewriting. Or 2-3 hours if you're Vlad and do everything at night, then break production and fix it until morning.

Vlad: So we're not locked in.

Jon: No. SQLite is a starting point, not a prison. If you outgrow it, you can migrate. But for 99% of freelance apps, you won't outgrow it. I know. I counted.

The Real Reason

Here's the honest truth: I chose SQLite because I didn't want to explain to a freelancer why they need to install PostgreSQL.

Imagine the onboarding:

Download LockMargin ✓
Install PostgreSQL ✗
Configure pg_hba.conf ✗
Create a database ✗
Set up backups ✗
Handle updates ✗

That's not a product. That's a barrier to entry. I'd close the tab at step two.

With SQLite:

Download LockMargin ✓
Open it ✓
Your data is in a single file on your desktop ✓

That's a product. I opened lockmargin.db in DB Browser to check. A file. 2.4 megabytes. Everything I created in a month. Copied to a flash drive in 3 seconds. That's my backup strategy.

When PostgreSQL Is the Right Choice

I'm not saying SQLite is always better. PostgreSQL is the right choice when:

Multiple users need concurrent access
Complex queries with JSONB, full-text search, geospatial data
High availability with replication and failover
Large datasets (terabytes, billions of rows)
Enterprise requirements (audit logs, row-level security)

For those use cases, PostgreSQL is unbeatable. But for a freelancer managing their own invoices? SQLite is the correct tool. I spent 20 years proving the opposite to clients. Now I'm proving it to myself.

The Lesson

Choose the database that matches your architecture, not the one you know best.

I knew PostgreSQL. I loved PostgreSQL. But PostgreSQL is a server database, and LockMargin is a desktop app. The architecture demanded SQLite.

If you're building:

A web app with multiple users > PostgreSQL
A mobile app > SQLite (or Realm)
A desktop app > SQLite
An offline-first app > SQLite
A data warehouse > PostgreSQL (or ClickHouse)

Match the tool to the job. I spent a week convincing myself PostgreSQL "would work too." Spent two more days on a Docker container. Then deleted everything and ran cargo add rusqlite. Works.

What's Next

This is post #2 in the Building LockMargin series. Next up: the first time I dogfooded my own product, and what broke. Spoiler: I broke PDF export at 2 AM before a deadline. But that's another story.

Follow the series at Building LockMargin.

Frequently Asked Questions

Is SQLite production-ready?

Yes. SQLite is used by Apple, Google, Microsoft, and every major browser. It's the most deployed database in the world. It's not just production-ready — it's production-proven. I don't trust "proven" in marketing, but here — facts. Billions of devices.

Can SQLite handle large datasets?

SQLite can handle databases up to 281 TB. For invoicing, you'll never hit that limit. Most freelancers have thousands of invoices, not millions. I checked: my database after 4 months is 2.4 MB. After 10 years — maybe 60 MB. Smaller than one phone photo.

What about data corruption?

SQLite uses WAL (Write-Ahead Logging) mode by default, which prevents corruption even if the app crashes mid-write. I've never lost data to corruption in 6 months of daily use. I once dropped my laptop. The database was fine. The laptop — cracked. Priorities.

Can I use SQLite with Rust?

Yes. The rusqlite crate is excellent. It's safe, fast, and well-maintained. LockMargin uses rusqlite for all database operations. I tried sqlx. Then Diesel. Went back to rusqlite. Just works.

What if I need to sync across devices?

SQLite doesn't have built-in sync. For LockMargin, sync is a file copy (USB, cloud storage, etc.). If you need real-time sync, you'd need a server — which defeats the offline-first purpose. I copy the file. Not perfect. But works. Like everything else in this post.

P.S. — Jon agreed to stay anonymous. But he's real. We had coffee at a cafe in Berlin in 2019. He said then: "All scaling problems are solved by not scaling." I didn't understand then. I did in December.

The Bottom Line

SQLite isn't a compromise. It's the correct choice for offline-first desktop apps.

PostgreSQL is a server database. It's powerful, flexible, and enterprise-grade. But it requires a server, administration, and maintenance. For a freelancer who just wants to send invoices, that's overkill.

SQLite is embedded, zero-config, single-file, and fast. It's the database that gets out of your way and lets you build your product.

I chose SQLite because I wanted to build a tool, not a sysadmin job. And six months later, I'm glad I did.

I build LockMargin - a local Financial OS for freelancers. No cloud, no subscription, no account. $49 once.
Canonical: https://lockmargin.com/blog/why-i-chose-sqlite-over-postgresql.html