A prestigious partnership can quietly replace your roadmap with a custom product for one institution. Before accepting the logo, separate the distribution value from the engineering, compliance and support obligations hidden inside the offer.
At 3:17 p.m., Kojo saw the institution’s logo in the subject line while sitting in a small meeting room in Accra. His co-founder had already covered the whiteboard with Friday’s roadmap options: improve onboarding, fix the unreliable document parser, or delay both and preserve cash.
Kojo is a composite, but the decision is familiar. The attached proposal promised access to a respected financial institution and a credible name for future conversations. It also asked for a private deployment, a separate approval flow, institution-specific reporting and support during business hours in another time zone.
Roadmap planning started in forty-three minutes.
If Kojo said no, the institution could choose another startup and the team might lose its best distribution opportunity that year. If he said yes as written, six months of product work could become a service contract wearing a partnership badge.
The requirements behind the logo
Kojo copied every requested obligation into a blank document. Then he removed the institution’s name.
The offer looked different immediately.
Without the logo, he saw four separate products: the SaaS product his team had planned, a private version for one partner, an internal reporting tool and a support operation. Each could be reasonable on its own. Together, they would put a six-person company on four roadmaps.
The problem was deeper than engineering capacity. The proposed deployment would create a second operating model. Releases would need another approval path. Bugs might appear in one environment and disappear in the other. A feature requested by the institution could be urgent for them while irrelevant to every smaller customer Kojo hoped to serve in Ghana, Nigeria and later Europe.
Prestige had compressed those costs into one word: partnership.
I have seen founders evaluate offers like this by asking whether the contract covers the next few hires. That matters, especially when runway is short. The harder question is what the team will become while earning that money.
A contract can fund the company and still pull it away from the product it intended to build.
A partnership needs a product boundary
At 3:41, Kojo drew a line down the whiteboard. On the left, he wrote what the current product could support for every customer. On the right, he wrote what existed only because this institution had asked for it.
The private deployment landed on the right. So did the custom reports and separate approval flow. The integration work sat across both columns because part of it could become reusable.
That distinction gave him a negotiating position. He could accept requirements that strengthened the shared product, price institution-only work separately, and refuse obligations that created a permanent fork.
This was the same underlying danger in the separate deployment Kofi refused. A second environment sounds like an infrastructure choice during the sales conversation. After launch, it becomes another place to test, monitor, secure and explain.
Kojo added three conditions to the draft:
- New capabilities would enter the main product when they served the wider roadmap.
- Institution-specific work would have a defined scope, owner and review point.
- Any separate deployment would carry its full ongoing cost, including support and release management.
The logo remained valuable. It simply stopped receiving free authority over the roadmap.
The revenue question comes second
Founders often start with contract value because it feels measurable. Product displacement is harder to put in a spreadsheet.
Kojo tried anyway.
He marked the features that would slip if the team accepted the proposal unchanged. The unreliable parser would remain in production longer. Onboarding work would move to another quarter. Two smaller prospects had asked for changes connected to both areas, so the delay could affect revenue that was less impressive individually but more aligned with the product.
This is where runway decisions become uncomfortable. Cash from one large institution may arrive sooner than revenue from a repeatable product. Yet the cash can also increase payroll, hosting and support commitments before the company has learned whether the partnership can be repeated.
The right comparison is wider than “contract versus no contract.” It is the offered contract versus the customers, learning and product reliability the team must postpone to deliver it.
That reasoning also shaped why Kabelo kept customer insight over compute. Limited runway makes trade-offs unavoidable. It does not make the largest visible opportunity the correct one.
The decision at 4:26
Fourteen minutes before the roadmap meeting, Kojo replied with a narrower proposal.
He accepted the shared integration work and the chance to test distribution through the institution. He moved custom reporting into a separately priced phase. He declined the permanent product fork and asked for a joint review before any private deployment work began.
The institution could still walk away. That possibility did not disappear when he pressed send.
For the next week, the team had no answer. Kojo had to plan as though the logo would vanish from the pipeline, while knowing a faster yes might have secured it. The doubt was real because the company needed revenue and had no guarantee that its smaller prospects would close.
The eventual turn was modest: the institution agreed to discuss the narrower scope. No celebratory announcement followed. There was still procurement, technical review and the possibility of failure.
But on Monday morning, the whiteboard still held one roadmap.
That is the practical test I would keep. Put the institution’s name aside, list the operating obligations, and ask whether you would build that product for an unknown customer at the same price. If the answer changes when the logo returns, you are pricing prestige rather than work.
Comments
No comments yet.