The personalization trap: how 'just configure it' becomes a $40K custom build
Productized only works when 'configuration' has named limits. We write the boundary into the offer schema. Here's why.
A productized system isn't a stance — it's a contract. If the contract says 'configuration within named limits' but the limits aren't named, you've signed up for a custom build with a productized price tag.
The drift
It happens on every engagement we've ever shipped. The first request comes in week one: can we route the daily standup to a different Slack channel? Yes — that's configuration. Week three: can we customize the standup template per project? Maybe — depends on the limit. Week six: can we generate a different report format for our largest client? That's a custom engagement.
Three reasonable-sounding asks; one of them is a different product. Without a written boundary, you find out in week six that you've quietly become bespoke. Margin disappears in retrospect.
Writing the boundary into the schema
Every Offer doc in our CMS has a required field called 'boundary.' It can't be saved blank. The field reads, on the productized system: 'Personalization beyond named configuration is a separate, separately-priced custom engagement.'
That's a six-word rule that survives editor turnover, that surfaces in the UI next to every price, and that gives the salesperson a sentence to use in week six. It's not a marketing line — it's an enforcement mechanism we wrote into the data layer.
Why this matters for an agency
If you sell productized systems to your clients, every system needs the same field. Otherwise the system is productized only until the first client wants something the demo didn't show. Then it's a custom build, sold at a configuration price.