Journal

2 min read

Own your stack: why your automation should run on accounts you control

The fastest way to get locked in is to let someone build your automation on their accounts. If you cannot see the keys, you do not own the system. Here is the test, and why it is non-negotiable.

Own your stack: why your automation should run on accounts you control

There is a quiet decision buried in every automation project that matters more than which model or which tool you pick: whose accounts does it run on? Get this wrong and you do not have an automation. You have a hostage situation with a monthly invoice.

How lock-in actually happens

It is rarely dramatic. A vendor or agency builds your workflows, your agents, your integrations, all on their cloud, under their API keys, behind a login only they hold. It works great. Then the price changes, or the relationship sours, or they simply go quiet, and you discover that "your" system was never reachable without them. Proprietary, poorly documented, and painful to move. That is the trap, and it is built on convenience, which is exactly what makes it easy to walk into.

"It is your data" is not the same as "you control it"

Most contracts will say you own your data. Fine. But ownership on paper and control in practice are different things. If your embeddings, your conversation history, your automation logic and your keys all live on someone else's infrastructure, you rely entirely on their uptime, their roadmap, and their goodwill. You can own the data and still be unable to touch it without asking. Real control means the thing runs on accounts with your name on them.

The test: can you see the keys?

Here is the whole thing in one question. Can you log into the cloud it runs on, read the code, and see the API keys, right now, without asking anyone? If yes, you own it. If you have to request access to your own system, you do not. Everything else, the demos, the dashboards, the reassurances, is decoration on that one fact.

What ownership costs you, and saves you

Owning your stack has a real trade-off. Someone has to build it properly and document it, and that is more work than spinning up a rented black box. It is slower on day one. But it is yours on day thirty and day three hundred. If the people who built it vanish, nothing breaks and nothing is locked. Anything self-hosted stays open source. When you scale, more work does not quietly add per-seat rent. And when a security review happens, you can actually see what is running.

That is the standard we build to, and it is not generosity. It is just the correct way to hand someone a system: your cloud, your repos, your keys, documented so the next engineer takes over without a phone call. We cannot lock you out of your own building. That is the point.

About the author

Amine Lamfichekh · CTO, Kaishift

Amine scopes and architects every Kaishift engagement. These notes come from the builds: what shipped, what broke, and what it cost.

Meet the team

let's talk about your goals and the best way to reach them

One team in Casablanca answers you the same day.

Amine LamfichekhCTOBook a call

Contact

let's talk about your project

Prefer a call? Book 30 minutes

Write to usWe answer the same working day.