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

I like the source-coverage idea a lot, especially because it makes the review step observable instead of just asking the user to “trust the draft.”

I don’t have a final metric for it yet, but I’m thinking about measuring the gap between the generated draft and the approved draft.

The useful part would be classifying edits, not just counting them: factual correction, unsupported claim, positioning/brand violation, or simple style preference. Then I can see how often the review layer catches the first three before anything reaches the publishing queue.

I’d also want a small test set with known constraints — things like “planned, not shipped,” “do not mention customer X,” or “only make claims supported by this source” — and run regeneration against those repeatedly. That gives me a more controlled signal than relying only on production feedback.

The metric I care about most is probably not “how often did the model make a mistake,” but “how often did a meaningful mistake survive review and make it into the approved queue.”

If that number isn’t very low, then the review layer isn’t doing its job.

That’s a fair pressure test, but Windows-only is a launch constraint rather than the market I’m committing to.

Windows is simply the first platform. The plan is to expand to other desktop platforms after the core Create workflow is validated, so I don’t want the current OS support to define the long-term customer segment.

I agree with the broader point though: the roadmap changes quickly depending on who adopts it. If the strongest pull comes from founders and agencies, cross-platform support becomes much more important. If it comes from regulated teams, then things like auditability, access controls, and enterprise requirements start moving up the list.

For now I’d rather validate the core workflow first, then let actual adoption tell me which branch deserves the most investment.

That matches how I’m starting to think about it as well.

The workflow has to earn the user first. If Create mode isn’t useful on its own, nobody is going to care where the credentials are stored.

The privacy/local-first question probably becomes important later, at the moment where the product asks for something more sensitive: an API key, OAuth access, or permission to publish to a real brand account. At that point it can either add confidence or create another reason to stop.

It’s still too early for me to say whether people ask about it before or after they’ve built a week of drafts — the trial has only just opened — but that’s actually a useful thing to track.

My current hypothesis is that most people will care about the workflow first and the architecture second. If they reach the point of wanting to connect publishing, then local-first has already done its job by making that next step easier to trust.

That’s a really good way to frame it: durable state vs. replaceable plumbing.

The drafts, source material, constraints, and approval history are the part I want the user to actually own and rely on. Publishing integrations should sit on top of that, not become the foundation underneath it.

If LinkedIn changes an API, a token expires, or an integration disappears entirely, you should lose convenience — not your ability to do the work.

That’s also why I want manual publishing to remain a first-class path even as Operate gets more capable. The integration can change. The workflow and the user’s state shouldn’t have to.

I think that’s exactly the right way to test it.

BYOK is probably not one value proposition — it’s a filter. For some users it signals control and reduces trust friction; for others it’s just another step between signup and the first useful draft.

So measuring abandonment before the first successful draft by segment makes a lot more sense than asking whether people “care about privacy” in the abstract.

And your last point is important too: local-first can easily become misleading if users assume “local” means nothing ever leaves the device. The boundary has to be explicit — what stays local, what is sent to the model provider during generation, and what is never sent to us.

I’d rather make that data flow understandable than rely on the local-first label itself.

Thanks for the comment! I was really looking forward to something like this xD

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.