The short answer
Before you hire anyone to build automation or AI systems for your business, get clear answers to five things: is the price fixed before work starts, do you own everything at the end, is there real documentation, what happens when something breaks after delivery, and can you actually verify their track record. If any of those five is vague or “we’ll figure it out later,” that is the moment to slow down, not after you have paid.
If you have been burned before, a developer who went quiet mid-project, a demo that never became a real system, a tool you could not maintain once they were gone, this checklist is built around exactly those failure modes.
1. Is the price fixed before anything starts
Hourly billing means you do not know the final number until the invoice arrives, and the person billing you has no structural incentive to solve the problem the simplest way. A more complex build takes longer and costs more, and nobody has to decide that on purpose for it to happen anyway.
Ask for a diagnostic first: a short paid or free call where they look at your actual setup and give you a specific number, not a range, based on what they found. If a developer wants to start building before they have scoped the problem, that is a sign the price is going to move. See how we handle fixed-price scoping for what a real diagnostic looks like.
2. Do you own everything at the end
This is the single biggest source of getting burned. If the workflows, the credentials, the accounts, and the documentation live in the developer’s environment instead of yours, you do not actually own what you paid for. You are renting continued access to it, whether or not that was made clear up front.
Ask directly: “If we part ways tomorrow, what do we keep, and where does it live?” The answer should be everything, in your own accounts, from day one. If the answer involves anything staying on the developer’s infrastructure or under their login, that is a dependency you did not agree to.
3. Is there real documentation, not just a Loom video
A recorded walkthrough is not documentation. It gets out of date the moment the system changes, and it is not searchable when something breaks at 11pm and the person who recorded it is asleep.
Ask to see a sample of documentation from a past project before you sign anything. It should describe what the system does, what it connects to, what credentials it needs, and what to do when something fails, written clearly enough that someone who did not build it could actually maintain it.
4. What happens when it breaks after delivery
Every system eventually hits something it was not tested against: an API changes its response format, volume spikes past what was expected, a token expires. The question is not whether this happens. It is whether anyone finds out before your customers do.
Ask what monitoring is included, and ask specifically who gets notified and how, when a workflow fails. If the answer is “we’ll check the logs periodically,” that is not monitoring, that is hoping. Also ask what support period is included after delivery and what it covers. Ours is 30 days, with an optional retainer if you want ongoing coverage, but the specific number matters less than whether there is a clear, written answer at all.
5. Can you actually verify their track record
Anyone can put a portfolio of screenshots on a website. What is harder to fake is a specific, verifiable history: how long they have been doing this, roughly how many systems they have built, and whether you can find independent evidence of that work, a public profile with reviews, case studies with enough detail to check, references you can actually call.
Vague claims like “we’ve helped hundreds of businesses” without any specifics are a signal to ask more questions, not fewer. A developer with a real track record can usually point to specifics without hesitation.
Putting it together
None of these five questions require any technical knowledge to ask. They require slowing down before you sign anything and getting specific answers instead of general reassurance. A developer who is going to do this right will not be bothered by any of these questions. One who gets vague or defensive is telling you something.
If you want to see what specific answers to all five look like in practice, read about how we work, check what a fixed-price project actually includes, or look at a real project from diagnostic to payback. And if you want a second opinion on a system someone else built, or a diagnostic on a new project, that conversation is free.