They couldn't see what they were changing

GoHighLevel sells a whitelabel mobile app: agencies brand it as their own, we build it, and it ships to the App Store and Play Store under their name. The branding step happens in a customizer — a form of colour and layout controls the agency fills in before we build.

I owned 150+ of those accounts. Every one of them passed through that customizer, and I was on the onboarding call when they did.

The customizer was a list of labelled inputs with no representation of the app itself. An agency owner picking a colour had to hold a mental model of where that colour would land — across a product they had never seen built.

They guessed. Often they guessed wrong, and only found out once the build came back, which meant another round trip through our build queue. Each one cost days and produced a support ticket that read like a complaint about our product quality.

I was taking notes on every onboarding call anyway, so I started tagging the moments where a customer hesitated or asked a clarifying question. The same pattern kept surfacing: the hesitation was never about which colour to choose. It was about what the control was attached to.

That reframed the problem. It wasn't a colour-picking problem or a documentation problem — both of which had obvious cheap fixes we'd already tried. It was a feedback problem. The interface asked for a decision and gave nothing back.

I argued for the third. The first two both leave the customer doing the mental rendering; only the preview moves that work to the software. The cost was real engineering time, so I brought the round-trip build data to make the tradeoff concrete rather than aesthetic.

• Better labels and tooltips — cheapest, but we'd already added help text and the confusion persisted. It treats the symptom.
• A static annotated screenshot of the app with callouts — moderate effort, but it goes stale the moment the app UI changes, and it still requires translation by the customer.
• A live preview panel rendering the app as they edit — most expensive, but it removes the guess entirely instead of narrowing it.

A live preview that updates as the agency edits — colour and layout changes reflected immediately against a representation of the actual app.

I wrote up the requirements from my call notes, took them into agile standups with the product manager and engineering team, and stayed on it through rollout: testing the build, then walking existing accounts through the change on their next check-in.

Adoption of the customizer rose 32%. Support escalations tied to branding errors dropped, and the round trips they caused went with them.

The second-order effect mattered more to me: onboarding calls got shorter and changed shape. We stopped spending them explaining our own interface and started spending them on the customer's actual launch.

I made the case with call notes and anecdote. It worked, but it worked slower than it should have — I spent weeks building consensus that a week of instrumented data would have bought in a day.

I should have counted the round-trip builds attributable to branding errors from the start, and put a cost on them. I learned that lesson properly on the next problem, and it's the first thing I do now.