Regulation is a design input, not a compliance follow-up

I had a strategy document for a side project that ran several pages on advertising-platform policy exposure. It was careful work. It analysed the deceptive-pre-click risk in detail and named the platform rules the mechanic would fail, all for an ad mechanic the project had already pivoted away from. On whether the service I was actually selling was lawful, the same document said nothing. The risk moved with the pivot and the analysis didn't follow it.

The service was reputation management for small local businesses, sold off a free audit comparing their Google Business Profile against nearby competitors. When I finally read the primary sources on what that service may do, four constraints came back, and every one of them removed or reshaped something already in the spec. The first took out the best feature in it. The commercially attractive version of review generation is a funnel: ask the customer how it went, send the happy ones to Google, route the unhappy ones to a private feedback form. Asking every customer is lawful and Google actively encourages it. Asking only the ones you think are happy is not. The CMA's fake reviews guidance, CMA208, names encouraging "just those who are satisfied" as publishing reviews in a misleading way at §4.5, and Google's Maps user-generated-content policy separately bans selectively soliciting positive reviews. The regulator enforces its side administratively, without going to court, with penalties reaching ten percent of turnover.

The second constraint surprised me, because the law was the looser of the two rules. An incentivised review is lawful in the UK if the incentive is prominently disclosed and the review still reflects genuine experience. Google bans incentives on business profiles regardless of disclosure, and CMA208 closes the loop by treating a review submitted to a platform that forbids incentives as itself likely misleading. So the disclose-it route, which is real and workable elsewhere, doesn't exist for anything delivered on Google, and no wording rescues it. The feature is gone.

Third, the lead form. The funnel depended on capturing a phone number through a paid social lead form and running an SMS sequence against it, and a number handed over on a lead form is not consent to market by SMS under PECR, the UK electronic-marketing regulations, which treat a text like an email. The regulator's guidance says that where you can't tell whether a number belongs to a sole trader or to a limited company, and on a lead form you can't, you treat it as the one needing consent. Sending someone the audit they asked for is solicited and fine. The drip sequence after it is marketing. What replaced it was a separate, optional, unticked box naming the sender and the channel, plus the assumption that plenty of leads will never tick it.

The fourth reached furthest back into the architecture. The audit's data source is Google's Places API, and the Maps Platform terms at §3.2.3(a) expressly prohibit copying and saving business names, addresses or user reviews, and separately prohibit pre-fetching. Those are the exact fields the audit is built from, and pre-fetching is what makes a report appear the moment a form is submitted. So: no pre-fetched competitor data, which is the whole of "instant". No stored report: a saved file carrying those figures is stored Maps content. And no chart of a client's rating over time, since a time series is stored by definition. What survives is a live fetch rendered at request time with the required attribution and nothing kept. That is a different product from the one I had designed.

That clause turned out to be load-bearing in a way I saw late. When I hand-built four sample audit reports to find out whether the product had anything true to say, the honest note that came with them recorded that committing the reports to a repository was itself in tension with the same clause, and that the reason no report could claim a business had improved or declined over time came straight from the storage prohibition rather than from editorial caution. The no-trend-claims constraint and the don't-store-Google's-data constraint are one constraint wearing two hats. I found that out by writing the reports instead of by reading the terms, which is the same wrong order as treating security as something that comes along for free with the feature.

I already run a gate on every new capability before it enters a build loop, and until this it asked two questions: whether the capability is genuinely my differentiator or undifferentiated plumbing I should buy, and whether I understand it well enough to automate it yet. Both are cost questions. Neither asks whether the thing is permitted at all. On a regulated surface the permitted set sits upstream of both, because it decides which features exist to build or buy before either question is worth asking.

The general version holds well past this one product. On a regulated surface the law is drawing the boundary of your design space whether or not you have looked, and the only variable you control is whether you find that out before or after you have built inside it.