Saved a near-signed enterprise deal by choosing the right imperfect product shortcut

Client: A B2B booking platform with enterprise accounts

Timeline: One week from stakeholder meeting to ready-to-show production flow

Stack: Existing booking backend, feature flag, admin configuration, payment flow

Challenge

A near-signed enterprise deal was at risk over one workflow the product did not support. The client wanted to sell add-ons without attaching them to the normal booking object, and for them it was non-negotiable. Saying no would have protected the roadmap and likely lost the deal. Building a full add-ons system from scratch would have protected the engineer in me, but it would have pulled the team into architecture, UI, edge cases, and QA the business did not have time for.

The timing made the decision sharper. Stakeholders raised the requirement in a meeting, and the product needed to look ready within a week. The platform’s largest account was already doing $3.4M a year and growing 79% year over year; this client later became the second-largest account. This was not a small concession. It was the kind of pressure where a technically clean answer can still be the wrong business answer.

Approach

I treated the requirement as a product-model problem, not a feature request. The obvious paths were both expensive: build a separate add-ons purchase system, or force the existing booking flow to become something it was never designed to be. The third option was smaller: keep the core flow intact, add a feature flag, and route add-on-only selections into a hidden inventory record the system already knew how to process.

The important part was what this choice refused. No parallel checkout. No new admin surface. No rushed data model that would need to be defended for years. The hidden record was not pretty, but it preserved the product’s existing assumptions: every purchase still had a place to attach, payments still moved through the known path, and the rest of the roadmap did not get swallowed by one client’s deadline.

The five-person team did not need to burn the weekend to make that point. I finished the implementation myself, behind the flag, and brought back a working flow in time for the next conversation.

Outcome

The client signed, and the product avoided a rushed rewrite around one account’s buying requirement. The add-on-only flow worked in production, stayed behind a controlled configuration, and later handled thousands of transactions. More importantly, the company got to say yes without pretending the product had suddenly become a different product.

That was the real change. Stakeholders saw that a hard client demand did not have to become either a roadmap-breaking custom build or a defensive no. The team had a pattern for future pressure: name the trade-off, preserve the product model, use configuration where possible, and make the compromise visible enough that nobody mistakes it for the long-term architecture.

Quote

“I genuinely thought this requirement could kill the deal. The clean version would have taken too long, and the quick version could have broken the flow our top client already depended on. Hasan found the version nobody else had seen: simple, clever, and safe enough to ship. He was a lifesaver on this.”

— Product stakeholder, drafted for approval

Lesson

The imperfect answer was the right answer because the goal was not architectural beauty. The goal was getting a major client across the line without damaging the system underneath. My inner engineer wanted the clean artifact: a proper feature, a new model, a polished flow. That would have been self-protection disguised as quality. The lesson I kept is that good engineering under pressure means knowing which imperfections are controlled, reversible, and worth accepting for the business outcome.