Why I published the format before the product

Update (22.09.2026): Windows Early Access opens November 2026 — Start in the first half, Standard in late October. The reasoning in this post is unchanged; only the date moved.

The data layer is open before the product launches. Here is why I made the schema, export formats, and decryption tool public first.

The promise that required proof

LockMargin's core promise is simple: your business keeps working even if I disappear. No license server, no account, no phone-home. The license is a signed token the app verifies offline; the token carries no expiration date.

But a promise without evidence is marketing. The honest ceiling post showed what happens when someone tries to pirate the binary — the check can be patched, the key can leak, the shell can be copied. The asymmetry that actually protects the user is not the binary. It is the data.

A cracked LockMargin is a shell. What a freelancer keeps in it — five years of invoices, clients, time entries — lives in an open SQLite format whose spec is public. The value isn't in my code staying secret. It is in the records staying readable, verifiable, and theirs.

What is open today

The data layer went public in November 2026, before Early Access opened and before the first customer paid: github.com/vladsh444/lockmargin-data-layer under MIT license.

The repository contains:

• The SQLite schema the app uses today — 33 tables across 4 groups, reconstructed from the application documentation
• Plaintext export formats (CSV, JSON) with full fidelity
• The encrypted .lockmargin container format specification
• A reference decrypt-cli in pure Python — no dependencies, verifiable round-trips
• Sample databases generated from the same schema the app uses

The decrypt-cli and scripts/build_sample.py reproduce the schema verbatim in their own SCHEMA constant, so the documentation, the samples, and the round-trip verification always agree.

Why before launch

Three reasons.

Trust is earned before the first payment. A freelancer evaluating LockMargin can verify today — without buying, without trusting me — that their data will never be trapped. They can run the decrypt tool on a sample file. They can read the schema. They can write their own importer. The proof exists before the ask.

The format is the product. In a local-first tool, the file format is the API. It is the migration path, the backup strategy, the integration surface, the exit door. Shipping the format late means shipping the product without its most important interface. Shipping it first means the interface is battle-tested by the time the first customer depends on it.

Community review catches mistakes I would miss. The schema has been public since August. Reviewers outside the project have already spotted edge cases in the encryption envelope and the export normalization; both fixes are in the app before Early Access, and the round-trip tools above are how I verify them. If I had waited until after launch, those same issues would have been customer data loss.

The cost of waiting

The alternative — keeping the format private until after launch — buys a false sense of control. It delays the only proof that matters: can a third party read the data without the app? If the answer is no, the promise is fiction. If the answer is yes, publishing early only accelerates the verification.

There is no competitive moat in a SQLite schema, and publishing it means giving up some control: someone can build a reader, an exporter, even a competing client around the same data. That is not a bug in the design. It is the point. I want to be paid for the application around the format, not for keeping the format secret. The schema is just the honest foundation.

What this means for you

If you are evaluating LockMargin: you can verify the exit door before you walk through the entrance. Clone the repo, run decrypt-cli on a sample, inspect the CSV. The format will not change without a public amendment and a migration path.

If you are building local-first software: consider publishing your format first. It forces clarity in the schema, it invites review before users depend on it, and it turns "trust me" into "verify it."

The honest ceiling post explored the binary side of the asymmetry — what happens when the app is cracked. This post is the data side: the format is open, the tools are public, the records are yours. The binary can be copied. The data stays readable.

If this resonates, read the manifesto: /manifesto.html

If you are building local-first software, where would you draw the line between an open data format and the parts of the product you keep proprietary? I'd be interested in how others handle that boundary. Vlad (Volodymyr) Shiyan writes the code, breaks the features, and answers the emails. Own your tools for $49 once, or read the manifesto first.

About the Author

Vlad (Volodymyr) Shiyan — Founder & Developer, Kharkiv, Ukraine. Building LockMargin since December 2025. Offline-first invoicing for freelancers who are tired of subscriptions. Standard is $49 one-time. Read more about Vlad →