EP. 05 – Should Software be Designed To Be Replaced?

Every piece of software you build could eventually become legacy code. So should you design it to be replaced from day one? Bosun thinks so. Chinedu isn't entirely convinced. Because while engineers might care about clean architecture, modularity and making systems easier to replace, customers are usually concerned with something else: whether the product actually solves their problem. And for an early-stage startup trying to find product-market fit, every hour spent preparing for a future rewrite is an hour not spent delivering something customers need today. In this episode of **Ramblings of B × C**, we explore the tension between building software that works now and designing systems that can evolve tomorrow. Drawing on our experience building a fintech product together, we revisit some of our early architectural decisions, the mistakes we made when introducing a second version of the application, and what we'd approach differently today. We get into: Why Bosun believes replacement is the default ending for most software. How vendor lock-in and tightly coupled systems make future migrations harder. The problem with legacy code that nobody understands but everyone depends on. Whether startups should prioritise speed or invest in better architectural foundations. What we learned from rebuilding parts of our fintech product. How product-market fit changes the conversation about technical debt. Why designing for replaceability can become another form of premature optimisation. Whether deciding when to replace software is ultimately a product, business or engineering responsibility. The interesting question isn't whether software will change. It's how much you should invest today to make that change easier tomorrow. And sometimes, the best decision might be to leave something that works exactly as it is. *⏱️ CHAPTERS* 00:00 – Introduction 01:42 – Should Software Be Designed for Replacement? 03:22 – Building Replaceable Systems Without Overengineering 04:46 – Vendor Lock-In and Switching Costs 08:38 – Why Replacement Might Be Inevitable 09:42 – The Legacy Code Nobody Understands 14:41 – Do Customers Care About Replaceable Software? 16:54 – Build Quickly or Design for the Future? 20:13 – Is There a Middle Ground? 20:54 – What We Learned Building Our Fintech Product 24:48 – When Good Architecture Becomes Wasted Effort 27:55 – Finding the Balance Before Product-Market Fit 29:27 – If It Isn't Broken, Should You Replace It? 30:12 – Is Software Replacement a Business Decision? --- *ABOUT RAMBLINGS OF B × C* One idea. Two perspectives. 30 minutes. Ramblings of B × C is a conversation between Bosun Olanrewaju (  / bosunolanrewaju  ) and Chinedu Okeke (  / chinedu-okeke  ) about technology, product, engineering, business and the decisions behind building things. No scripts. No manufactured disagreements. Just two perspectives exploring one idea at a time. Subscribe for new conversations. #softwareengineering #softwarearchitecture #legacycode #productmanagement #technicaldebt #startups #ramblingsofbxc