Your Convex, Your Data: Why We Built Convex Mode Without Lock-In

When we designed Convex Mode, there was an obvious simpler path: store all operational data in LaunchThatBot's own backend. One database, our schema, our control.

That would have been easier to build, easier to maintain, and -- honestly -- better for retention metrics. If your data lives in our system, leaving is harder. That is the standard playbook.

We did not do that. Here is why, and here is exactly what the alternative looks like.

The ownership model

When you enable Convex Mode, you connect your own Convex project. The data lives in your instance:

• Your Convex account, under your email and billing
• Your Convex dashboard, where you can view, query, and modify everything
• Your Convex deployment URL, which you control

LaunchThatBot installs functions and schema into your project. But the project itself belongs to you. If you disconnect from LaunchThatBot tomorrow, the Convex project still exists, the data is still there, and the functions still run.

This is not a "data export" feature that gives you a CSV dump on your way out. This is the actual production data, in the actual production system, owned by you the entire time.

Why this matters more than it sounds

Most platforms that talk about "no vendor lock-in" mean one of two things:

1. They offer an export feature that gives you a snapshot of your data when you leave. You get a zip file and figure out the rest.
2. They use open standards so you could theoretically rebuild the integration elsewhere. Theoretically.

Both of these put the burden on you at exit time. You leave, and then you deal with the migration.

Convex Mode works differently. There is no migration when you leave because your data never moved. It has been in your Convex instance the whole time. "Leaving" means disconnecting LaunchThatBot from a system you already own and operate.

What happens when you detach

People have detached from LaunchThatBot. This is what the process actually looks like:

1. You decide to manage OpenClaw independently. Maybe your team grew and you built internal tooling. Maybe you want more control. Whatever the reason.
2. You disconnect your deployment from LaunchThatBot. The management plane stops routing to your instance.
3. Your OpenClaw instance keeps running. It was always running on infrastructure you selected. LaunchThatBot managed it, but it was not hosted inside LaunchThatBot.
4. Your Convex instance keeps running. The tables, functions, and scheduled jobs are yours. They continue to execute on your Convex project.
5. You manage both independently going forward. Your OpenClaw deployment and your Convex backend are now fully under your control, with the same data and functionality they had before detaching.

There is no data loss. No migration. No "transition period" where things are broken.

Why we built it this way

We are building LaunchThatBot for indie developers and solo builders. These are people who have been burned by platforms before -- by pricing changes, by API deprecations, by acquisitions that killed products they depended on.

The only way to earn that audience's trust is to make leaving easy. If you know you can leave without pain, you are more likely to stay because the product is actually good, not because you are trapped.

This is also a forcing function for us. If our users can leave at any time with zero friction, we have to keep making LaunchThatBot worth using. There is no lock-in cushion to coast on.

The architectural decision

From a technical standpoint, using the user's Convex instance instead of our own creates more complexity for us:

• We need to handle authentication to external Convex projects
• We need to deploy and manage functions in environments we do not control
• We need to handle error states where a user's Convex project is misconfigured or unavailable
• We need to test against different Convex plan limits and configurations

All of that would be simpler if we just used our own database. But simpler for us would mean worse for you -- your data in our system, your operations dependent on our availability, your exit path requiring migration.

The added complexity on our side is worth the ownership guarantee on your side.

What this means for your decision

If you are evaluating LaunchThatBot, here is the blunt version:

• Best case: LaunchThatBot saves you significant time deploying and managing OpenClaw, and you stay because it keeps being useful.
• Worst case: LaunchThatBot does not work out for you, you detach, and everything you built -- deployments, data, automation -- continues working exactly as before.

There is no scenario where trying LaunchThatBot makes you worse off. The floor is "your stuff still works."

That is intentional.

References

• Convex docs: docs.convex.dev
• GitHub Security Advisory GHSA-g8p2-7wf7-98mq (context on why trust matters in this ecosystem): github.com