I built a local-first content operator because social AI tools wanted too much access

Yes, thank you for the comment. The fear of losing personal data is precisely one of the key factors behind the creation of this product.

I like that framing a lot.

It turns the first-session question from “do you care about local-first?” into something much more concrete: “can this produce a draft you would actually trust enough to publish?”

Keeping OAuth out of that test also makes the signal cleaner. If a user can give it one trusted source, one brand constraint, and one destination, and the draft consistently needs only minor edits, then Create has already proven useful on its own.

I also like the idea of tracking critical edits rather than just whether someone generated a draft. A regeneration count or “looks good” reaction is weak evidence, but needing fewer than one or two substantive corrections before publishing feels much closer to real value.

If that holds over repeated sessions, then local-first can stay where it probably belongs: as a trust and reassurance layer, while the quality of the draft is what actually earns adoption.

Exactly. I think that’s the distinction I’m trying to preserve as well.

The manual path shouldn’t feel like a degraded mode that exists only because an integration is missing. It should remain a first-class workflow: create, review, export, and publish however you want, without giving the product control over the destination.

Then OAuth and automation become optional accelerators rather than dependencies the whole product is built around.

Your DictaFlow example is a good parallel. If the core job still works when the “ideal” integration path is unavailable, the product is much more resilient — both technically and strategically.

And yes, platform policy risk is a big part of that. I’d rather have integrations improve the workflow than define whether the workflow is possible at all.

That distinction makes a lot of sense: local-first protects the data boundary, but it doesn’t protect you from a bad model output.

That’s also why I want Create and Operate to stay separate. A draft should be something you can inspect, regenerate, edit, and reject without any publishing permissions connected at all. Automation only makes sense after you trust how the system behaves with your knowledge base.

Your “planned feature, not shipped” example is exactly the kind of case I think needs to be pressure-tested. If a regeneration can silently lose that constraint, then the system has failed even if every file and credential stayed local.

So one of the things I’m looking at is how reliably those source constraints survive across regeneration and different content formats, rather than treating the knowledge base as context the model can loosely interpret.

And I like the way you framed BYOK friction: for some users it’s friction, for others it’s evidence that the product isn’t asking them to hand over everything before they can trust it.

This is probably the most useful pushback I’ve gotten on this so far.

I think your point about privacy being more of a retention/trust factor than an acquisition driver is a good one. I may be overestimating how much users care about it before they’ve experienced the product.

The BYOK friction is also something I’m watching closely. I chose it because I didn’t want to sit between the user and their model provider, but I agree that “bring your own key” can become a very real adoption barrier, especially for less technical users.

And yes, Windows-only is a limitation right now. That’s mostly a consequence of starting narrow rather than a belief that Windows is the ideal long-term market.

Your point about charging for Create mode is especially interesting. I’ve been thinking about Create and Operate as two parts of the same product, but there’s a strong argument that Create should prove its value independently first.

If people won’t pay for the research-to-draft workflow on its own, adding publishing and automation probably won’t fix the core value problem.

That’s a test I’m seriously considering now. Thanks for being direct about it.

Yes — that’s exactly the kind of problem I ran into, and it’s why I separated content creation from account connection and automation.

You don’t need to connect any social accounts just to create and refine content. You can work on drafts inside the app first, check that the output respects the source material and its constraints, and then publish or move that content wherever you want.

The same idea applies to automation. Before anything is scheduled or runs automatically, you can test the workflow, review the output, and make sure it behaves the way you expect.

For me, the order is important: first make the content trustworthy, then decide how much automation you want to give it.

Not yet — it’s too early for me to claim that I’ve seen users choose it specifically because of the local-first architecture.

The decision initially came from my own concerns as a developer. I’m not very comfortable with putting API keys, account tokens, business knowledge, and other sensitive data into another developer’s infrastructure if it isn’t necessary.

So I built Content Operator in a way that gives users the option to keep that data on their own device instead of on WeMAIde servers.

The tradeoff is exactly what you pointed out: local-first and BYOK add some setup friction. What I’m trying to learn now is whether privacy is a strong purchasing reason by itself, or whether it works more as a trust layer that makes people comfortable enough to adopt the workflow in the first place.