Insights
What you actually get when I hand a system over
In short: A finished automation is more than working code. The handoff includes the system running on your own accounts, a runbook written for the person who will own it, an explicit list of the cases it refuses to handle and passes to a human, and a change log with the reasoning behind each decision. If a vendor cannot show you those four things, you are renting, not owning.
“We'll hand it over when it's done” is one of the vaguest sentences in this business. Sometimes it means a login and a wave. I'd rather show you the folder. Here is what is in it when I finish a build, whether that is a two week pilot or the first month of a plan.
The system, running on your accounts
The code lives in a repository you own. The credentials it uses sit in your password manager, not mine. The scheduled jobs run under an account with your company's name on it. If I disappeared tomorrow, nothing would stop, and nobody would have to ask me for a password. That sounds obvious. It is also the first thing to check with any vendor, because it is the easiest thing to skip.
A runbook someone else could follow
One document, written for the person who will actually own the thing, not for another developer. It answers the questions that come up at the worst moments. What does this do, and when does it run? What does it look like when it worked? What does it look like when it didn't? How do I pause it? Who do I call, and what should I have in front of me when I do?
I don't consider the runbook finished until the owner has run through it once while I sit on my hands. The places they hesitate are the places I rewrite.
The exception list
Every automation I build has a short, explicit list of things it refuses to do. Anything that moves money. Anything that goes to a customer unreviewed. Anything with legal weight. Those cases get routed to a person with the context they need to decide in a minute, and the list is a page in the runbook, not a comment in the code.
This is the most important page in the folder, and it is the one most projects don't have. A system that handles the obvious cases and quietly guesses at the unusual ones is the kind that costs you a client six weeks later.
The reasons, not just the changes
A change log that says what was built is table stakes. Mine also says why: the approach I picked, the one I rejected, and what would make me change my mind. When someone wants to extend the system a year from now, that is what saves them from re-learning the decision the hard way.
The month after
Pilots carry a 30 day repair warranty. If something inside the agreed scope stops working in that window, I fix it, and the fix goes into the runbook too. Real workflows reveal their odd cases in the second and third week, after the demo energy has worn off, so I plan on hearing from you.
Four questions for any vendor
You don't have to hire me to use this. Before you sign with anyone, ask: do I own the code and the accounts it runs on? Who holds the credentials? Could someone who never met you keep it running from the documentation? What does it do when it hits a case nobody planned for? Clear answers to those four are a good sign. A pause is information.
The packages page has a specimen of the assessment handoff, labeled as a composite, if you want to see the shape of the documents before you book anything.
If you want a straight read on which of these fits your business, book a free discovery call. If AI isn't the right tool for your problem, I'll tell you.