I shipped half a feature on purpose. The other half can't wake up by accident.
Pay-per-lead went live half-on: capture collecting real enquiries today, payments deployed but dormant behind a fail-safe gate until the review says otherwise.
The directory site I'm building got its biggest feature yet this month: pay-per-lead. A visitor sends an enquiry through a company's profile, the company gets notified, and unlocking the enquirer's full contact details costs money — a one-off payment or a subscription.
Here's the decision I want to write down: I shipped it half-on, on purpose. The capture half is live and collecting real enquiries today. The payment half is fully deployed — every line of code on the production server — and completely dormant. It cannot take a payment. Not "shouldn't". Can't.
Deploying is not releasing
Software engineers have had a name for this for years — Martin Fowler calls them release toggles: latent code shipped to production behind a switch, so that deploying code and releasing a feature become two separate decisions. Marketing people rarely think in these terms, which is a shame, because half our launch disasters are exactly this — the code went live and the feature went live in the same breath, and there was no moment in between to look at it.
My toggle isn't even a toggle, strictly. The entire payment path hangs on one configuration value — the price ID of the one-off product in the payment provider. Until that value is set, the gate is closed by construction: the one-off option doesn't render at checkout, and anyone hitting the payment URL directly gets a graceful error instead of a charge. There is no code path to money.
Deploying code and releasing a feature are different decisions. The gap between them is where the review lives.
Why the gap, concretely
Because the two halves carry different risk. The capture half — a form, a stored enquiry, a notification email — can fail politely. Worst case, a lead needs re-sending and I apologise. So it went live immediately and starts compounding now: every enquiry captured this week is inventory the payment feature will monetise later.
The payment half handles other people's money on code that, for infrastructure reasons, never went through a local linter before deployment. Switching that on the same evening it was written would be malpractice dressed up as momentum. It waits for a proper adversarial review — the first attempt at which, ironically, died on an API rate limit, which is precisely why the gate exists. When the review passes, going live is one pasted configuration value. I've made the case for speed over perfection before, but speed is for reversible things. Charging someone's card is not where you move fast.
There's a marketing-shaped bonus, too: the notification email a company receives already shows all three unlock options, and two of them — the subscriptions — work today. The dormant half isn't hidden scaffolding; it's a storefront where one shelf quietly waits for stock. The same staging logic as making the page beautiful before the site had traffic: sequence the work so every live piece earns something while the risky piece waits its turn.
Fail safe, not fail loud
The detail I'd defend hardest is how the gate fails. Default off. Graceful degradation — a redirect with an error message, never a broken checkout. One single switch, checked server-side, so there's no combination of cached pages or crafted URLs that wakes the feature early. If you're gating anything — a feature, a promo, a price — the gate itself deserves as much design as the feature. Half the incidents I see are gates that were "on unless told otherwise".
Building it this way cost almost nothing extra. The payment provider was wired the same API-first way I set up the subscriptions, the AI assistant wrote both halves in one session, and the gate is a single if-statement with good manners. The judgement — which half is safe to release, which half must wait, what the gate checks — is the part the tools still don't supply.
Half a feature, shipped whole. The other half sleeps until the review says otherwise.
Sources & further reading
External
- Martin Fowler: Feature Toggles (aka Feature Flags)
- Productive: Decoupling deployment from release with feature toggles
- LaunchDarkly: Feature toggle vs feature flag
Related posts