When payroll and the cloud bill compete for the same cash, protect the smallest production footprint that keeps paying customers online, then preserve as much payroll as possible through direct, early agreements with the team. The decision should follow customer dependency and recoverability, rather than whichever invoice creates the most panic.
At 4:17 on a Friday afternoon, Daniel, an illustrative composite founder in Accra, was holding a mug of tea he had reheated twice. His finance sheet showed enough cash for one clean outcome: pay the five-person team in full, or clear the cloud balance keeping customers online in Ghana, Germany and the US.
4:17 PM: Two obligations, one balance
The provider’s warning left little room for interpretation. If Daniel did not pay, production services could be restricted. The exact timing was unclear, which made the risk harder to contain.
Payroll was due. Two team members had already mentioned rent and family commitments during the week. Paying late would transfer the company’s cash problem directly into their homes.
Yet letting the service go offline could trigger another failure. Customers in three countries depended on it during different working hours. A Friday evening outage in Accra could become an unanswered support thread in Germany, followed by a failed Monday morning in the US.
Daniel’s first instinct was to pay payroll and deal with the infrastructure later. Salaries felt personal because they were personal. Then he opened the customer dependency list.
One customer used a scheduled process over the weekend. Another needed access before Daniel’s team would return on Monday. If both failed, the company risked losing the revenue needed for the next payroll too.
The bad ending was now visible: five salaries paid on Friday, customers offline by Saturday, and no credible answer when they asked why.
5:00 PM: Find the minimum service that must survive
Daniel stopped treating the cloud bill as one indivisible expense.
He and Ama, the engineer still online, traced what paying customers actually touched. The demo environment could sleep. Internal analytics could wait. Old test instances had no reason to run through the weekend. A background feature under development could be paused without affecting a customer.
The production database, authentication service and scheduled customer jobs had to remain available.
That distinction changed the decision. The choice had looked like people versus infrastructure. The real choice was how little infrastructure the company could safely keep while protecting the revenue that paid those people.
This is the same discipline behind a deployment rehearsal: identify the component whose failure changes the business outcome, then test every assumption around it. Kojo’s experience with technical debt and runway shows why discovering those dependencies during a live incident costs more than finding them earlier.
By 5:42, Ama had a shutdown sequence. Daniel still had no guarantee that reducing usage would prevent restriction. The outstanding balance remained, and payroll remained due.
6:10 PM: Make the human cost explicit
Daniel considered splitting the available cash quietly: partial salaries now, cloud payment immediately, explanation on Monday.
He rejected the silence.
A founder can decide which server pauses. A founder should not privately decide which personal obligation an employee will miss. Delay without warning removes the team’s ability to plan.
At 6:10, Daniel called each person. He explained the constraint plainly: production required payment that evening, the company could send most of payroll now, and the remaining portion depended on a customer receipt expected the following week. He did not describe that receipt as guaranteed.
One person asked whether customer funds had already cleared. No.
Another asked what would happen if they did not. Daniel had to say the uncomfortable part aloud: he would defer his own pay, cut every non-customer service still running and return with a dated cash plan rather than another promise.
The team could have refused. Someone could have decided that a company unable to meet payroll had already made the decision for them.
For several minutes, Daniel waited with his phone face down beside the cold tea.
The agreements came in one by one. They did not make the situation good. They made the trade-off visible and consented to, with his own compensation absorbing the first loss.
7:03 PM: Keep the company alive without hiding the damage
At 7:03, Daniel paid the amount needed to address the cloud account, sent the agreed payroll portions and saved the confirmation records. Ama completed the shutdown sequence and checked the customer paths from outside the company network.
Before leaving, Daniel added three controls to Monday’s work.
Cloud payment risk would appear in the weekly cash view beside payroll, rather than inside a technical dashboard. Every production service would have an owner and a written answer to one question: what customer outcome fails if this stops? The company would also keep a smaller operational reserve separate from money already committed to salaries.
The reserve would take time to build. That part remained unresolved.
On Monday morning, the scheduled customer job completed. The team logged in knowing what had happened, what remained unpaid and when Daniel would update them. No triumphant message followed. There was only a smaller cloud footprint, a difficult promise written down, and Daniel’s third cup of tea sitting untouched while he checked the incoming customer payment again.
Comments
No comments yet.