Lock-in has a file format

Ask someone how they got locked into a piece of software and you will usually hear about pricing. The plan that doubled. The seat count. The annual commitment that renewed while nobody was looking.

That is the story people tell, but it is rarely the mechanism. Pricing is the moment you notice the lock. The lock itself was installed much earlier, quietly, and it usually has a file format.

The shape of the trap

The pattern is consistent enough to be boring. You adopt a tool because it is genuinely good at something. You use it for a year. Over that year you produce four hundred documents, and every one of them lives in a format that only that tool fully understands.

Then something changes. The price, the roadmap, the company gets acquired, or the one feature you depend on gets deprecated in favour of an AI assistant you did not ask for. You go looking for the exit, and you find that leaving does not cost money. It costs your archive.

You can export, technically. What comes out is a flattened approximation: the text without the structure, the layout without the editability, the document without the thing that made it a document. Everything you made is still visible and none of it is workable. So you stay, and you tell yourself it is because of the pricing.

The decision that trapped you was not the renewal. It was made on the first day, when you accepted a format that could not leave.

The arithmetic is worth doing before you are inside it. If rebuilding one document takes forty minutes and you have three hundred of them, leaving costs you two hundred hours. Nobody has two hundred hours, so in practice nobody leaves, and the vendor learns that their retention is excellent. Both things are true at once: the retention number is real, and it is measuring the wrong thing.

Two products, one test

We ship two products that have almost nothing in common. AtomStorm Studio turns a prompt into presentations, posters, and resumes. Atlas cleans up macOS. Different users, different problems, different technology.

They are held to the same test, which we apply before shipping anything: if a user walked away from us tomorrow, what would they be left holding?

Studio: a real file

For Studio, the answer has to be a document that outlives us. A .pptx where the text is text and the shapes are shapes, that opens in PowerPoint, Keynote, WPS, or Google Slides, and stays editable in all of them. Not a picture of a slide. Not an export that technically opens. A document that someone who has never heard of us can pick up and continue working on.

Atlas: a machine in a known state

For Atlas, the answer has to be a machine you can put back. Before it removes anything it shows you exactly what it plans to remove and why, and after it runs you can put it back. Atlas is also open source, which is the strongest form of the same promise: if we disappeared tomorrow, the tool would still be there, and somebody else could keep it alive.

Neither of these is generosity. They are both the same design constraint, applied to two different problems: do not create a position the user cannot get out of.

What this costs us

It would be dishonest to present this as free.

The editable export is the single most expensive component we maintain. We rewrote it once, and the rewrite touched fonts, text measurement, layout translation, and a long list of format quirks across four different rendering engines. A bitmap export would have taken an afternoon and would demo just as well. It would also produce a better-looking product on a shorter timeline, and approximately nobody would notice the difference until well after purchase.

Open-sourcing Atlas means anyone can fork it. Making files portable means we cannot rely on inertia to keep anyone here. Every quarter we get to find out whether people are still using our tools because they want to, which is a more exposed position than the alternative.

We think it is the correct trade, and not primarily for moral reasons. A company that keeps customers through switching costs stops learning what customers actually want, because the signal it needs is exactly the signal it has suppressed. If leaving is easy and people stay, that is information. If leaving is hard and people stay, that is nothing at all.

The strongest argument against us

There is a real counter-argument here, and pretending otherwise would be lazy.

Some of what looks like lock-in is just integration, and integration is often what makes a tool good. A design tool that knows your brand tokens, a document tool that knows your team's templates, an editor that knows the shape of your previous work: all of these produce better results precisely because they hold state that a portable file cannot carry. Insisting that everything be expressible in a neutral format is a good way to build software that is portable and mediocre.

We take that seriously. The distinction we draw is between two things that look alike from the inside:

• State that improves the tool — a system that remembers your brand colours. It produces better results precisely because a portable file cannot carry it.
• State that holds the artifact hostage — a system where the only editable form of your finished deck lives on its servers.

You can have a deeply integrated tool that still hands you a complete, workable file at the end. Those two properties feel like they trade off, and mostly they do not; what they actually trade off against is engineering time, which is a cost the vendor pays and the customer never sees on the invoice.

The test we use internally is a question about the exit rather than the experience: not "is this integration valuable" but "if the integration went away tomorrow, does the user still have something whole?"

What portability looked like when we tested it

We ran the check described at the end of this post on our own exports, which is less pleasant than it sounds.

Exporting from Studio and opening the result in four different applications produced four different kinds of wrong on the first attempt. Text that fit in one engine wrapped in another. A font that rendered correctly on the machine that made the file was substituted on a machine that had never seen it, and the substitution changed every line length in the deck. One engine handled a shape effect that another ignored entirely.

None of that showed up in our own preview, because our own preview is the one environment where everything is by definition correct. The failures only exist in other people's software, which means you only find them if you deliberately go and look. That is the uncomfortable part of taking portability seriously: it is work that produces no visible improvement in your own product, and the only way to know whether you did it is to keep leaving your own house.

AI raised the stakes

This has always been true for software. It is sharper now, because AI tools generate volume.

A person using an AI document tool seriously might produce more artifacts in a month than they previously made in a year. Decks, one-pagers, posters, drafts. The archive builds faster than anyone can audit it, and it is easy to accumulate several hundred documents before ever asking what format they are in.

There is a second thing worth watching. Many AI tools keep the interesting part on the server: the structure, the reasoning, the intermediate representation the model actually produced. What you receive is a rendered result. That is a deeper version of the same trap, because the artifact you hold is downstream of something you were never given.

Our position is that the container should be yours. Studio generates an editable HTML container and then shapes it into slides, posters, reports, or resumes. The container is the real artifact, the exports are views of it, and both are things you can take with you.

Four questions before you commit

Not about us. Apply these to any tool you are about to build a year of work on:

1. Export something real and open it somewhere else. Not the preview, not the share link. Download the file, open it in a competitor's application, and try to edit it. Whatever survives that trip is what you actually own.
2. Ask what happens to your archive if you stop paying. Read-only access? Thirty days? Nothing? The answer is usually in the terms and is usually worse than people assume.
3. Check whether the useful structure ever reaches you, or whether you only receive rendered output while the editable form stays server-side.
4. Ask what happens if the company is acquired. Nobody can promise independence forever. But a tool built on portable formats is one you keep regardless of the answer, and that is the only version of the promise that does not depend on trusting anyone.

We would rather compete on whether the tools are good than on whether leaving is painful. That is a harder position to hold, and it is the one we intend to keep holding.