Cars were originally custom, one-off products. They were expensive to build, their parts were not reliably standardized, and even components intended for repeated production often needed fine-tuning before they worked properly. Building and maintaining them required scarce and highly skilled workers.

The demand for transportation already existed. The production system simply could not meet that demand at a price most people could afford.

As the automobile industry began to coalesce, manufacturers developed more precise and interchangeable parts. Ford then combined those parts with specialized labor and a moving assembly line, borrowing ideas from several industries, including meatpacking. The meatpacking version, part of the same brutal industrial world Upton Sinclair described in The Jungle, moved the product past workers who performed the same repetitive motions. Ford and his engineers effectively turned that disassembly process around.

By moving standardized automobile parts through a repeatable production system, Ford dramatically reduced the time and skill required at each stage of assembly. The result was a more consistent product at a much lower cost.

I think we are watching a similar pattern develop in software.

For much of its history, custom business software resembled those early automobiles. Skilled software engineers had to configure databases, build interfaces, connect systems, layer on APIs and security protocols, and reengineer the entire arrangement around a specific application. It was slow and expensive because it was the equivalent of building a car by hand.

Open-source software, reusable frameworks, cloud infrastructure, and APIs are becoming the standardized parts in this analogy. Developers no longer need to fabricate every component from raw material.

AI adds a flexible production layer. It can help identify components, generate the code connecting them, test possible solutions, document the system, inspect failures, and rapidly revise the design.

This does not eliminate the need for technical knowledge. It changes where that knowledge is most valuable. Just as the automobile assembly line did not eliminate automotive engineering; it concentrated advanced expertise in design, production systems, safety, and quality control. AI may do something similar to software. Producing lines of code becomes less scarce, while architecture, security, integration, validation, and maintenance remain critical.

Business analysts, consultants, and operations professionals do not become simplified assembly workers. Their opportunity is to become a translator between the people experiencing a problem and the technical systems capable of solving it.

That requires understanding the desired outcome, recognizing the available components, identifying missing requirements, bringing in technical specialists when the risk or complexity demands it, and testing whether the solution actually improves the way people work.

This brings us to the more interesting comparison with the automobile industry.

Cheaper production methods did not just make existing cars less expensive. They expanded the market to include millions of people who had always needed transportation but could not previously afford an automobile.

Software contains a similar pool of unmet demand. Almost everyone I know has thought, “There should be an app for that,” or “I wish this software worked the way I want it to.” While there are often legitimate reasons why established software works the way it does, and lowering the barrier to development will certainly produce more bad and useless applications, the underlying point is not lost.

People and businesses have a real need for more personalized software. Its price and complexity have kept much of that demand untapped.

I saw this while consulting with a catering operation. The company could have benefited from connecting seasonal menu planning and inventory management with ingredient availability from local farms. The need was real, but it was probably too specific to justify a conventional custom software project.

While working at Whole Foods Market, in their data department, I watched the company invest heavily in connecting independent local apiaries with their global honey supply chain. The business value existed, but so did the cost and complexity of connecting small, irregular suppliers to systems designed for consistent global operations.

I see the same constraint in my own life. I juggle multiple fitness applications to track my diet, workouts, heart rate, history, and progress because no single system gives me the synchronized, holistic view I want.

These examples operate at very different scales, but they share the same problem. The desired system is possible. It has simply not been economical to build around the specific user.

AI and reusable software components are beginning to change that calculation. Businesses may no longer have to force every process into the constraints of a few common platforms. Individuals may eventually have software organized around how they actually live and work.

The new constraint may not be whether we can build something. It may be whether we can correctly identify what deserves to be built, assemble it responsibly, and carry it through adoption.

For business leaders, this means the opportunity is larger than reducing development costs or replacing technical labor. Lower costs can expose operational improvements and entirely new markets that were previously too small to pursue.

It also creates a professional role for the business-technology translator: someone who can recognize problems people have learned to tolerate, understand the operational context, translate needs into requirements, apply the right technology, involve specialists where necessary, and make sure the resulting system produces a useful outcome.

That role sits across operations, technology, and adoption. It depends on technical fluency, but its defining skill is judgment.

It is also the role that best describes the work I have been moving toward throughout my career: finding friction, connecting ideas across domains, and turning unclear business problems into practical systems.

When production becomes affordable enough, potential demand becomes kinetic. The problem once dismissed as too small to solve becomes a viable project, a new capability, or even a new market.

That is where I think the next big opportunity lives.