Edition #3: Three weeks to the biggest event

Each Saturday, I send one operator an applied lesson on building a business that runs without you. Read time: ~7 min.

Late June. Hot summer. I was the Salesforce architect on a platform we had spent six months building for a global design awards organization.

✅ Submissions worked.

✅ The portal worked.

✅ The judging workflow worked, and UAT was three days away.

❓Then payments stopped going through.

Not all the time, and just on European cards, just when the cardholder reaches the final confirmation step. The portal accepted the entry. The amount queued for capture. The processor returned an error nobody on our team had seen before. About four hours of digging produced the cause: the European regulator had enforced two-factor authentication on online payments, and the payment vendor (US-based, large, well-regarded; selected by the client a year before we joined the project) had not deployed the 2FA module yet.

The fix was small from our side. We needed the vendor to enable the module for our merchant account.

The work to schedule the call with the vendor took a week. Summer, vacations, the usual. When the call finally happened, the vendor was clear and professional and delivered the following line:

"Two-factor authentication has been enforced in Europe, but since it is not mandatory in North America yet, we have not deployed the module. It is on the roadmap. Three to six months."

The client was European. The biggest event of their year, the application window for an international design competition with thousands of paying entrants from around the world, was three weeks away.

I want to stay with that moment for a minute because it is the moment that matters. Not the weekend I am about to describe. The moment on the call.

Because:

↳ The contract was signed.

↳ The integration was built.

↳ The client had announced the dates.

↳ The judges were lined up.

↳ The marketing was already out.

And the vendor, politely, on a recorded call, had just told us that none of that was their problem.

Before I tell you what we did that weekend, I want to tell you what the client should have asked a year earlier when the vendor was selected.

The contract said the vendor was PCI compliant → True.

It said they had US enterprise references → True.

It said they had been processing payments for fifteen years → True.

It said they handled billions of dollars per year → True.

It did not say what happens when regulation in the client's market changes ahead of regulation in the vendor's market.

That was the actual question. Nobody at the client's procurement stage thought to ask it because it sounded like worst-case paranoia. It is not paranoia and it is base-rate. Once your company crosses any meaningful threshold of complexity, of geographic reach, of regulatory exposure, this scenario stops being theoretical. It becomes a question of when.

What the contract should have said: a service level commitment on regulatory change, with a defined window (90 days, not 6 months) and a clear escalation path when that window cannot be met. Not a feature request queue. A contractual obligation.

The vendor I am describing was not a bad vendor. They were a vendor optimized for a specific market (US-only mid-market processors) sold into a project with global exposure. The mismatch was invisible at signing and decisive at delivery. The wrong question got asked at procurement, and a year later, on a Friday afternoon in late June, my coffee machine was being asked to do things coffee machines should not be asked to do. The client's procurement team was at home.

After the roadmap line, we spent two hours on the call.

The vendor offered workarounds. Each one had a flaw:

↳ Manual reconciliation: would not pass audit.

↳ Off-platform processing: PCI scope explosion.

↳ Custom integration on their staging environment: not a production-supported path, would void our merchant agreement.

Two hours of someone politely telling us that their plan was their plan, and the world should accommodate.

Notice the shape of this. The vendor was a large, established company with hundreds of clients. We had three weeks. The vendor's incentive was to protect their roadmap. Our incentive was to ship. Nobody on the vendor's side would lose their job if we missed our event. Several people on our side would.

This is the part where operators learn slowly. In vendor relationships, schedule pressure is asymmetric. The party with the calendar problem has all the urgency. The party without it has all the leverage. A good contract balances this, and unfortunately, most contracts do not. Most contracts are drafted by the vendor's lawyers, reviewed by the client's procurement team, and signed at a moment when nobody is imagining the late June phone call where the asymmetry will become visible.

I will be brief about the weekend because the weekend is not the lesson.

I told the client and the team to give me until Monday at 11 AM. I spent Friday night, Saturday, Saturday night, and Sunday on an alternate integration path. The path used the vendor's existing infrastructure in a way they had not designed it for, but had not explicitly forbidden. It maintained PCI compliance if you read the documentation carefully. It required about thirty-five hours of work and a second cup of patience from a coffee machine that started making a clicking sound by Sunday afternoon.

Monday at 11 AM, the client tested the payment flow with a European card and 2FA. It went through. The team was relieved. The client was relieved but skeptical. Testing continued through the week, and finally, the event opened on schedule.

The applications came in. The vendor never knew we had built a workaround on top of their platform.

Here is what the weekend cost: one person away from family for three days, a project that would have been wildly over budget if we had been billing by the hour, and a delayed but unavoidable conclusion that the vendor was the wrong vendor for this client all along.

The client had picked them based on price, references, and reputation. Nobody had asked the regulatory-divergence question. That oversight cost my team a weekend. For a different operator, on a different project, with a different implementation partner unwilling to absorb the gap, it could cost a contract or a company.

I am the implementation team, even though I was the Architect on the project and had no business being a hands-on developer. I am the one who sat on the other side of that weekend. So when I say this, I am saying it as the person who paid for a procurement decision I had no part in.

This is what I now ask every founder who is selecting an enterprise vendor and cannot afford a 50-hour weekend six months from now.

1. What happens to my contract when the regulation in my market changes ahead of yours?

Get the answer in writing. "We follow our published roadmap" is the wrong answer. The right answer specifies a window (60 to 90 days is reasonable for most regulatory triggers) and a defined escalation path. Vendors who refuse to commit to a window are telling you something honest about how they will behave when it matters.

2. Who at your company has the authority to accelerate a roadmap item for a paying client?

Get the name. Confirm the person exists. Ask how often they have used that authority in the last year. If the answer is "the product committee meets quarterly," you are looking at a 90-day minimum response time on anything that matters. That may be fine for your situation, but it also may not. Either way, you should know.

3. Show me your last three regulatory-driven feature deliveries and how long they took from request to production.

This is the only data point that predicts what they will do for you. References tell you what the vendor wants to be. Past behavior under regulatory pressure tells you what they are.

4. What is the cost of exit?

If they cannot deliver in your window, what does it cost in time, integration debt, and operational disruption to switch? If exit is "impossible," you do not have a vendor. You have a counterparty in a hostage situation, and the counterparty knows it before you do.

These four questions take an hour to ask, but they save weekends. Sometimes they save companies. Most procurement processes do not include them.

The client renewed their contract with us for a second year. They also renewed with the payment vendor.

The switching cost was higher than the cost of working around the limitation. Their procurement team did the math and decided that the pain of the weekend, absorbed by my team (mostly me, actually) and not theirs, was cheaper than the risk and disruption of a vendor change. They were not wrong about the math. They were also not the ones who lost the weekend.

That asymmetry is the real lesson. The client's procurement team made a vendor decision a year before delivery, and the cost of that decision was paid by people who were not in the room when it was made. The renewal was the proof. They could renew because the pain was not theirs.

This is the part of the story that took me the longest to understand. Vendors are not adversaries. They are scheduled. Your job at the moment of signing is to know whose schedule you are joining, and to know that the people who will pay for that schedule's gaps may not be sitting at your procurement table. If their schedule does not have room for your reality, the price on the contract is not the real price. The real price is what someone, somewhere in your delivery chain, will pay later, in weekends and unbilled work, to absorb the gap between their roadmap and yours.

You can sign anyway. Sometimes you have to. But you should know.

Reply with one thing. What is one vendor in your stack right now whose roadmap is incompatible with your reality? If you could redo procurement today, what would you change in the contract?

I read every reply.

Iulian