When monthly repayments start, hire the operator who can shorten the path to cash unless a clearly defined engineering gap is already blocking revenue. Debt changes the hiring test: the next role must protect the repayment calendar as well as the product roadmap.
In 1970, Apollo 13 had a problem that could not wait for the ideal solution. The lunar module had round lithium hydroxide canisters; the command module had square ones. Carbon dioxide was rising, and the crew needed the square cartridges to work in the round system. Engineers at Mission Control designed an adapter from materials already on board, then passed the instructions to Jim Lovell’s crew. NASA’s Apollo 13 Flight Journal records the work.
That was a constraint problem, not a talent-shopping exercise. Mission Control did not ask which specialist would make the spacecraft better six months later. They asked what had to happen before the next life-support limit arrived.
A repayment schedule can create the same discipline for a startup.
Repayments turn runway into a calendar
Equity funding gives you room to make a longer bet. You can hire an engineer to build a capability, run customer discovery alongside it, and wait for the learning to compound.
Capital with monthly repayments creates a date that does not care whether the product is becoming more elegant. The repayment arrives while the AI feature is still being tuned, while a prospective customer is still reviewing a proposal, while an integration is still blocked by someone else’s API.
That does not make an engineering hire a bad decision. It means the hire needs a direct line to cash within the period your business can carry. If your strongest prospects have already said yes pending a security review, a missing integration, or a feature that an engineer can ship quickly, the roadmap hire may be the practical cash hire.
The mistake is treating every technical gap as revenue-critical because the product matters to you.
I have seen founders in Accra, Berlin, and the US make this harder by describing the choice as “build versus sell.” The real question is narrower: what stops a named buyer from paying in the next few months? Sometimes the answer is code. Often it is onboarding, proposals, collections, implementation, follow-up, or a sales process that only exists in the founder’s head.
Name the revenue block before opening the role
Before writing a job description, make a short list of current opportunities. Put a real company or customer type beside each one. Then write the next action that moves each opportunity toward money received.
If the same technical requirement appears repeatedly, hire the engineer who can remove it. Be specific. “Customers need the product to connect to their existing data source before signing” is a case for engineering. “We have demos but no repeatable way to turn interest into a paid pilot” is a case for an operator.
The operator can be a commercial lead, implementation person, customer-success generalist, or a founder-level chief of staff who owns the unglamorous work between interest and payment. The title matters less than the work: keeping deals moving, turning customer requirements into decisions, getting invoices issued, and spotting where the product is being bent into a second bespoke business.
This is where the hiring decision connects to whether you should hire an engineer before you know what customers will pay for. A roadmap can look urgent from inside the company. Payment is the evidence that tells you which part of it deserves the next person.
Treat the hire as a repayment decision
A useful exercise is to write the hire’s first 90 days against the repayment schedule.
For an engineer, define the customer outcome rather than a feature list. “Enable three active pilots to upload and review their own documents” gives you something to test. “Build the AI workflow” gives you a large surface area to admire and little help deciding if the hire is working.
For an operator, define the commercial handoff. “Move qualified pilots from demo to signed scope, implementation, invoice, and first use” is concrete. “Help us grow” leaves the founder carrying the same decisions after payroll has increased.
You also need an honest downside case. If the hire takes longer to ramp than expected, can repayments still be met? If one customer slips, does the plan still work? A role funded by debt should survive more than the optimistic forecast.
This is not an argument for starving the product. It is an argument for sequencing. An operator who turns existing demand into cash can buy the engineering time you actually need. An engineer who removes the one obstacle holding back signed revenue can earn the same priority.
Build the adapter that gets you through the constraint
The Apollo 13 adapter did not become the permanent design for spacecraft life support. It solved the immediate constraint with the materials available, and it helped bring the crew home.
Your first hire under repayment pressure may carry that same temporary purpose. They may not be the person who owns the company’s eventual product architecture or commercial organisation. They need to make the next period safer by converting a known blockage into cash, evidence, or retained customers.
Write down the next repayment date. List the customers most likely to pay before it. Then hire for the one constraint connecting those two facts.
Comments
No comments yet.