How do I avoid being locked in again?

If you built with AI and then felt trapped by a platform, you already know the cost of lock-in, and you are right to want to avoid it with whoever you hire next. The good news is that staying free is mostly about a few deliberate choices made early. Lock-in is rarely accidental, so refusing it is largely a matter of insisting on the right things up front.

Own the three things that matter

Lock-in almost always comes down to someone else holding one of three things: your domain, your code, or your data. Keep all three in accounts you own, and most lock-in becomes impossible. Register your domain yourself. Hold the code in your own repository and add helpers as collaborators rather than letting them keep it in theirs. Keep the data on a service in your name. When these three sit with you, a partner can be added and removed like a guest, and leaving is a matter of revoking access, not begging for the return of your own business. This single principle prevents the majority of lock-in before it can start.

Insist on common tools, not private ones

Some partners, sometimes without ill intent, build on their own private systems or unusual tools that only they know well. That quietly locks you in, because no one else can easily pick the work up. Favour partners who use common, widely known tools and standards, the kind that many other people can work with if you ever need to switch. Ask directly whether the work will run on widely used technology or on something proprietary to them. Building on common ground is a choice that keeps your options open, and a partner comfortable with that choice is one who is not relying on your inability to leave.

Demand documentation as part of the job

A system only one person understands is a system you are tied to, whether or not anyone intended it. Documentation, plain written explanation of how your app is put together and how to run it, is what makes a system handable to anyone. Insist that reasonable documentation is part of any engagement, not an optional extra. It is the difference between a system you own and a system you merely possess but cannot use without its author. A partner who documents as they go is building you something you can keep. One who leaves it all in their head, deliberately or not, is building you a dependency.

Ask how you would leave, before you join

The most powerful anti-lock-in move is a single question asked before you hire anyone: if this did not work out, how would I move on from you? A confident, honest partner answers easily, describing how you would keep your code, data and domain and hand the work to someone else. Hesitation, discomfort, or an implication that you would never want to leave is the sound of lock-in being planned. Firms that lead with ownership, and Bamco is one, treat your freedom to leave as a feature, not a threat. Asking the exit question first is how you make sure the door stays open before you walk through it.