Accept a custom feature only when it strengthens the product you intend to sell again. If it serves one customer’s private process, needs their ongoing direction, or pushes the core roadmap aside, price it and treat it as bespoke work.
Consider Daniel, a composite founder in Accra, with a half-finished cup of coffee beside his laptop and a customer call starting in ten minutes. The customer had kept his small team paid through a difficult stretch. Their request looked manageable in the email: add a custom approval path, generate a different report, and connect it to a process their operations team already used.
By the end of the call, the request had become a second product.
They wanted separate rules for different teams. They wanted edits made by their managers to change how the system behaved. They wanted the work ready before an internal review. Daniel knew what sat on the other side of saying yes: two engineers pulled from the workflow his team had promised other prospects, a growing branch of code only one customer understood, and a product demo that would quietly become a services pitch.
Saying no carried its own risk. This customer was paying the invoices. A refusal could put the next payroll conversation on the table sooner than he wanted.
The request that sounds like revenue
A customer-funded feature can feel like validation. Someone has seen enough value to ask for more, and they may be willing to pay. For a founder with limited runway, that can be hard to separate from the need to keep the company alive.
But a paid request answers two different questions. The first is whether the customer has a real problem. The second is whether solving it creates a capability other customers can use.
Daniel’s customer had a real problem. Their approval process had grown around specific people, exceptions, and internal reporting habits. The proposed work would reduce their manual effort. It would also encode decisions that belonged to their company alone.
The bad ending was not an angry call. It was quieter: three months later, Daniel’s team would be maintaining a private system for one account while the product they meant to build remained stuck in slides, partial prototypes, and postponed conversations. The customer would have bought delivery capacity. Daniel would have lost the chance to learn whether the broader market wanted the original product.
That distinction matters most when the request arrives from the person making payroll possible.
Put the request through the same test as the roadmap
Before committing, I would ask the customer to describe the decision or workflow behind the feature, not only the screen they want built. “We need a custom report” can mean several things. It can mean they cannot see a decision-maker’s bottleneck. It can mean their team has no reliable record of what happened. It can also mean they need a report formatted for one internal meeting.
Those are different jobs.
A useful conversation separates the shared problem from the customer’s preferred implementation. Daniel could ask: Which part of this workflow would another company recognise? What breaks if it stays manual? Who owns the process after launch? What would a version that works for other teams need to leave out?
That last question is usually where the roadmap splits.
If the generalisable part is clear, it can earn a place on the product roadmap. The customer may get early access, a paid implementation, or influence over the order of work. If the value lives in their particular rules and reporting structure, it belongs in a scoped services agreement with a price, a timeline, and an owner on their side.
That boundary protects both parties. The customer gets a candid answer about what they are buying. The founder avoids presenting a custom build as a reusable feature and discovering the difference after the engineering work has started.
The same ownership question appears in Kojo’s pilot lacked an owner. Live queue access stayed unsafe. A workflow with no clear owner turns every later change into an argument about responsibility.
Price the divergence honestly
Custom work can be the right decision. Early companies often need revenue, and founders building across African, European, and US markets will encounter customers whose operational reality does not fit a standard product yet.
The mistake is hiding the cost of divergence.
Daniel’s team could take the work, but the proposal needed to name what it would consume: engineering time, support expectations, integration work, and the features that would move later. It also needed an exit point. Would the customer own the resulting configuration? Would future changes require a new scope? Could the work become a maintained product capability, and under what conditions?
Those details may make the deal smaller. They also stop a “quick addition” from becoming an unpriced obligation.
A customer who needs bespoke software may still be an excellent customer. The engagement just needs to be sold and managed as bespoke software. That clarity is more valuable than a vague promise to “make it work.”
Keep the product decision visible
Daniel went back to the customer with two paths. One covered a reusable approval capability that fit the roadmap, with the customer helping define the real-world edge cases. The other covered their private reporting and rule set as a separate piece of work, with a clear scope and a named person on their team responsible for decisions.
The conversation became more practical. The customer did not have to pretend their process was universal. Daniel did not have to pretend every paid request belonged in the product.
A week later, his engineers were still building the shared workflow. The customer had a document that made the custom work visible before anyone wrote it into the core system. On Daniel’s desk, the coffee had long gone cold. The roadmap was still one roadmap.
Comments
No comments yet.