For a lot of small businesses the honest answer is: not much, and nobody has checked. Two questions settle it, and both are free. Where does the data physically live and whose account is it in, and what could you export if you stopped paying, in what format. Ask them before you commit, because they are close to impossible to reconstruct two years later, which is exactly when you will need them.
Nobody decides to get locked in
Lock-in is almost never a decision. It accumulates.
Something you built as a trial keeps working, so it keeps running. A month later it is part of the routine. A year later it is doing the quoting, or holding the customer list, or deciding which jobs get followed up, and nobody has ever asked where any of that actually sits.
The reason this happens now, and did not much before, is that building has become easy. You can describe an internal app and have something working the same afternoon, with no technical background at all. I think that is mostly a good thing. I would far rather an owner spent two hours building something real than another two hours in a webinar about the future of work.
But the app has to keep your data somewhere. And the default somewhere usually belongs to whoever built the builder.
Nothing in the process stops to tell you that. There is no moment where a screen says: by the way, your customer records will now live in our database, in a region we choose, under our terms. It just works, which is the whole appeal, and which is also the problem.
What large companies made vendors change
There is a useful signal in how the enterprise end of this market has moved.
Big customers did not respond to AI app builders by asking for a smarter model. They asked for something much more boring: that the application and its data sit inside their own cloud account, under their own security, encryption and audit controls, with the model treated as a swappable component rather than the thing everything is built around.
A concrete example reported in 2026: AWS and the app-building startup Superblocks struck a deal letting the tool run inside a customer's own AWS environment, with each app spinning up its own database inside that customer's account rather than an external one by default. The point of the arrangement was not performance. It was that the app inherits the controls the customer already has, instead of becoming something built and hosted outside the business's own visibility.
The same argument has been made publicly by senior people across the industry on two fronts: use more than one model so you are not exposed to one vendor's pricing or direction, and be careful about how much of your operating detail you hand to any single provider.
A small business has no leverage to demand any of that. It does not need any. It can ask the same two questions, and the questions cost nothing.
The two questions
One. Where does the data physically live, and whose account is it in?
You are asking three things at once: which company controls the storage, which country or region it sits in, and whether it is inside an account you hold or one the vendor holds. All three matter, and all three are usually answerable in a support chat in about ten minutes.
Two. If you stopped paying tomorrow, what could you take with you, and in what format?
This is the question that does the work. A vendor that can hand you a clean export of your records in a common format is a vendor you can leave. One that can only offer screenshots, or a PDF, or nothing at all, is one you cannot, whatever the contract says about ownership. Owning your data and being able to get it out are different things, and only the second one is useful on the day you need it.
Neither question is an accusation. Most vendors are perfectly reasonable and most answers are fine. The point is not suspicion. It is that the answer is trivially easy to obtain before you commit, and very hard to establish once you are three systems deep and it is Friday afternoon.
Why this is a governance question, not a technology one
The framing we use at Handiwork is this: a dependency you cannot exit is not a tool, it is a term of business you never negotiated.
That is why we ask both questions before recommending anything, because the answers change the recommendation. A tool with an ordinary export path and a clear data location is a reasonable thing to build a process on. A tool with neither is fine for an experiment and a poor place to put your customer list.
It sits alongside the other quiet governance questions that turn up in small businesses: which agreement actually governs your business files, what your AI assistant can reach and under whose login, and whether your setup would survive losing the machine it lives on. None of them are dramatic. All of them are cheaper to answer early. The broader picture is in our guide to using AI safely in a small business.
If you would rather have someone work through it with you, that is part of what our services cover.
What to do this week
If you have built something in an afternoon and it is still running, give it ten minutes.
Write down the answer to both questions. Put the file somewhere you will find it again, next to your other supplier records.
If the second question has no answer, you have not bought a tool. You have rented a dependency. That might still be the right call, and plenty of rented dependencies are worth it. But it should be a decision you made, not one that accumulated while you were busy.
Ready to find out where you stand?
If you want a straight look at what your business already depends on and what leaving would cost, our free AI Readiness Check takes about five minutes: AI Readiness Check.
Frequently asked questions
Is vendor lock-in really a risk for a small business?
The risk is rarely that a vendor behaves badly. It is that your options narrow: a price rise, a feature removal or a company being acquired becomes something you absorb rather than respond to, because leaving is not practical.
What counts as a good export?
A file you could open and use somewhere else. A spreadsheet of your records, or a standard data file, is good. A PDF report or a set of screenshots is not, because the structure is gone.
Should I avoid no-code AI app builders then?
No. They are genuinely useful and the speed is real. Just know the two answers before you put anything that matters into one, and keep your own copy of the data that would hurt to lose.
Does using more than one AI model help?
It reduces exposure to a single provider's pricing and direction, which is why large buyers have pushed for it. For most small businesses the bigger and simpler win is where the data sits, not how many models are behind it.
How often should I revisit this?
Once a year, and any time a tool moves from experiment to something the business relies on. That transition is the moment the question changes from interesting to important.
Ready to find out where you stand?
Take the free five-minute AI Readiness Check. There is no pitch at the end of it.
Take the AI Readiness CheckSources
- AWS is helping vibe-coding startup Superblocks, and the implications are big — TechCrunch, https://techcrunch.com/2026/08/03/aws-is-helping-vibe-coding-startup-superblocks-and-the-implications-are-big/



