Hiring an AI Automation Engineer? Here's How I Work

On the HighLevel ideas board, one post describes business owners whose sub-accounts are "still locked with the defunct agency" after it shut down. That's the risk when you hire someone to build inside your systems. I'm Eric Forte, a GoHighLevel and n8n AI Automation Engineer based in the Philippines, and this is how I work with clients, from the first call to after launch, so you know what you're getting before you book anything.

Key Takeaways

• Before I quote, I write your brief back to you with numbered questions, and anything I couldn't verify goes on a separate list, without hours attached.
• The build runs in your accounts. I ask for the least access that does the job, and credentials live in a password manager.
• Nothing goes live until it's tested end to end, failure paths included, and the test data gets cleared out.
• During the build, updates come through the channel your team already uses, usually Slack, plus a weekly call.
• At handoff you get an operating guide, and nothing is left running on my personal logins.

What are the stages of working with an AI automation engineer?

A client build with me runs in eight stages, in this order:

1. A free 30-minute intro call.
2. Your brief, written back to you with numbered questions.
3. A written scope and quote.
4. Access set up inside your own accounts.
5. The build, with updates in your team's channel and a weekly call.
6. End-to-end testing, failure paths included.
7. Handoff with an operating guide.
8. Support after launch, if you want it.

What happens on the first call?

The first call is a free 30-minute intro call. You tell me what you want built or fixed, and I tell you if it's doable and roughly what it'd take. If it's a good fit, I put together a written scope and quote after the call.

It helps to come in knowing which tool the problem lives in and what goes wrong, like leads going missing or a follow-up that never fires. You don't need a diagnosis. I ask a lot of questions to find where it breaks. Sometimes that's one workflow. Sometimes it's two triggers firing on the same record.

If automation is the wrong tool for part of it, I'll tell you. Some steps need a person, and you'd want to know that before paying for a build around them.

How do you scope and price the work?

I scope every job before any work starts, and you get the scope in writing. Pricing is hourly or fixed, whichever suits the job, and a larger build comes with its price up front. If the scope changes partway through, I re-quote it with you. You hear about it before the invoice does.

Getting the scope right early matters. BCG surveyed C-suite executives in 2024, and nearly half said more than 30% of their technology development projects ran over budget and late. One of the top causes it named was a lack of alignment between the tech side and the business side on what the project was meant to achieve.

So the first thing you get from me is your brief, written back in my own words, followed by numbered questions. Your answers shape the quote.

Before I quote, I check each piece against the tools themselves. Can this GoHighLevel trigger see that field? Does the API return what the form needs? Anything I couldn't confirm goes on its own list with no hours next to it, because putting a number on something I haven't seen is guessing.

The audit I run on a setup before adding anything is in my post on Elon Musk's 5-step algorithm, with a real GoHighLevel example.

Whose accounts does the build run on, and what access do you need to give?

The build runs in your own accounts: your GoHighLevel sub-account, your n8n, your Make or your Zapier. The workflows live there from the first day, so they never need moving when the project ends.

On the HubSpot to ClickUp project sync, the client already ran their automations in Make, so I built the system there "to fit the existing stack instead of forcing a tool change."

For access, I ask for the least that does the job. If an admin role covers it, I don't need owner. Logins and API keys go into a password manager. They don't get pasted into Slack, email or a notes doc.

I also leave your existing workflows alone unless you've said yes to changing them. New work gets built as new. What already runs keeps running while I build.

How will you know what's happening during the build?

I work inside the channel your team already uses, usually a Slack thread. Each message gets a short headline you can scan, and I tag the person who needs to answer. Questions don't sit waiting on the wrong person. I save my questions up instead of pinging you all day, and when a piece is done you get one clear rundown of what changed and what's been tested. I also set up a weekly call with you to go over progress and anything that needs your decision. On hourly work, my time log shows what got done, with something you can check, like the changed workflow or a record count.

For bigger changes, I send you the plan first, and you approve it or tell me what to change before I build. If the work looks like it's going to land over the estimate, I tell you, along with why.

How do you test an automation before it goes live?

I test every build end to end, failure paths included. I want to see what happens when a field comes back empty or a service is down, since that's where workflows break.

Two builds where you can see the testing:

• In a Calendly to GoHighLevel booking pipeline for a lending client, the workflow waits 60 seconds after writing to GoHighLevel, reads the contact back, and checks that the form fields saved. If one is still empty, it waits 30 seconds and retries, up to three attempts before giving up.
• In the AI Lead Router for Baton Leads, testing covered the AI step too: "the first prompt gave inconsistent results, so I kept tuning it until the classification was reliable."

When I test in your live system, I only use test records you've okayed, and I delete them afterwards. Before handoff the test data comes out. Your reports and pipelines only show real leads.

If I'm replacing something that's already running, I don't rip it all out at once. In a Typeform to CRM migration, the Slack ping for qualified leads and the Hyros call stayed on Zapier for the time being, "which keeps those paths running while the team plans the full migration."

What do you get at handoff?

At handoff you get an operating guide covering daily use, how to set up the next client or record, and what to do when something looks off. You also get a short list of anything still open. And everything runs on your accounts, not mine.

It matters because your setup shouldn't depend on one person. A 2016 study by Avelino and colleagues looked at 133 popular GitHub projects and found that 65% would be in trouble if two or fewer developers left. An automation setup carries the same risk when one builder is the only person who knows how it works.

Exporting the workflows doesn't fix that. As one commenter put it in the n8n community forum, "An exported workflow alone is not enough if the client cannot renew a key, restore a backup or receive an error alert." If any connection inside them was set up with my login during the build, I move it over to an account you control before I step away.

Where it helps, the docs live right in the build. In that same Typeform migration, the replacement plan is written into the code. Whoever picks it up next can see what comes after.

What happens after launch?

After launch, the build keeps running in your own accounts, and failed steps raise an alert instead of failing quietly. I'm glad to stay on for support. If something needs changing later, I scope it with you first, the same way as the original build.

A lot of after-launch trouble can be planned for during the build:

• In the Calendly pipeline, Facebook conversion tracking runs on its own branch, so an outage on the tracking side never blocks the notification to the closer.
• In a client onboarding pipeline, edge cases with no matching payment send a Slack alert right away. Ops can sort them out while the details are fresh.
• In the bad-fit lead cleanup system, if someone removes the disqualifying tag later, DND goes off and the contact is eligible again.

Who would you be hiring as your AI automation engineer?

You'd be hiring me, Eric Forte, a freelancer working on my own. The person you talk to on the first call is the person who builds it, and nobody hands you off to someone you haven't met.

I've been working in software and automation for 5+ years and have shipped 100+ workflows. One of them is a call-qualifying system for Baton Leads that handles 16,000+ calls a month.

Frequently asked questions

What should I ask an AI automation engineer before hiring them?

Ask whose accounts the build will run on, how they handle scope that changes partway through, and what you get at handoff. If any of those answers is vague, that's the time to find out, before anything gets built.

Who owns the workflows when the project ends?

You do. When you hire me, Eric Forte, the workflows live in your GoHighLevel, n8n, Make or Zapier from day one. The credentials and the operating guide are yours too, so another developer or your own team can take over without me.

Should I give an automation freelancer admin access to my GoHighLevel account?

Give only the access the job needs. If an admin role covers the build, the owner role isn't needed. Once the work is done, you can remove the access.

Should I pay hourly or a fixed price?

It depends on the job. A quick fix is often simplest by the hour. A larger build gets a written scope and price, so you see the number before work starts, and if the scope changes, I re-quote it with you.

What happens if something breaks after handoff?

I build the error handling to raise an alert when a step fails, and the operating guide covers the common fixes. If you'd like help with the rest, just say so and I'll stay on for support.

Want to talk it through?

If you're looking to hire an AI automation engineer for something in GoHighLevel or n8n, book a free 30-minute intro call. You'll know by the end whether it's doable.

Sources

• BCG, "Software Projects Don't Have to Be Late, Costly, and Irrelevant," April 30 2024. BCG article. Retrieved 2026-11-11.
• Avelino, Passos, Hora and Valente, "A Novel Approach for Estimating Truck Factors," ICPC 2016. arXiv abstract. Retrieved 2026-11-11.
• HighLevel ideas board, post on sub-account transfers from agencies that have gone out of business, November 9 2025. HighLevel ideas board. Retrieved 2026-11-11.
• n8n community forum, "When you build n8n workflows for a client, whose account should they run on?", November 2026. n8n community thread. Retrieved 2026-11-11.