When runway is short, the safer roadmap is often the one that puts a usable service in customers’ hands before the full infrastructure exists. A cash-assisted workflow can test demand this week, while six months of bank integrations may only prove that the team can integrate with banks.
Picture Sami, an illustrative composite of several early-stage founders I have met across African and European markets. At 4:40 on a Tuesday afternoon in Tunis, he was holding a printed integration plan covered in blue ink while his technical lead waited beside a laptop showing another failed test transaction. The roadmap required six more months. Their runway did not offer six quiet months.
The choice hidden inside the architecture
Sami’s product would help small businesses collect payments, reconcile them and move funds through local banking channels. The original plan looked responsible: connect directly to each bank, automate the transfer path and release a finished experience.
Customers liked the presentation. They also kept asking when they could use it.
One potential customer had reached the point where interest required an answer. If the team could support the customer’s next payment cycle, the relationship could move forward. If they could not, the customer would keep using spreadsheets, phone calls and the existing bank process. Sami’s team could lose the account before learning whether the underlying product solved anything worth paying for.
The technical lead wanted to protect the architecture. Sami wanted to protect the company. Both positions were rational.
This is where roadmap conversations become misleading. The visible choice was between a direct bank integration and a manual workflow. The actual choice was between learning from a live transaction now and learning from an integration project months later.
Six months of engineering could answer, “Can we connect these systems?”
It could not answer, “Will a finance manager trust us with this workflow twice a week?”
What the cash-assisted version had to prove
The alternative was deliberately narrow. The customer would initiate the request through the product. Sami’s team would verify the details, guide the payment through existing channels and record the result in the system. Humans would cover the gaps that bank integrations were meant to remove later.
This created uncomfortable work. Someone had to monitor each request. Exceptions would arrive through calls and messages. Reconciliation would take attention that software could eventually save.
Still, the workflow could reveal the facts that mattered first: who initiates a transaction, which information arrives incomplete, where trust breaks, how often the process repeats and whether anyone pays to avoid the current mess.
The distinction matters. Manual work can be useful when it exposes the sequence software should eventually handle. It becomes dangerous when the team treats repeated labour as a permanent business model or hides the true cost of serving each customer.
I would set three boundaries before shipping this version. Limit the customer group. Define the transactions the team will support. Record every manual intervention, including the reason it was needed and the time it consumed.
That record becomes the integration roadmap. The team builds against observed friction instead of imagined completeness.
This is the same discipline behind asking what Monday must prove after Friday’s demo wins the room. Applause, interest and technical progress matter less than the next behaviour you can observe.
Runway changes what “safe” means
Founders often describe delay as the cautious option. They want another integration, another approval or another round of automation before asking a customer to depend on the product.
With ample capital, that caution can buy polish. With limited runway, it can consume the company before the market gets a vote.
Sami’s bad ending was concrete. The team could spend most of its remaining runway completing connections, then discover that customers would not change their payment habits. A technically correct release would arrive after the useful decision window had closed.
The cash-assisted version carried different risks. It could create operational errors. It could become expensive to support. Customers might reject a workflow containing human steps.
Those risks were visible within days. The integration-first risks stayed hidden for months.
So Sami crossed out the six-month launch date and wrote a smaller promise beneath it: support one defined payment flow for a small customer group, with every manual step logged. The team would continue integration work only where real transactions showed repeated pressure.
The roadmap lost that Tuesday because survival required evidence sooner than the architecture could provide it.
Build the automation from the queue
By the following week, Sami was no longer debating every possible bank connection. He was watching where actual requests stalled.
One customer repeatedly sent incomplete recipient details. Another needed confirmation before releasing funds. A third completed the process without asking for the feature the team had considered essential.
Each case changed the build order.
The first automation removed a repeated verification step. The next improved transaction status updates. A broader integration remained on the roadmap, but it now had a reason to exist beyond making the product diagram look complete.
This approach also has a stopping rule. If customers will not tolerate the assisted workflow, will not repeat it or will not pay enough to cover the manual burden, the team should resist dressing that result up as “early traction.” The failed test has saved months of runway.
On Friday afternoon, Sami’s blue-marked integration plan was still on the table. Beside it sat a shorter page containing the week’s transaction exceptions, written in the order customers had encountered them. That page was messier.
It was also the first roadmap built from reality.
Comments
No comments yet.