The right move is to ship the WhatsApp off-ramp behind strict limits while keeping the cleaner compliance path as the destination. The weekend release should test one narrow behavior before Monday, without turning a temporary workaround into the product’s operating model.
At 4:47 PM on Friday, Chinedu was staring at two diagrams on a whiteboard in a small Lagos office. One showed the payment flow his compliance adviser preferred. The other ended with a WhatsApp message, a manual confirmation and an operations lead checking each request before releasing funds.
Chinedu is an invented composite, but the decision is familiar. His fintech had spent weeks teaching a small group of merchants how to move money through a new workflow. By Monday, several of them would start another trading week. If they returned to their old process, the product might lose the chance to become part of their routine. If he shipped the WhatsApp route carelessly, one disputed transaction could create a compliance problem the company could not afford.
The cleaner path could arrive after the habit had formed elsewhere
The team’s preferred flow kept everything inside the product. It produced clearer records, required less manual interpretation and gave the compliance adviser fewer reasons to worry.
It also needed more work.
One engineer believed they could finish it the following week. Another had already found two edge cases in the identity checks. Chinedu had heard “next week” before, usually just before a new exception appeared.
The WhatsApp option was already understandable to merchants. They used it to place orders, confirm deliveries and send payment evidence. No training session was required. A merchant could make a request in the same place where they already handled the rest of the day.
That familiarity mattered. Early products often compete against an existing habit rather than another startup. The spreadsheet, voice note or group chat looks crude from inside a product meeting, yet it survives because the customer knows what to do when something goes wrong.
I have seen teams underestimate that difference while building AI and automation products. The demo proves the system can complete the task. The real test begins when a customer is tired, distracted and holding an older phone on a Monday morning. Sibusiso’s older phone failure is another version of the same product decision: the polished path matters less when the customer cannot complete it.
A temporary off-ramp needs a removal condition
At 6:15 PM, Chinedu’s operations lead asked the question that changed the discussion: “If we ship this, when do we stop?”
Until then, the team had treated the choice as release versus delay. Her question exposed a third option. They could release a constrained route whose purpose was to gather evidence, then remove or replace it once that purpose had been served.
They wrote down the boundaries before anyone touched the code. The route would serve a limited group of merchants. Every request would require manual review. The team would cap exposure at a level they could absorb. No request would complete without a traceable internal record. Any ambiguity would stop the transaction.
Most importantly, they defined what they needed to learn by Monday: Would merchants initiate the process without being prompted? Where would they hesitate? Which questions would appear repeatedly? Would the manual checks reveal exceptions the product flow had missed?
Those questions turned the weekend release into a test. Without them, the WhatsApp route would become another piece of permanent temporary infrastructure, quietly consuming an employee’s evenings.
A workaround earns its place when it reduces uncertainty faster than it adds risk. The boundary must be explicit because convenience has gravity. Once customers and staff adapt to a manual route, removing it becomes harder than launching it.
Compliance and speed belong in the same decision
Founders sometimes place compliance and shipping on opposite sides of the table. That framing produces weak choices. The useful question is how much behavior can be tested without creating an exposure the company cannot observe, limit or reverse.
Chinedu could control who entered the test. He could require a human decision before money moved. He could pause the route if the records stopped matching. Those controls made a narrow release possible.
If the team could not define those controls, delaying would have been the correct call.
This distinction matters for small teams on limited runway. A full product build consumes time before demand becomes clearer. An unrestricted shortcut creates operational debt before the company understands its consequences. The middle path works only when the founder can name the risk, assign someone to watch it and specify the event that stops the test.
The same reasoning applies beyond fintech. Before automating a workflow, I want to see the manual exception that breaks it. Before adding another engineer, I want evidence that engineering capacity is the constraint. Before turning a WhatsApp interaction into a permanent feature, I want to know which part of the conversation customers actually value.
That is why the shared spreadsheet a demo missed matters. Informal tools often contain decisions the polished interface has not yet learned to represent.
Monday should produce evidence, not relief
On Sunday evening, Chinedu reviewed the release conditions again. The team had built a door they could close, rather than a second product they would have to support indefinitely.
By Monday, success would not mean that money had moved. It would mean the team could explain what merchants did, where manual judgment entered the process and which controls belonged in the final flow.
The cleaner path still mattered. The weekend test could make it cleaner for the right reasons.
At 4:47 PM, Chinedu had been choosing between delay and speed. By Sunday evening, the decision had become narrower: how little could they ship to learn what Monday would otherwise hide?
Comments
No comments yet.