"Ship fast" is romanticised so much that we now treat speed like a product virtue on its own, whereas I don't think it is. I think speed is useful when it serves the product. If someone has a "long" timeline, already has a user )even if it's for internal use), and is learning from actual usage, I don’t think they should be pressured just because people keep saying "just ship it." I think you should take the time to build something you are comfortable attaching your name to, especially if it is a passion project. Whether you launch in two weeks or five months, if the product has no unique workflow, proprietary data, integration depth, switching cost, network effect, distribution advantage, or some other form of defensibility, it is still clonable and replaceable. Shipping faster does not and will not fix that. And when you look at many of the products being pushed to "just ship", you find out that they do not even pass basic accessibility checks, not to talk of proper accessibility verification, security, privacy, compliance, reliability, interoperability, and the other things serious customers eventually care about. One thing we need to keep in mind is that there is a difference between a software that runs and software that is ready to be adopted. So instead of asking only how fast you can ship, I think you should also ask what gets harder to replace the longer a customer uses this product. Maybe it is the workflow, accumulated data, integrations, collaboration history, institutional knowledge or maybe even just trust. Those things take time to build. With all said and done, taking your time should not be an excuse for endless perfectionism. Feedback still matters, as well as real users. But deliberate development is not the same thing as fear of shipping. Six months is not a long time if those six months produce something better, harder to replace, and easier for serious customers to trust. The market will care much less about whether you launched three months earlier than whether you built something people would actually notice if it disappeared. At the end of the day, I think the most important thing is to have enough information and engineering discipline to do the right thing at the right time for that particular product.

The Dangote Refinery IPO did more than overwhelm Bamboo and Cowrywise. It exposed a reliability problem engineers discuss far less, that is, when a system starts failing, does the product help it recover, or does the failure experience make the outage worse? Most of the engineering conversation has naturally been about scaling, load balancing, capacity and preventing systems from going down. All of that matters, but if there's one thing we know, it is that at some point, systems will still fail. And the part that is not really discussed is what happens next. Imagine I am trying to buy Dangote shares and the app gives me: "Something went wrong." What do I do? I press the button again. Nothing happens, so I press it again. I refresh the page. I log out and back in. Maybe I open another tab and try again. Now multiply that behaviour by thousands of users while the system is already under pressure. Your error experience will add to the source of traffic. This is why failure states are part of reliability engineering, and the frontend is part of your reliability architecture. When a transaction fails or becomes uncertain, the product should help the user answer a few basic questions like: Was my request received? Is it still processing? Should I retry? If I should retry, when? If I retry, can I accidentally submit the same transaction twice? Can I check the status somewhere instead? Sometimes the right interface during an incident might just be a disabled action with a countdown. A clear "processing" state. A status page. A queued request. Automatic retry with controlled backoff. Or simply telling the user to wait five minutes before trying again. Behind that experience are deeper engineering decisions like idempotency, rate limiting, circuit breakers, retry policies, backpressure and load shedding. But users experience all of those decisions through the product. GitHub recently documented an outage where retry behaviour amplified traffic during recovery. The original failure was one problem. Requests repeatedly trying again became another. That is the part I think frontend engineers and product teams should pay more attention to. We spend a lot of time designing the happy path: Click Buy -> Process Payment -> Success. We should spend just as much time thinking about: Click Buy -> System is degraded (eg: third-party PGS unreachable) -> What should happen now? This becomes even more important in financial systems. If my money is involved, "Error 503" is not enough. "An error has occured" is not enough (UBA is on this table). I need to know whether my instruction went through, whether my money is safe, and exactly what I should do next. As we design systems, we should keep it in mind that resilience is also designing the product so that when the system starts failing, users do not unknowingly help it fail harder.