Every Choice Makes Sense. Yet There May Be No Room Left for the Future.

After watching a video about Bethlehem Steel, I thought again about the earlier discussion of Walmart and Kmart. What interests me is not who was smarter. It is this: when we say a line of business is not worth pursuing, is there too little demand—or does our way of working make it unviable?

In the steel example, large mills had reasons to reserve resources for more profitable markets. Smaller mills used different production processes and cost structures, accumulated capabilities at the lower end, and moved upward. This is the Christensen Institute's analysis of the development of minimills, not a complete explanation of Bethlehem's rise and fall.

Walmart makes me think about another side. One small-town store may seem too small, viewed alone. But behind the store are shared procurement, distribution, and operating capabilities. The business did not just lower prices; it developed practices that could sustain them. Walmart's annual report also distinguishes everyday low prices from everyday low costs.

The two stories are not the same formula for failure. But they bring a question back to metabiz: are good systems really unaffordable for small companies—or are we still serving each small company with the delivery model of a large bespoke project?

SaaS Already Addresses Part of This

If each customer needs new interviews, design, development, and testing, then bears the maintenance alone, costs will naturally be high.

SaaS lets multiple customers use shared product capabilities, spreading development, maintenance, and updates across them. Customers do not need to pay the cost of building a mature function from scratch just to use it.

This is where I think SaaS and Walmart can be understood together: a small individual customer or store does not have to rely on small, immature capabilities behind it.

But buying SaaS does not mean the work is finished.

Membership sits in one system, orders in another, and frontline staff have their own practices. Each feature may work, while people still move data, reconcile it, and chase answers manually.

If we rebuild the entire system for every customer to close that gap, the costs we just saved may return.

Do Not Rebuild What Is Common. Invest in What Is Different.

The direction metabiz wants to take is to provide mature shared capabilities through SaaS, use AI EDP to connect the data and processes needed to complete the work, and have AI-assisted forward-deployed engineering (FDE) address what genuinely differs for the customer.

AI EDP does not require replacing POS, ERP, or CRM systems that already work. Start with one part of the work. Establish where data comes from, where it goes, when it is exchanged, and who handles errors. Then connect the parts that are needed.

FDE is not simply an engineer waiting for a document before writing code. It means getting closer to the customer's work, understanding the problem, implementing a solution, and checking whether the result can actually be used.

For example, the customer may not need another report. They may need to stop spending time comparing two sets of orders every day. We should first check whether that reconciliation can be reduced and what happens when data disagrees—not merely show a new screen running.

This is an illustration of the approach, not a customer outcome we have already delivered.

AI can help organize, develop, and check the work, but cannot make responsibility disappear. Commitments, data permissions, exceptions, and acceptance criteria still need to be recorded. Faster direct handling by an engineer should not mean every problem is silently rescued by that person.

After Doing It Once, the Next Time Cannot Start from Scratch

If FDE ultimately means building a completely new custom system for each customer, it has not solved the cost problem.

What matters more to me is whether an integration approach can become a reusable module. Have we retained tests for errors we encountered? Can the delivery method we clarified be used next time without the same person explaining it again?

We share methods, tools, and capabilities—not customers' data mixed together.

Large projects are not inherently bad, and customization is not inherently wrong. Some differences deserve investment. But each customer need not pay again for building the common parts.

This brings me back to the original question of today's article.

Revenue-generating work needs to be completed. But if all our time goes into work we will still have to redo next time, shared capabilities will always wait until we are less busy. Each choice has a reason. Together, they may keep us in the same delivery model.

The room I want to leave for the future is not just for another new product. It is for the work we complete today to make the next engagement more mature too.

Whether we achieve that cannot be judged only by how much AI we use or how quickly code is generated. We need to look back at delivery hours, rework, maintenance load, and whether the customer completed the work they wanted done.

A small company does not need a scaled-down large project. It needs to get important work done with an investment it can afford.

— Adam｜metabiz Founder

Further viewing: 理性避難所｜Bethlehem Steel · Walmart and Kmart. Read the Chinese original.