Key takeaways
- We build a tool that lives inside a client's CRM sidebar. Every client gets their own separate copy of it, at their own address.
- Running one shared copy for everyone would work perfectly, right up until one client could search another client's contacts.
- Nothing would error. The screen would look correct to both of them. That is what makes this class of bug dangerous.
- The config refuses to install for a client whose settings are missing, rather than falling back to a shared address.
- You cannot check this by looking at it. You check it by opening the tool inside the client's own CRM and searching for one of their people.
We built a tool that a client opens from inside their own CRM. It sits in the sidebar, pulls up their contacts, and writes notes back onto their records. Useful, small, and the kind of thing that gets rolled out to a second client about a week after the first one likes it.
That rollout is where the interesting decision was.
The obvious way is the wrong way
The obvious build is one copy of the tool, at one address, that figures out which client is asking and serves the right data. That is how most software works. It is also more efficient: one thing to deploy, one thing to update, one thing to watch.
We did not do that. Every client gets a completely separate deployment, at their own address, with their own credentials attached to it. Two clients means two of everything.
The reason is the failure mode, not the effort.
If one shared copy is serving everybody, then something has to decide whose data to hand back on every single request. That decision is now a piece of logic that can be wrong. Get it wrong and a client opens their sidebar and is looking at someone else's customers. Worse, writes a note onto someone else's record.
With one deployment per client, that decision does not exist. The credentials sit on the deployment itself. There is no code path that could ever serve the wrong data, because the deployment only has access to one client's account in the first place. You cannot get a decision wrong that you never have to make.
Why you would never catch it
Here is the part that made the call easy.
If the shared version leaked, nothing would break. No error message, no red screen, no failed request. The sidebar would load, contacts would appear, search would work, and notes would save. It would look completely normal to the person using it.
The only way to notice is for someone to recognise a name that should not be there. Which means the detection method for your worst bug is a client happening to spot a stranger in their own CRM. That is not a safety net.
Compare that to almost every other kind of bug. A broken form throws an error. A dead link 404s. A failed automation leaves nothing on the timeline. Those announce themselves. This one does not, and it is the one that would end a client relationship.
The rule we wrote down
The config that installs the sidebar link for each client reads that client's own settings. If either of them is missing, it skips that client entirely.
Skipping is the correct behaviour, and the note in our own code says so in as many words, because the tempting fix when a new client's install does not appear is to point them at an address that already works. That would take about four seconds and it would be the exact bug we designed the whole thing to prevent.
So the rule is written where someone would go looking for it: never widen this to a shared address to make it work for a new client. If the settings are missing, add the settings.
How we actually verify it
We do not verify this by reading the config, and we do not verify it by loading the tool ourselves. Both of those tell you the structure is right, which is not the same as the behaviour being right.
We open the tool inside that client's own CRM, search for one of their contacts, and confirm the results are theirs. That is a two minute check and it is the only one that proves anything.
This is a habit worth generalising. For any setting where the wrong value produces a screen that still looks fine, checking the setting is not a test. Only the behaviour is.
What this means for a business here in San Jose
Most businesses will never deploy anything. But if you use any Go High Level San Jose setup, or any shared software where an agency serves several clients from one system, this is worth understanding, because you are on the other side of the decision.
Three questions worth asking whoever built your system:
- Is my data separated by a wall, or by a rule? A wall means my data lives somewhere nobody else's code can reach. A rule means a piece of logic checks who is asking. Rules can be wrong.
- If it were wrong, how would we find out? If the honest answer is "a customer would tell us", that is worth fixing before anything else.
- Has anyone actually tested it from inside my account? Not from an admin view. From mine, logged in as me.
None of that requires you to be technical. They are just the questions that separate a system built carefully from one built quickly.
The efficient version of this tool would have been easier to build and cheaper to run. We built the boring one instead, because the failure mode was silent, and the silent failures are the ones that cost you a client.
If you want systems built with that kind of care, that is the work we do. Have a look at optechsol.llc.