Catching a promotion-tool capability gap before building the wrong solution

What was happening

The promotion initially used an app-based countdown bar with minimum-spend messaging, a delayed cart state, and a ten-minute urgency timer. Later, the desired experience shifted toward a popup. Research showed the installed tool supported the banner workflow but not the requested popup interaction as a native feature.

Why the obvious solution was not enough

Trying to imitate a popup by fighting the app's generated markup or injecting brittle scripts would create a maintenance problem. The implementation decision had to distinguish between configuration that the current product supports and a genuinely custom interface that should be estimated and owned as code.

How the solution works

1. Reproduce the current promotion behavior first so the working baseline is understood before changing tools.
2. Separate the business rule from the presentation: minimum spend, delay, timer duration, claimed state, and expiry behavior are different concerns from whether the UI is a banner or popup.
3. Check the installed product's documented capabilities and configuration surface before promising the requested interaction.
4. Keep the supported banner implementation stable when it already satisfies the original requirement.
5. For the popup request, identify either a purpose-built tool or a small custom component instead of layering unsupported DOM hacks over the existing app.
6. Estimate the custom path separately so stakeholders can compare effort and maintenance cost against the value of the changed interaction.
7. Retest timer expiry, hidden state, delayed appearance, and claimed state regardless of which presentation option is chosen.

What should be verified before shipping

• Verify the timer hides or resets intentionally at zero instead of leaving a stale urgency message.
• Confirm the requested delay is measured from the intended cart event, not merely from page load.
• Test claimed and unclaimed states separately.
• Confirm the chosen tool actually supports the final requested presentation before implementation begins.
• If custom code is selected, verify it does not conflict with the app's own banner state or duplicate the promotion message.

What changed

The requirement was reframed as a product-capability decision instead of a styling tweak. That prevented unsupported app behavior from being disguised as a quick configuration change.

Reusable lesson

Technical discovery is part of implementation. Confirm whether a third-party tool owns the requested behavior before spending time styling around a capability it does not have.