When Did Building Software Become the Same as Building a Business?

It's becoming increasingly easy to build software.

An idea that once required a development team, considerable funding and months of work can now be turned into a functioning prototype much faster.

I find that exciting.

The ability to experiment without committing enormous resources opens opportunities that might previously have been out of reach.

But I think there's a danger in confusing the ability to build something with the ability to make it succeed.

A website can look beautiful. An application can work exactly as intended. Every feature on the development checklist can be marked complete.

And yet none of those things automatically makes it a business.

Who needs the product?

What problem does it solve?

Will anyone actually pay for it?

What happens when a payment fails, a customer needs assistance, or something goes wrong after launch?

These are not questions that can be answered by producing more code.

I've been exploring several software projects, often using AI to accelerate development. One thing I've tried to maintain is the distinction between technical progress and commercial progress.

They aren't the same.

A project can be moving quickly from an engineering perspective while remaining far from commercial readiness.

Equally, a relatively simple product may have more commercial potential than something technically impressive if it solves a genuine problem for a specific group of people.

This is why I keep returning to the purpose of a project.

Before adding another feature, I want to understand whether it contributes to the outcome we're trying to achieve.

Before expanding into another market, I want to know whether the payment arrangements, operating requirements and customer experience have been considered.

Before declaring something ready, I want evidence that the important parts work under realistic conditions.

None of this means I believe every uncertainty must disappear before launching.

That would make experimentation almost impossible.

But I think there's a difference between taking a calculated risk and proceeding without understanding the risk at all.

I'm also increasingly sceptical of development schedules that are based entirely on conventional expectations.

If AI changes how quickly work can be completed, then our planning assumptions should change too.

I'd rather assess actual progress, unresolved tasks and demonstrated delivery speed than defend a timeline simply because it looks familiar.

At the same time, faster development doesn't eliminate the need for payment verification, security, customer support, legal obligations or trust.

Those responsibilities remain.

Perhaps the most interesting consequence of AI-assisted development is that writing the software may become one of the easier parts of starting a technology business.

Understanding customers, making sound decisions, managing risk and finding a sustainable way to create value may become even more important.

That's where I want to direct more of my attention.

Not simply towards building more applications.

But towards understanding which ones deserve to exist, whether they can genuinely serve people, and what it takes to turn an interesting idea into something commercially meaningful.