Ramblings of B x C

“The default ending is replacement.”

That's Bosun's argument in this episode. Every product eventually evolves, and the software we write today might become the legacy code someone else struggles to maintain tomorrow.

But Chinedu has a question: do customers actually care?

In this episode of Ramblings of B × C, we explore whether software should be designed for replacement from the very first line of code.

We talk about vendor lock-in, architectural decisions, legacy systems nobody understands, and the trade-off between shipping quickly and building for the future.

We also revisit our experience building a fintech product together, including an early rewrite that didn't quite solve the problems we thought it would.

And somewhere along the way, the conversation shifts from whether software should be replaceable to a more difficult question: who gets to decide when it's time to replace it?

One idea. Two perspectives. 30 minutes.

“Scale is a problem that you earn.”

It's one of Bosun's many quotable lines from this episode, and it captures something we think more startups should consider.

When we talk about scaling, the conversation usually revolves around engineering: microservices, infrastructure, architecture, and preparing for millions of users.

But what about the product decisions that create unnecessary complexity in the first place?

In this episode of Ramblings of B × C, Bosun and Chinedu explore premature scaling from both engineering and product perspectives.

We revisit our experience building a fintech product together, including why we started with a single EC2 instance, what happened when we expanded the product too early, and the lessons we took from shutting down a feature that wasn't ready.

We also explore how to distinguish foundational investments from unnecessary complexity, why startups need room to pivot, and when preparing for scale early actually makes sense.

Because the question isn't whether your product should scale.

It's whether you've solved the problem well enough to earn that scale.

One idea. Two perspectives. 30 minutes.

Who owns technical debt—and do product and engineering mean the same thing when they talk about it?

In this episode of Rambling of BxC, Chinedu and Bosun discuss the statement: “Technical debt is a product decision.” It sounds like a simple yes-or-no question, but they soon find themselves unpacking deferred features, engineering shortcuts, unfinished work and the pressure to keep shipping.

Chinedu initially sees technical debt through refactoring, database migrations and engineering cleanup. Bosun brings in the product decisions behind what gets built now, what gets left for later, and why teams rarely find the time to return to it.

Such a fun conversation. Both learn in real time, adjusting, adapting and revising opinions they held at the start.

Along the way, they explore:

• When fixing technical debt should take priority over a new feature.
• How performance, reliability and customer impact change the conversation.
• Why engineers need a clear business case for work that users may never see.
• How AI coding agents can help clear old debt while introducing new problems.
• The cost of fixing something versus the cost of leaving it alone.

With practical examples involving workflow patches, caching and traffic spikes, the conversation keeps returning to one question: what is it going to cost if that debt is not paid?

Listen in, and think about how it works on your team: who owns technical debt, and who decides when it gets attention?

Follow Rambling of BxC for more conversations with Chinedu and Bosun as they challenge each other’s perspectives and work things out together.

Should engineers talk directly to customers — or should the product team act as the bridge between customers and engineering?

Bosun and Chinedu both begin this episode saying engineers should have direct customer exposure, but quickly discover they mean very different things by it.

They explore what gets lost when customer problems are translated through product teams, why customer context can improve engineering judgement, the danger of treating customer requests as specifications, and the cost of pulling engineers out of focus time for more meetings.

The conversation eventually reaches a practical middle ground: engineers should sometimes hear directly from customers and ask questions through an engineering lens — but the goal is to understand the problem, not to design the solution live on the call.

One idea. Two perspectives. 30 minutes.

---

Music licensed through Soundstripe.

Code: UXJOJSL7LZOZPXMQ

Most startups don't need a Product Manager the way the industry usually defines one. So what do they actually need?

In our first episode, Bosun and Chinedu unpack one of the most misunderstood roles in tech — and what product management is really supposed to do.

We talk about:

• Why very early-stage startups may not need a dedicated PM
• Why founders are often the first product managers
• The difference between owning product decisions and managing product operations
• When a startup actually needs someone focused full-time on product
• Whether AI changes the role of the Product Manager
• Why product management is ultimately about maximising value for the customer and the business

Bosun brings firsthand experience from building products at an early-stage startup, while Chinedu pushes the conversation toward a broader question: if product management isn't about Jira tickets and sprint ceremonies, then what is it actually for?No manufactured debate. Just one idea, two perspectives, and 30 minutes to see where it goes.