Hand workspaceisolated and readyI have spent years building websites, automations and other digital projects. And almost every project began with the same ritual. Before I could make anything useful, I first had to assemble the technical toolbox.
Create account. Confirm email. Find the API page. Generate a key. Copy the secret. Store it safely locally or in a secret store. Check the permissions. Then hope that three months later you still remember which key was for what.
How my project setup used to work
If I was building a website that needed GitHub, Cloudflare, email, analytics and perhaps a database, I normally had to arrange access to all of those services first. Sometimes that meant OAuth, but often it also meant individual API keys, tokens or secrets that had to be stored safely somewhere.
That was annoying enough for my own projects. Client work made it more awkward. Eventually the client should be able to take the project back under their own control. I do not want a website to remain dependent on a folder on my laptop, my personal accounts or a collection of keys that only I understand.
The frustrating part was not any single step. It was all the little steps together. They created very little value for the client, but they consumed time and attention on every project.
One rule does not change: secrets never go to GitHub
GitHub is for your code and change history, not for API keys, tokens or passwords. If a .env file contains secrets, it should stay out of version control — for example through .gitignore. Secrets belong locally, in a dedicated secret store or in the protected environment of your Hand.
GitHubCode and non-secret configurationHands does not change that rule. The advantage is that supported apps require much less manual secret handling because the connection can use OAuth or another protected connection path.
What OAuth changes for me
With Hands, we have already built the connection layer for many of the apps I use most often. Instead of first finding where a provider hides its API key and figuring out how to pass it around safely, I connect a supported app and go through that provider's OAuth permission flow.
OAuth sounds technical, but the practical difference for me is simple: I no longer need to move the password or API key between systems myself. I authorize the connection with the provider and attach that account to my Hand.
“Look at the website in GitHub, check in Analytics which pages get the most traffic, and make a clearer version of the most important landing page on dev.”
That is the real gain for me. I spend less time preparing tools and more time saying what I actually want to achieve.
Speed without giving up control
Fast connections would not be very useful if that meant an AI could suddenly do anything everywhere. The second half matters just as much to me: for each Hand, I choose which apps to connect and what I am comfortable letting it do inside them.
An app may request broad permission during connection while the Hand itself still operates within smaller boundaries. I can let some actions happen automatically and require a review or confirmation before more sensitive work goes ahead.
- Only the apps the work needs. A Hand does not need automatic access to everything I use.
- Different freedom for different actions. Reading can be automatic while publishing or changing something can still require my approval.
- The connection belongs with the Hand. Not with a loose text file full of secrets sitting on my laptop.
My laptop is no longer the workplace everything depends on
The other big change is that my own computer no longer needs to be the place where the entire project lives. Every Hand has its own isolated Linux workspace. That means my laptop does not have to keep a local IDE, terminals, processes and project folders running just so an agent can work.
It also changes where I can work. I can start a larger build task from my computer, check the result from my phone later, and continue again without keeping the same laptop alive as the working environment the whole time.
That sounds like a small distinction, but for me it is a big one. The Hand has its own workspace; I use whatever device is convenient to give direction, review the work and issue the next request.
Why this may matter even more for client work
When I build something for a client, I ultimately want to leave behind something the client owns. Their domain. Their GitHub. Their Cloudflare. Their accounts. Their data. Not a website that only keeps working as long as my laptop, my personal API keys or my local configuration stay around.
With a good Hands setup I can work with the accounts and connections that belong to the project from the start. The client can later manage their own access and keep using the Hand without me first organizing a technical treasure hunt to transfer every secret and local configuration file.
For me, that is the bigger shift behind Hands. AI can already write code, research and build automations at extraordinary speed. But if every request begins with manually installing and connecting half a toolbox, a lot of that speed disappears into setup again.
Not: “Which accounts, keys and local configuration do I need to set up first?” But: “Which apps does this Hand need, how much freedom do I want to give it, and what do I want it to do?”
Connect the apps you need. Keep control of the boundaries. Then just start with the task.
Explore the available apps, connect only what the work needs and decide how much freedom feels right for each Hand.