I build AI automation systems and CRM integrations that scale your business, not your headcount.

Ranges are wide because "automation" covers everything from a single Zapier fix to a system that runs a whole business function. A one-off workflow lands in the hundreds. A real build, meaning integrations, error handling, and something your team can operate without me, typically runs 3k to 10k depending on how many systems it touches and how bad the data is going in. I quote after seeing your stack, never before, because most of the cost sits in edge cases nobody raises on a first call.

Fixed fee for anything with a definable end, which is most builds. You get a number before work starts, and if I estimated badly that is my problem rather than your invoice. Hourly only for exploratory work nobody can honestly scope yet, usually an audit of an existing mess. Retainers make sense in exactly one case: the system genuinely changes month to month and you want someone holding it. If your system is stable and someone is selling you a retainer, they are selling you insurance you probably do not need. Scope changes get repriced in the open, not absorbed quietly and resented later.

It depends on whether your problem is technical or organisational. An agency earns its fee when several disciplines have to run in parallel, design and copy and paid media alongside the build, or when procurement needs a company with insurance and a support agreement. The tradeoff is that the person who sold you the project is usually not the person building it, and the build lands with whoever happens to be free that week. An independent builder is the better bet when the work is genuinely technical, because you talk to the person writing the workflows and nothing is lost in the handoff. Ask either one the same question: who specifically writes this, and can I speak with them before I sign.

The useful version audits where your operation loses hours to manual coordination, decides which of those are worth automating and which honestly are not, then builds and hands over the systems. That last part separates consultants from contractors. Plenty will produce a recommendations deck and leave you with the original problem plus an invoice. Ask whoever you are evaluating to show you a system they built that is still running a year later, and to tell you who maintains it now. If that answer is vague, you are buying slides.

Production evidence, not demos. Ask what happens when the model returns something unexpected, where tool calls get logged, how spend per run is capped, and exactly which actions need a human to approve. Each of those has a specific answer if the team has shipped agents against real systems, and a hand-wave if they have only built prototypes. Ask what they refuse to automate, too. Anyone who says yes to everything has not had an agent running against a live CRM at 2am. Framework choice, LangChain or CrewAI or something custom, matters far less than whether the guardrails exist at all.

Building an agent that has tools, memory, and permission boundaries, rather than a chatbot answering from a prompt. The agent gets a goal, a defined set of actions it may take against your systems, and constraints on what it can do without approval. In practice that means LangChain, CrewAI, or a custom framework, plus the unglamorous parts: logging every tool call, capping spend per run, and deciding exactly where a human signs off. Off-the-shelf agents demo beautifully. The difference in production is entirely in the guardrails.

You never migrate straight across. Export, map fields into a staging layer, then run a dry pass against a sandbox so you can see exactly what breaks before anything is live. Deduplication rules get agreed before records move, because two systems always disagree about the same contact. Custom fields, activity history, and file attachments are where migrations quietly lose data, so those get validated by row count and by spot check. Both systems run in parallel until the numbers reconcile. Cutover is the boring part when the mapping was done properly.

GoHighLevel, HubSpot, Salesforce, Zoho, Pipedrive, ActiveCampaign, Close, Microsoft Dynamics, and Monday or Airtable when a team is using one as their CRM. Integration work is rarely limited by which CRM you picked. It is limited by what the API exposes and how aggressively it rate limits. Salesforce and Dynamics expose almost everything and charge for the privilege. GoHighLevel and Pipedrive are faster to wire but have gaps you design around. If a platform has an API it can be connected. The real question is what keeping that connection stable costs.

Far less API work than people expect and far more decision work. Salesforce exposes nearly everything through its REST, Bulk, and Streaming APIs, so connecting it is rarely the hard part. The hard part is agreeing which system owns a record, deciding what happens when both sides edit the same field, and handling the objects your org has customised over a decade. Sandbox first, always, because validation rules and required fields will reject writes that passed cleanly in your test payload. Watch the daily API call allocation on lower editions too. A sync built without batching can burn through it before lunch.

One clean integration between two systems with decent APIs is usually days, not weeks. Full CRM architecture, meaning migration plus multi-platform sync plus the automation layer on top, runs two to six weeks depending on data quality and how many people have to agree on field definitions. The build is rarely the slow part. Waiting on API credentials, settling which system is the source of truth, and cleaning historical records account for most of the calendar. Projects that slip almost always slipped on decisions, not on code.

Connecting systems that were never designed to talk, then keeping that connection alive. Concretely: authentication and token refresh, mapping fields between two different data models, handling rate limits and pagination, retry logic with backoff, a queue so nothing is lost while the other end is down, and alerting that names the record which failed instead of just announcing that something did. The connection itself is often a day of work. Everything listed after it is what separates an integration that survives a year from one that stops silently on a Tuesday. If a quote never mentions error handling, you are buying the first day only.

Zapier when the flow is short, linear, and needs to be live today. Make when the visual layout genuinely helps whoever maintains it and the branching is moderate. n8n once you have real conditions, need self-hosting for data residency, or your Zapier invoice has started to resemble a salary. Migrating Zapier into n8n is the single most common request I get, usually triggered by cost or by one fragile flow failing silently for a month. Self-hosted n8n has no per-task pricing, which is the whole argument at volume.

The server, and very little else. A small VPS handling a few thousand executions a day sits somewhere between 10 and 40 dollars a month, and self-hosted n8n charges nothing per task, which is the entire argument once volume climbs. n8n Cloud is the better choice below a few thousand executions a month, or when nobody on your team wants to own a server. The cost people forget is upkeep: version upgrades, moving to queue mode when one instance stops coping, backing up the workflow database, and someone noticing before the disk fills. Budget for that rather than for a licence. A Zapier bill in the high hundreds usually pays for a self-hosted setup within a quarter.

Most of GoHighLevel is configuration and your team should own it. Pipelines, calendars, forms, standard workflows, and email sequences are all point and click, and paying someone to click on your behalf is waste. You need a developer when you push past what the builder exposes: custom values driving logic across sub-accounts, the v2 API, webhooks into outside systems, snapshot deployment across many locations, or a data migration in either direction. The other case is an account that has grown into hundreds of workflows nobody can map any more. That is an audit problem rather than a build problem, and it is worth paying to untangle before it breaks.

Yes, within a narrow scope. Voice agents reliably qualify callers, answer questions from a known set, check a live calendar, and book, reschedule or cancel inside the same conversation. They handle common objections when those responses were scripted from real call recordings. What they do not do well is open-ended negotiation or anything needing judgment about an unusual account, so the right design routes those to a human mid-call instead of pretending. Latency matters more than voice quality. A pause beyond roughly a second reads as a bad line.

Different, and the distinction changes what it costs you. Classic RPA drives the user interface, clicking through screens the way a person would, which is exactly why it breaks the week a vendor moves a button. What I build talks to APIs directly, so it survives interface changes and runs in milliseconds rather than seconds. RPA still earns its place against genuinely legacy systems with no API at all, mainframes and old desktop software, and there I would reach for it rather than pretend otherwise. If your systems expose APIs and someone is quoting you screen automation, ask them why.

It will break eventually, so the system gets built expecting it. Every integration has retries with backoff, a dead letter path so failed records are held rather than dropped, and alerting that names which step failed and with what payload. Silent failure is the actual risk. A flow that quietly stops routing leads costs far more than one that crashes loudly on day one. Handover includes what to check first when something breaks, so your team is never dependent on me being awake to diagnose it.

Yes. Workflows, code, prompts, and documentation are yours, running on your infrastructure under your accounts. Self-hosted n8n sits on your server. API keys are issued from your accounts, never mine. That matters more than it sounds, because a lot of automation work gets delivered inside an agency's own tooling, which means the day the relationship ends, the system ends with it. Ask anyone you are evaluating where the workflows physically run and whose name is on the API keys.