Forty percent of our delays came from one control

Every whitelabel app we built had to pass Apple's and Google's review before an agency could launch. A rejection wasn't just a technical delay — it landed on an agency owner who had already promised their client a date.

I handled those escalations. That gave me a view nobody else had: I saw every rejection, in sequence, with the customer's reaction attached.

Rejections were being treated as individual incidents. Each one got diagnosed from scratch, fixed, and resubmitted — a full cycle of roughly a week between the bounce and the launch.

Because each was handled alone, nobody was asking whether they were the same failure repeating.

I went back through the escalation history and categorised the rejections by cause rather than by account. One cause accounted for 40% of them.

It was the colour picker. Agencies were selecting brand colours that failed the stores' contrast and asset guidelines — a dark logo on a dark background, text that didn't meet the required ratio. The interface let them pick a combination the store would predictably reject, and said nothing.

This was the same root as the customizer's preview gap, seen from the other end: the tool accepted input it knew would fail, and the customer discovered it a week later through a rejection notice with our name on it.

I did the second immediately and pushed for the third. Documentation was something I could ship that week without anyone's roadmap, and it bought the time to make the case for the redesign properly.

• Fix faster — throw more support at the queue. Doesn't reduce rejections, just absorbs them, and it doesn't scale with account growth.
• Document the constraints and train the team — cheap, fast to deploy, but relies on humans catching it every time.
• Constrain the picker so store-violating combinations can't be submitted — the real fix, but it needed engineering time and a design decision about how hard to block.

I wrote up the iOS and Android asset and contrast requirements as practical guidance — what the stores actually enforce, in language an agency owner could act on — and got it into the knowledge base and the support team's hands.

Then I took the 40% figure to the product manager and engineering team and worked with them on the picker redesign, so the constraint lived in the interface rather than in a document somebody had to remember to read.

The rejection rate fell, and time-to-resolution on the ones that still happened dropped from 7 days to 2 — because the team now recognised the failure on sight instead of diagnosing it fresh.

The compounding effect: an agency's launch date stopped being a coin flip. That's a retention story, not a support story.

I categorised the rejections manually, once, in a spreadsheet. It answered the question but it didn't keep answering it — the moment I stopped maintaining it, the visibility went with me.

The right move was to get a cause field onto the rejection record at the point of logging, so the distribution was always live and anyone could see the next 40% coming. Insight that depends on one person re-running it isn't infrastructure.