The answer was no. Not “no, that’s expensive.” Just no. The jobs weren’t records. Each one was a couple of tags on a contact, three custom fields added at different times by different people, an opportunity someone had dragged into Won, and a note cut off mid-sentence. There was no job. There was a person that a job had happened to.

Nobody made a bad decision to get there. “Can we just add a field for that?” is a five-second request and the answer is always yes, because adding a field is easy. That’s the trap. The CRM never pushes back, so the schema drifts for eighteen months and nobody notices until someone asks a question that needs a join.

This post is about where that line sits: not whether to use the platform, but where GoHighLevel as a database stops being a shortcut and starts being architecture debt. I’ll cover the failure that stays invisible, the four boundaries that decide it, what Custom Objects actually change, and the arrangement I default to when the CRM isn’t the right home.

The failure mode nobody sees coming

Databases push back. Declare a column as a date and it refuses to hold “next Tuesday.” Declare a foreign key and it refuses to orphan the row. Half the value of a schema isn’t storage, it’s the set of things it won’t let you do.

A custom field holds whatever you type. That’s a feature when a rep jots down a competitor’s name. It’s a slow disaster when the field is called contract_value and it contains “1,250.00”, “$1250”, “1250 (pending)” and “ask Dave” across four hundred records.

Here’s why it stays invisible: nothing breaks. Workflows keep firing. Dashboards keep rendering, because they count records rather than summing values. The failure surfaces the day someone needs an aggregate, and by then you have four hundred rows of ambiguity and no way to tell which reading was right. You can’t retroactively decide whether “1250 (pending)” was invoiced.

History is the other half. A CRM field is a current value. Overwrite it and the old one is gone. Anything touching money, entitlements or consent eventually needs to prove what the state was and when, and the platform discarded that silently, months earlier.

What the platform is genuinely good at

An argument against a tool isn’t credible unless it starts with the tool’s real case. GoHighLevel is very good at a specific set of things, most of them expensive to build yourself.

• Conversation state across channels. One thread per person spanning SMS, email and calls, with delivery status attached. Rebuilding that is months of work and a compliance surface you don’t want.
• Sequenced outreach with human interrupts. Wait steps, conditions, and a reply pulling someone out of a sequence. Easy to describe, tedious to get right.
• Tenant isolation by default. Each sub-account is its own location, and nothing crosses unless you deliberately copy it.
• Non-engineers can change it. A workflow a client can edit on a Tuesday afternoon beats an elegant pipeline only you can touch.

Every one of those is about people and communication. That’s the pattern: when the thing you’re storing is a person, or something that happened to a person, the CRM is the right home. When it has a life independent of any person, you’re outside the design.

Four boundaries that decide it for you

“Is this a database?” isn’t a useful question. These four are decidable, and any one of them crossing is usually enough.

1. The question you need to ask requires a join

Not “show me contacts tagged X.” I mean revenue by technician by quarter, or every account with more than three open items where the last payment was over sixty days ago: grouping, filtering across related records, and arithmetic on typed values, all at once. Smart lists answer a narrow, predefined set of questions well, but they aren’t a query engine, and the gap between the two is where most people discover they’ve built a database by accident.

2. More than one system writes the same field

This is the one that quietly costs the most. A stock level or invoice status lives in a CRM field, and both an automation and an external sync can write it. There’s no transaction and no compare-and-set. Last write wins, and “last” is whichever request happened to land second. You see it as an occasional wrong value you can’t reproduce, which is the worst kind of bug to be handed.

The fix isn’t better retry logic. The field has the wrong owner. Exactly one system should write any given piece of state, and if that system isn’t the CRM, the CRM holds a copy for display rather than the value itself.

3. Someone will need the history

Anything where you may later have to prove a prior state needs append-only storage. The workaround people reach for is a note per change. It doesn’t hold: notes aren’t structured, aren’t queryable, and the export path treats them as an afterthought, which leads straight to the next boundary.

4. The exit shape doesn’t match what you put in

People check this last and should check it first. Contact export lands as CSV, and only the most recent note travels with it, truncated to 255 characters. A year of notes exports as one, clipped. Custom object data isn’t part of a direct export at all: the documented route is a snapshot from one sub-account to another, which is a copy inside the platform, not a file you keep. Export permissions are role-gated, so a client who believes they own their data may not be able to pull it themselves.

None of that makes it a bad choice. It makes it a bad sole home for anything you’d be in trouble without.

What Custom Objects change, and what they don’t

Custom Objects are a real improvement and worth using. Properties, policies, vehicles, courses: things that aren’t people, modelled as first-class records with their own fields and associations back to contacts, usable in workflows. For years the only option was squashing everything into a contact, and that was worse. They don’t turn the CRM into a database, though, and the reasons are specific rather than philosophical.

• Ten objects per sub-account, documented as a hard cap. That’s your entire entity budget. Fifteen nouns worth modelling means five go back into custom fields.
• Uniqueness is limited and one-way. Up to ten unique fields per object, and only single line text, multi line text, number and phone types can be unique. It’s enforced across the sub-account and every entry point including the API, which is genuinely useful. But downgrade a unique field to non-unique and you cannot make it unique again.
• Write access is admin-only. Creating, updating and deleting object records is restricted to location admins; regular users are read-only. Check this before assuming the front desk will maintain records.
• Records count against storage quota. Object records and attached files consume the same account storage as everything else, so high-volume machine-generated data is the wrong shape.
• The exit is a snapshot, not an export. Objects, fields and associations move between sub-accounts via snapshots, subject to the same cap in the target account.

Read those as design constraints rather than complaints. They tell you the intended scale: dozens of entity types, no. Millions of rows, no. A handful of business nouns with clean identity and moderate volume, yes, and it works well there.

The API budget is a design constraint too

If you’re treating the platform as a datastore behind an integration, the rate limits shape what’s possible. On the v2 API a marketplace app gets a burst allowance of 100 requests per 10 seconds per resource, and 200,000 requests per day per resource, where a resource means a location or company. Version 1 is end of support, so anything new belongs on v2.

Every v2 request carries a version header alongside the bearer token. It’s easy to forget and produces a confusing failure when missing:

curl -H "Authorization: Bearer $TOKEN" 
     -H "Version: 2021-04-15" 
     -H "Accept: application/json" 
     "$BASE_URL/<resource>?locationId=$LOCATION_ID"

More useful than the numbers is that responses carry their own accounting, so you never have to guess where you are in the window: X-RateLimit-Remaining and X-RateLimit-Max cover the burst interval, X-RateLimit-Daily-Remaining and X-RateLimit-Limit-Daily cover the day.

Pace against the remaining count rather than reacting to failures, and watch the daily counter separately: burst limits recover in seconds, a daily allowance doesn’t, and a backfill that exhausts it takes the rest of the day’s normal traffic with it. The consequence is that polling is expensive and webhooks are cheap. Push where you can; poll only to reconcile.

The shape I reach for: CRM in front, system of record behind

When something crosses one of those boundaries, this is the arrangement I default to. It’s deliberately boring.

1. Pick one owner per piece of state and write it down. Contact details and conversation history belong to the CRM. Money, inventory and anything with an audit requirement belong to the external store. No field gets two owners.
2. Give every record a stable external ID on both sides. Do this on day one. Retrofitting identity onto records matched by email is genuinely painful.
3. Push changes out with webhooks, not polling. Webhook to a queue, queue to a worker, and make the worker idempotent, because you will receive duplicates and you’ll need to replay after an outage.
4. Reconcile on a schedule anyway. Webhooks get dropped. A nightly sweep comparing counts and updated timestamps, re-pulling only the drift, catches what the push path missed without burning the daily allowance.
5. Push a flattened summary back for display. The CRM doesn’t need the ledger, just the two or three values a human wants on the contact record. Treat those fields as read-only and never let a workflow write them.

The external side doesn’t need to be impressive. For a small engagement it’s usually managed Postgres, or plain Postgres on a modest VPS from somewhere like Contabo or InterServer, sat behind Cloudflare so nothing is directly exposed. The glue is often n8n or Make rather than anything custom. What matters is that constraints exist:

CREATE TABLE job (
  id             bigserial PRIMARY KEY,
  crm_contact_id text        NOT NULL,
  technician_id  bigint      NOT NULL REFERENCES technician(id),
  completed_on   date        NOT NULL,
  value_cents    bigint      NOT NULL CHECK (value_cents >= 0),
  created_at     timestamptz NOT NULL DEFAULT now()
);

Nothing clever there. But value_cents can’t hold “ask Dave”, technician_id can’t point at a technician who doesn’t exist, and the quarterly margin question becomes one query instead of a conversation about why it can’t be answered.

Arguments that don’t survive contact

• “We’re too small for a second system.” Sometimes right, and worth taking seriously. But the cost of adding a store later isn’t the store, it’s the reconstruction, and some of that history is unrecoverable.
• “We’ll clean the data up later.” Cleanup needs to know what the value should have been. Free-text fields with no history don’t retain that. This is the one I’d push back on hardest.
• “Custom Objects solved this.” They solved modelling non-person entities, which was the biggest gap. They didn’t add joins, transactions, versioning or an export path.
• “The client wants everything in one place.” They want one place to look, which is a UI requirement, not a storage requirement. A summary pushed back to the contact record satisfies it.
• “We can export whenever we want.” Test it before you rely on it. Export the notes. Export a custom object. Do it as the client’s own user, not as an admin.

How I’d decide

1. Name the thing. If it’s a noun that isn’t a person, it wants to be a record, not a field on a contact.
2. Write out the hardest question anyone will ask of it. The actual sentence. If it needs grouping, arithmetic, or two entity types at once, the CRM isn’t the home.
3. Count the writers. More than one system writing the same field means the CRM holds a copy, not the value.
4. Decide whether history matters. Assume it does for anything involving money or consent.
5. Do the export before you commit. Not the docs, the actual file. Whatever doesn’t come out cleanly is data you don’t really own.
6. Check the entity budget. Ten objects per sub-account. If you’re modelling toward that ceiling, decide now which nouns get a slot.

Steps two and five take about twenty minutes together and prevent most of what I’ve described.

Frequently asked questions

Can I use GoHighLevel as a database for my business data?

For people, conversations, bookings and pipeline state, yes, and it’s a good one. For anything needing joins, transactions, versioned history or guaranteed export, no. Using GoHighLevel as a database for that second category works right up until someone asks a question the platform can’t express, and by then the data is already ambiguous.

How many Custom Objects can a sub-account have?

Ten per location, documented as a hard cap. Each object supports up to ten unique fields, and only single line text, multi line text, number and phone types can be marked unique. Treat those slots as a fixed budget when you plan the model.

Can I export Custom Object data out of the platform?

Not through a direct export the way contacts go to CSV. The documented path is a snapshot between sub-accounts, which carries fields and associations but stays inside the platform. The API does support CRUD on objects and records, so a scripted pull is the practical route to a copy you keep.

Why do my exported notes look truncated?

Contact export includes only the most recent note, cut to 255 characters. That’s expected behaviour, not a bug. If notes hold anything you’d need later, pull them through the API and store them somewhere that keeps all of them.

What usually trips the API rate limits?

Backfills, and polling loops that scale with contact count. The limits are 100 requests per 10 seconds and 200,000 per day, both per resource. Read the rate limit headers on each response and pace against them rather than retrying into a wall.

Does a sub-account count as a real tenancy boundary?

For operational separation, yes: each is its own location and nothing crosses unless you copy it. The consequence is that cross-client reporting has to happen outside the platform, because no query spans locations. If portfolio-level reporting is a requirement, plan for an external store from the start.

Should I migrate off the CRM entirely?

Usually not. A full migration means rebuilding the conversation and outreach layer, which is the part it does best. Moving one category of data out, with a clear owner and a summary pushed back for display, is smaller and reversible.

The one thing worth remembering

The CRM will never tell you that you’ve gone too far. There’s no constraint to violate, no error to raise, no migration to fail. That’s exactly what makes the boundary worth drawing on purpose, before the field gets added rather than after four hundred records have been through it.

The test I’d keep: write down the hardest question anyone will ever ask of this data, then check whether the platform can express it. If it can’t, that’s not a reporting gap a better dashboard will close. It’s the boundary telling you where GoHighLevel as a database should stop and a real system of record should start. The identity mapping, the webhooks, the reconciliation sweep: all of that is plumbing once the decision is made.

Working on this with me

Most of what I do here is unglamorous and ends with the reporting question getting answered:

• Auditing an existing setup and mapping which custom fields have quietly become load-bearing, with an owner assigned to each.
• Drawing the boundary: what stays in the CRM, what moves to Custom Objects, what needs an external system of record.
• Building the sync layer: webhooks into a queue, idempotent workers, stable ID mapping both ways, and a reconciliation job that catches dropped events without burning the API allowance.
• Standing up the store: schema design with constraints that hold, on managed Postgres or a small VPS, with backups you’ve tested restoring rather than assumed.
• Rescuing free-text fields into typed columns, including the judgement calls about what’s recoverable.
• Handover packaging: a real export, documented, so a client can leave with their data whether or not they keep working with you.

If you’re weighing this up, send me something concrete: a list of your custom field names, a sample export, or the query you can’t currently answer. That’s usually enough to tell you where the line sits.

The post Your CRM Is Not a Database: Where GoHighLevel Should Stop appeared first on John Nessime.

That is the moment. Not a crash, not an error banner. A plain question about the system that nobody can answer from the canvas.

GoHighLevel is good at what it was built for and most accounts never need anything else. But there is a point where the next workflow makes the account worse instead of better, and past it, GoHighLevel custom development costs less than another six months of patching. Below: the failure mode hiding under all the others, six signals you have crossed that line, the honest case for staying in the builder, and three levels of code to try before committing to a full app.

The failure hiding under all the others

The workflow builder has no failure semantics. Everything below is a consequence of that.

When a step works, the contact moves on. When a step fails, the contact usually also moves on. No transaction, no rollback, no retry budget you control, no way to say “this contact is in a bad state, stop and tell someone”. A Custom Webhook that gets a 500 back does not park the contact for review. It becomes a line in an execution log nobody reads, and the contact continues as though the other system had answered.

Fine when the step sends a text message. Not fine when the step is the only thing keeping two systems in agreement. So the useful test is not “is this hard to build in the builder”, because plenty of hard things build fine. The test is: what happens when this step fails, and would I find out?

Signal one: you are storing state in tags

Tags start as labels. Then someone needs to know whether a lead was called, so there is a called tag. Then whether they were called twice, so called-2. Then a workflow that removes called when a new form arrives, and another that puts it back if an appointment was booked first.

Those are no longer labels. That is a state machine with no diagram, no validation, and no guarantee that only one workflow writes to it at a time. Two workflows fired by the same event will both read the old value and both write, and whichever finishes last wins. That is a race condition, and it hides during testing because you test one contact at a time. The tell is a tag name with a number in it, or a tag whose meaning needs the word “unless” to explain.

Signal two: the data has to be right, not eventually right

Marketing automation tolerates drift. One extra nurture email hurts nobody. The moment GoHighLevel holds something that must reconcile with another system, that tolerance is gone. Order status from a store, invoice state from an accounting package, availability shared with a clinic system.

Those need idempotency, meaning a repeated message produces the same result as a single one, and reconciliation, meaning something periodically compares both sides and reports the difference. The builder gives you neither: no natural home for an idempotency key, no scheduled job that reads both systems and complains. You can fake reconciliation with a workflow on a timer, but that is a batch job written in a UI designed for follow-up sequences, and the first time it half-runs you will not hear about it.

Signal three: per-execution billing became a per-lead tax

The actions that make workflows powerful are premium actions, billed per execution against the agency wallet. Custom Webhook, Inbound Webhook, Custom Code and the workflow AI actions all sit in that category. HighLevel gives each sub-account a small free allowance when premium actions are first switched on, publishes volume tiers above that, and lets you rebill sub-accounts individually instead of absorbing the charge. Take the current rate and tiers from HighLevel’s billing documentation rather than any blog post, including this one.

The mechanism is the point. You pay per execution, not per useful outcome. A workflow calling out three times to enrich, score and push a lead is three executions per lead. Multiply by volume and sub-accounts, and the plumbing line can pass the cost of a small service doing all three in one request.

Two caveats. Consolidating three calls into one endpoint is usually cheaper than moving the whole thing to code. And whatever you move still costs something to run, whether that is a VPS from a provider like Contabo or InterServer, a hosted platform such as Make or n8n, or a serverless function. Compare both sides.

Signal four: the same logic lives in twenty sub-accounts

Snapshots are the platform’s answer and better than people expect. You can refresh a snapshot and push selected assets to sub-accounts that previously imported it, choosing both the assets and the recipients, and the push is selective rather than destructive.

Two limits. Push Update only reaches sub-accounts inside your own agency, so anything shared externally has to be re-imported through a new link. And HighLevel documents that when a snapshot refresh deletes steps, contacts waiting on those steps in workflows created from that snapshot are removed. Fine for a copy change, destructive for a structural one.

Snapshots distribute structure. They do not give you versioning, a rollback path, a diff between intended and running state, or a test that fails before the change reaches a client. Once a change has to land correctly in twenty accounts on one day, you want those, and they come from putting the logic behind an API you control and calling it from a thin step in each account.

Signal five: the integration must survive the other side being down

A Custom Webhook fires the moment the contact reaches the step. If your endpoint is slow, restarting or rate limited, that single firing is what you get. No queue in front, no backoff behind.

The API side has numbers worth knowing. HighLevel documents a burst limit of 100 requests per 10 seconds and a daily limit of 200,000 requests, counted per marketplace app per resource, where a resource is a location or the company. Every response carries headers telling you where you stand, so backoff can follow what the server says instead of a guessed sleep.

curl -sS -D - -o /dev/null 
  -H "Authorization: Bearer $GHL_TOKEN" 
  -H "Version: $GHL_API_VERSION" 
  "$GHL_API_BASE/contacts/" 
  | grep -i '^x-ratelimit'

-D - writes response headers to stdout while -o /dev/null discards the body, so you read the rate limit state without dumping contact data into your shell history. Set the base URL and the required Version value from the current API reference. Watch X-RateLimit-Max and X-RateLimit-Remaining for the burst window, X-RateLimit-Interval-Milliseconds for its length, and X-RateLimit-Limit-Daily with X-RateLimit-Daily-Remaining for the day.

The daily budget sounds enormous until a migration. Reading a contact, upserting it, then writing custom fields is three calls each, so forty thousand contacts is 120,000 calls before live traffic touches the account. Batch the reads, skip writes where nothing changed, run backfills overnight. Watch for loops too: writes made through the API can themselves fire workflow triggers, so a receiver that writes back has built a cycle.

Signal six: someone needs a screen, not a form

Forms collect. They do not display. Once a client asks to see a filtered view of their own data, approve something in two clicks, or work a queue that is not a pipeline, you are looking at an interface.

The platform supports this. Marketplace apps can add Custom Pages, which render inside HighLevel in an embedded iframe loading a URL you host, appearing on the app details page or in the left navigation. HighLevel publishes an app template to start from, plus an SSO mechanism so your page can identify the user instead of asking them to log in again. That is still a real application with hosting, auth and deployment: the biggest step on this list, the one I would defer longest, and the only honest answer when the requirement is a screen.

Where the workflow builder genuinely wins

A one-sided argument is not worth reading, so here is the case against writing code.

• The person who owns the outcome can change it. An account manager adjusts send timing on a Friday with no deploy and no developer awake.
• Messaging and scheduling are solved. SMS, email, calendars, reminders and the delivery infrastructure behind them are the platform’s core. Rebuilding any of it is a bad trade.
• Timezone handling is built in. Time-based steps run in the account timezone or the contact’s own, falling back to the account when a contact has none.
• No pipeline to maintain. No repository, no secrets rotation, no dependency upgrades, no server needing patched at an awkward hour.
• Execution history is right there. For a linear sequence, reading what happened to a contact beats correlating logs across two systems.

If the automation is a follow-up sequence with branching, the builder is correct and code is the expensive mistake.

Three levels before you build an app

“Needs a developer” is not one decision. It is three, and most accounts only need the first.

Level one: the Custom Code action

The builder has a Custom Code premium action that runs JavaScript inside the workflow. Values from earlier steps are mapped in as named input properties and arrive in an InputData object. The action returns a JavaScript object or an array of objects for later steps to reference, and console.log output is captured so you can see what ran.

// Normalise a phone number before it reaches a branch step.
// rawPhone and country are input properties mapped from earlier steps.
const digits = String(InputData.rawPhone || "").replace(/D/g, "");
const cc = InputData.country === "US" ? "1" : "";

if (!digits) {
  console.log("no phone on contact, routing to manual branch");
  return { e164: "", usable: false };
}

return {
  e164: "+" + (digits.startsWith(cc) ? digits : cc + digits),
  usable: digits.length >= 10
};

This kills a lot of branch sprawl. Ten If/Else steps existing only to reshape a value collapse into one action returning a clean value and a boolean. Still inside the platform, still billed per execution, still no retries. But logic smeared across a canvas now reads in one place.

Level two: a private integration and a script you own

For one account you do not need a marketplace app. Create a Private Integration inside the sub-account, select only the scopes the job needs, and use the token as a bearer credential. No OAuth handshake, no refresh cycle, no listing.

This is where reconciliation jobs, nightly audits, migrations and bulk cleanups belong. Run it as a cron job on a small VPS, behind a Cloudflare Tunnel if it needs an inbound endpoint, with the token in a secrets store rather than a config file. Treat that token as a credential with a rotation plan, not a string you paste once and forget.

Level three: a marketplace app

You need this when the thing spans many accounts, has a user interface, or is a product you intend to sell. It means OAuth 2.0 on the authorization code grant, token storage and refresh per installed location, webhook handling, and somewhere to run it. Note the version boundary: the v1 API is end of life and unmaintained, and new builds target the OAuth-based v2. If a tutorial hands you a permanent location API key, it is describing the old world.

Marketplace apps can also register their own workflow triggers and actions, which appear in the builder for sub-accounts that installed the app. That is the pattern I reach for first: the hard logic lives in your service, and the person who owns the campaign still drags a step onto a canvas. It requires the workflows read scope, and those custom actions are themselves premium actions billed per execution.

Arguments that do not survive contact

• “We will just add one more workflow.” The cost is not building it. It is that every future workflow now has to be reasoned about alongside it. Ten workflows listening for one tag is not ten problems, it is the interactions between them.
• “No-code means no developer.” It means no deployment. Someone still holds the whole model in their head, and when they leave, an undocumented canvas is harder to inherit than a repository with a README.
• “Zapier or Make will handle it.” Often true and worth trying first. What they do not give you is one place where business logic lives. Split rules across three tools and debugging means three log formats.
• “It works, so it is fine.” Every silent failure worked right up until someone counted. Absence of errors in a system with no error reporting is not evidence.
• “Custom code is lock-in.” Backwards. Logic on a canvas is bound to one vendor’s UI and exports only as a snapshot. Logic in a repository moves.

How I would decide

1. Write down what happens when each external call fails. If the answer anywhere is “the contact continues as if it succeeded” and that matters, you have found your requirement.
2. Count the workflows writing to the same tag or field. More than two means you have a state machine. Draw it before touching anything.
3. Count premium executions per lead, then multiply by monthly volume. Compare against a few hours a month maintaining a small service. Sometimes the builder still wins. Do the arithmetic instead of assuming.
4. Ask how a change reaches every account. If it involves opening sub-accounts one at a time, that is the real cost, and it grows with every client.
5. Try the smallest level that fits, and leave the trigger in the builder. Custom Code action, then private integration script, then marketplace app. Whatever moves out, keep the entry point as a workflow step so the marketing side can still change timing and audience without you.

Whatever you build, monitor it. An uptime check on your receiver and an alert when the reconciliation job reports a non-zero difference will catch more real problems than any amount of careful workflow naming.

Frequently asked questions

Do I need a marketplace app to use the GoHighLevel API?

No. For a single sub-account, create a Private Integration inside that account, grant only the scopes you need, and use the token as a bearer credential. Marketplace apps and OAuth are for anything spanning accounts or distributed to other people.

How much automation should stay in workflows?

The parts a non-developer should be able to change: timing, audience, message copy, branching on obvious contact attributes. Move out the parts where being wrong is expensive and being wrong is silent.

Why does my workflow show as successful when the integration clearly failed?

A step firing and a step achieving something are different events, and the builder records the first. A webhook returning an error still counts as having run. If the outcome matters, verify it explicitly rather than trusting the log.

Should I avoid premium workflow actions on cost grounds?

Not on principle. They cost per execution because they are the expensive verbs. The problem is fragmentation: three separate calls where one would do triples the bill for the same outcome. Consolidate before considering a move off the platform.

What does a GoHighLevel custom development project usually start with?

An audit, not a build. Map which workflows write to which fields, where external calls happen, and what the failure path is for each. Often that document alone removes the need for the project.

The one thing worth remembering

Ask what happens when a step fails. That question separates automation belonging in the builder from automation needing code, more reliably than counting steps, counting workflows, or judging how clever the branching has become.

If failure is visible and cheap, stay in the builder and enjoy that your client can edit it themselves. If failure is silent and expensive, GoHighLevel custom development stops being an upgrade and becomes maintenance you already deferred. Then start small: a Custom Code action beats a marketplace app you will not want to maintain.

Working on this with me

I work on the engineering side of GoHighLevel accounts, usually the parts failing quietly rather than the parts that look broken.

• Auditing an account for silent failures: which workflows write to which tags and fields, and what happens on every external call that returns an error.
• Replacing branch sprawl with Custom Code actions, so logic reads as one block instead of fifteen steps on a canvas.
• Webhook receivers and sync services that retry, deduplicate and reconcile, with the rate limit headers driving backoff instead of a fixed sleep.
• Migrations and backfills planned against the daily API budget, batched and run in the account’s timezone so live traffic keeps working.
• Private integration setup with least-privilege scopes, token storage and a rotation plan that is written down.
• Marketplace app work when genuinely warranted: OAuth handling, custom workflow actions, and Custom Pages hosted somewhere you control.

If you want a second opinion, send something concrete: a screenshot of the workflow you are least sure about, an execution log entry that makes no sense, or the response body your webhook endpoint is returning. That is a faster conversation than a scoping call.

The post Six Signs GoHighLevel Needs a Developer, Not Another Workflow appeared first on John Nessime.