Before you accept growth capital with repayment obligations, identify every product choice that cash pressure could force before you have enough evidence to make it well. The map should cover roadmap commitments, customer segments, pricing, hiring, infrastructure, and the experiments you may have to cancel to meet a payment date.
In April 1970, Apollo 13 was headed toward the Moon when an oxygen tank exploded. The landing was abandoned. Gene Kranz and the teams in Houston had to work with the spacecraft they had, including a lunar module built for two astronauts for a short stay, then use it to help return three people safely to Earth. NASA’s Apollo 13 mission archive documents the mission as a rescue operation whose outcome was uncertain for days.
A repayment date creates a smaller version of that constraint. It turns decisions that once had room for iteration into decisions made against a calendar.
Repayment changes the job your product must do
A product can begin with a narrow, useful job: help a Ghanaian retailer reconcile orders, help a Berlin logistics team remove a manual approval step, help a US SaaS team test whether customers trust an AI recommendation.
With flexible capital, you can stay close to that job while you learn. You can reject a large customer request that pulls the product sideways. You can wait before hiring. You can run the inconvenient experiment that shows whether people will pay.
Once repayments enter the operating calendar, the product may acquire a second job: produce cash on schedule.
That is when seemingly temporary choices become structural. You take the integration work because the customer pays now. You promise custom reporting because it closes a contract. You raise prices before the product has earned the right to raise them. You put the founder on sales calls all week and delay the work that would make sales less founder-dependent.
Each decision can make sense in isolation. Together, they can change what the company is building.
The risk deserves the same attention as a buyer request that becomes a second product. What happens when a buyer changes your product beyond recognition? explores that problem from the product side. Repayment pressure adds a date to it.
Make an irreversible-decisions map before the money arrives
Write down the decisions the capital would make easier to take, then mark which ones would be hard to undo six months later.
Start with the roadmap. Which planned work serves repeatable demand, and which work would exist mainly to generate near-term revenue? A contract can fund the company while also filling the codebase with commitments that future customers never asked for.
Then look at customer concentration. If one overseas client becomes necessary to cover a payment, ask what they can demand in return. More seats may be harmless. A dedicated workflow, country-specific rules, or a second product surface can shape every release that follows.
Hiring deserves the same scrutiny. A senior engineer, sales lead, or implementation team changes the monthly cost base. That can be the right move when demand is proven. It becomes dangerous when the hire exists mainly because the capital makes payroll feel temporarily affordable.
Also map pricing. Discounted annual deals, advance payments, and service-heavy contracts can make a revenue graph look healthier while making the product harder to operate. The cash arrives first. The delivery burden arrives every week after.
Put each choice in one of three columns: reversible, expensive to reverse, and identity-changing. If you cannot name the exit path, treat the choice as identity-changing.
Protect the learning loop that created the product
The most valuable asset in an early-stage company is often the ability to change its mind after contact with customers. Repayment can weaken that ability before the founder notices.
A team stops asking, “What are we learning from this customer?” and starts asking, “Will this invoice clear in time?” Both questions matter. The second can crowd out the first.
Set explicit boundaries before signing. Decide what percentage of engineering time can go to custom work. Decide which customer requests require a product decision rather than a sales decision. Decide what revenue concentration would trigger a review. Decide which experiments remain funded even during a difficult month.
Those boundaries are easier to hold when they were written before the capital arrived. During a tight week, every exception will sound rational.
This is also why hiring before demand has a cost beyond salary. A larger team creates work that needs managing, planning, and protecting. Should you hire an engineer before you know what customers will pay for? is the question to answer before a repayment schedule makes the answer feel urgent.
Use the repayment calendar as a product test
A repayment schedule can expose a useful truth: the company may need a business model that produces cash more predictably than its current product can.
That does not mean accepting any revenue. It means making the trade visible. If a payment depends on a custom enterprise deployment, say that the company is choosing services revenue. If it depends on converting a free AI demo into paid usage, say that the company is betting on activation and retention. If it depends on raising again, say that plainly too.
Apollo 13 did not complete its original mission. The teams changed the mission to bringing the crew home, then made every decision around that constraint. A founder facing repayment dates needs similar honesty: name the operating constraint, then decide which product commitments are worth making to survive it.
Before accepting the money, put the first repayment date on a calendar beside the roadmap. Then ask which planned decisions would still make sense if that date arrived before the next major product learning.
Comments
No comments yet.