Go/No-Go Decision Framework

A structured approach for evaluating whether a blocked technical integration should continue or be abandoned — and what to do if it's abandoned. This framework emerged from the ^[1] Bookly integration effort, where an unresolved tokenization blocker forced a formal decision point.

Core Principle

When a technical integration is blocked and a client has explicitly rejected stopgap solutions, the team must treat the next attempt as a go/no-go gate rather than an open-ended debugging loop. Indefinite iteration ("we'll try it this way, then this way") consumes time without producing a decision. Time-boxing the final attempt forces resolution.

"There comes a time where it's like, we need to time box things… Eshock going to talk to his friend — go/no-go. Give me the code, I'll take a once-over. And then we have exited this holding pattern."
— Kimberly Gehrmann, ^[2]

When to Apply This Framework

Apply a go/no-go gate when all three of the following are true:

1. The integration is blocked — a specific technical issue has resisted multiple resolution attempts.
2. The client has rejected partial solutions — a "janky" or interim launch is not acceptable; the client wants a final, high-quality product.
3. Scope creep risk is high — continued debugging risks pulling senior resources into rabbit holes without a defined exit condition.

Framework Steps

1. Identify the Specific Blocker

Document the exact failure point clearly. Vague blockers ("it's not working") lead to vague debugging. A precise statement enables targeted final attempts.

LMB example: WooCommerce's native Square payment authorization captures credit card tokens for product purchases but fails to relay the token to Bookly for service bookings. The communication bridge between WooCommerce and Bookly is the specific gap.

2. Assign One Final Attempt

Designate a single, bounded final effort — ideally with a fresh perspective (a colleague review, a code audit, an external resource). This is not an invitation to restart the work; it is a last check before closing the gate.

LMB example: Ishak consulted a developer colleague. Kimberly Gehrmann conducted an independent code audit of the staging tokenization PHP. Both efforts were time-boxed and parallel.

3. Set the Decision Criteria

Define in advance what "go" and "no-go" look like. The decision should be binary and observable, not a matter of opinion.

4. Prepare the Contingency Before the Decision

Do not wait for a no-go verdict to begin contingency planning. Identify what existing work can be launched in the no-go scenario, so the team is never left with nothing to ship.

LMB example: The contingency was defined before the final Bookly attempt concluded: launch the staging variant pages with "Book Now" buttons linked directly to Square. This reused high-quality design work already completed by Asymmetric, avoided introducing new technical debt, and preserved the client's existing Square booking data and customer history.

5. Communicate the Decision Cleanly

Once the gate closes, communicate the outcome as a resolved decision — not a failure. Reframe the no-go as scope clarity: the team now knows what the solution is not, which is necessary information for identifying what it is.

Contingency Planning Principles

A good contingency plan for a no-go integration outcome should:

• Reuse existing work — avoid building something new just to fill the gap.
• Avoid new technical debt — linking to an existing external system (e.g., Square) is preferable to building a custom bridge that will need to be replaced.
• Preserve client data integrity — do not migrate or disrupt existing customer records as part of a contingency.
• Be shippable immediately — the contingency should be deployable as soon as the no-go decision is made, not require additional development cycles.

LMB example: The contingency (staging variant pages → Square links) satisfied all four criteria. The only remaining task was a simple URL fix: the live site's "Book Now" buttons linked to the generic Square homepage rather than specific service pages — a one-line update per service.

Related Patterns

• Time-boxing — Set explicit deadlines for debugging efforts. An open-ended investigation is not a plan.
• Rubber duck / fresh-eyes review — Before closing the gate, have someone outside the original implementation review the code. Tunnel vision is a real risk on long-running blockers.
• Staging as a launch asset — Staging environments often contain completed, high-quality work that can be promoted to production as a contingency. Audit staging before assuming a no-go means starting over.

Client Examples

• ^[1] — Bookly Integration (Dec 2025): The canonical case for this framework. WooCommerce-to-Bookly tokenization was blocked for an extended period. Lisa (client) explicitly rejected stopgap solutions, citing 5+ years of customer data in Square and a high design bar. The go/no-go gate was set; the contingency (staging variant pages + Square links) was defined in parallel. See ^[3] for full context.