DEV Community

Vlad (Volodymyr Shiyan)
Vlad (Volodymyr Shiyan)

Posted on Originally published at lockmargin.com

Why I published the format before the product

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 September 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.

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: the Ownership Manifesto (https://lockmargin.com/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 Shiyan writes the code, breaks the features, and answers the emails.

Canonical version with full references: https://lockmargin.com/blog/why-i-published-the-format-before-the-product.html

Top comments (5)

Collapse
 
kevan3010 profile image
Kevan •

Publishing the data format before the product is a strong trust move for freelancers who've been burned by subscriptions. How are you finding the first Early Access users so far?

Collapse
 
vladshiyan profile image
Vlad (Volodymyr Shiyan) •

Thanks. I'm still working on getting LockMargin in front of the right freelancers. It's early days, so I'm focusing on honest feedback and learning what people actually need before trying to scale.

Collapse
 
kevan3010 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Kevan •

Makes sense, honest feedback first is the right order.

One thing that might help with "the right freelancers": the ones who care most about "your data stays yours" are the ones posting right after a tool hurt them. A price increase on their invoicing app, a locked account, a tool shutting down. Searching "[tool name] alternative" or "[tool name] price increase" on freelancer forums brings them up, and a reply there lands at the exact moment.

That search is what I'm building FounderPulse for: it finds people who just posted about the problem you solve and drafts a first reply. Free test, no signup, at founder-pulse.com. I'd like to know if it finds your kind of freelancer.

Thread Thread
 
vladshiyan profile image
Vlad (Volodymyr Shiyan) •

That's a useful angle. Looking for people who are already dealing with the problem makes more sense than trying to convince everyone they have it. I'll check out FounderPulse and see how it works. I'll try the manual approach too.

Thread Thread
 
kevan3010 profile image
Kevan •

Glad it helps. For the manual version, the quickest search I know: "FreshBooks alternative" or "Harvest price increase" (swap in whatever tools your buyers use) on Reddit and X, newest first, last 7 days. Those people are comparing options right now, so a short reply that answers their question fits better than a pitch.

If you try FounderPulse on LockMargin, tell me if it finds the same threads as your manual search. That's the feedback I need most.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.