The Software Works. Now What?

A couple of weeks ago, a friend called me with a business idea.

He understood the problem he wanted to solve, had a clear idea of how the product should work, and had even prepared an RFP describing the application he wanted to build.

He asked if we could help him build it.

I've spent 25 years helping founders and companies create software, and after reviewing what he had prepared, my first concern wasn't whether we could build it. It was whether he should build all of it.

The RFP was comprehensive. Perhaps too comprehensive for where the business was.

There were many features that seemed reasonable individually, but the purpose of this first product wasn't to create the complete version of the company he imagined. It was to find out whether customers experienced the problem strongly enough and whether the proposed solution created enough value for them.

So my recommendation was to reduce the scope.

Identify what we actually needed to learn. Build enough to test those assumptions. Put it in front of real users. Then allow what we learned to determine what deserved to be built next.

That is essentially the discipline behind a good MVP strategy: the objective isn't to create a smaller version of everything you eventually want. It is to make the smallest responsible investment capable of reducing the uncertainty that matters most.

Then I didn't hear from him for about ten days.

When he called me again, I assumed we were going to continue discussing the proposal.

Instead, he showed me the application.

He had built it himself using Claude Code.

And it was surprisingly good.

The problem was no longer building it

My friend had originally approached me because he assumed he needed a software company to turn his idea into a working product. Ten days later, much of that problem had disappeared.

He had an application. The main workflows worked. The interface looked reasonably good. Many of the features described in the RFP were already there.

But he had a new set of questions.

Had he built too much for what he was trying to validate? Which features were actually necessary? Was the user experience good enough? How should payments be implemented? Was deploying the application to a server enough to consider it production-ready?

He had gone from an idea to working software remarkably quickly.

What he hadn't gained in those ten days was the experience to know how much responsibility that software was ready to assume.

The question was no longer whether the software worked.

It was whether we should trust it with real users.

Then it happened again

I might have considered this an isolated experience if almost the same thing hadn't happened with another founder.

We had previously helped him develop a functional prototype. The next objective was to turn it into an MVP he could put in front of an early adopter — in this case, a bank.

We worked through what needed to change and produced a roadmap. Then he went away and worked on it himself.

About two months later, he came back and showed us what he had built using AI-assisted development.

Once again, the product existed. And once again, the question had changed.

He wanted to know whether what he had built was ready to be used by a financial institution.

How would integrations behave when something went wrong? How were errors handled? What information was being logged? How was access controlled? What needed to be backed up? What happened to sensitive information as it moved between systems?

These weren't theoretical engineering questions anymore. A bank was going to depend on the answers.

Around the same time, a third situation emerged.

A friend who runs a minerals company had asked us to study the way his business managed deliveries of construction materials. We identified the friction and proposed a system that could improve the process.

Instead of asking us to build it, he took the proposal to a relatively junior developer, who used AI-assisted development to create the solution.

Then they came back to us with a familiar question.

Could they put it into production?

Three different situations had arrived at almost exactly the same place.

That was when it stopped looking like coincidence.

The bottleneck is moving

For most of my career, one of the largest barriers between understanding a problem and having software that could attempt to solve it was the ability to build.

A founder could understand a market extraordinarily well and still need engineers before the idea could become a product. An operations executive could understand a broken workflow better than anyone else and still depend on a development team to translate that understanding into software.

That barrier hasn't disappeared, but it has changed dramatically.

Today, people who are very close to a problem can use AI-assisted development to turn their understanding directly into functional software.

I think this is an extraordinarily positive development.

The people who understand a problem no longer have to wait as long for someone else to translate their thinking into software. Experiments that once required significant budgets and engineering capacity can sometimes be attempted in days.

But reducing one constraint exposes another.

The scarce capability increasingly isn't just turning requirements into code. It is knowing what deserves to be built, what needs to be validated, what could fail, what needs to be protected, and how much responsibility a system is ready to assume.

AI-assisted development hasn't eliminated engineering judgment.

It has made the absence of it easier to reach.

Working software and production software answer different questions

A functional application proves something important: an idea can be expressed as software.

You can click through the workflow. Information can be stored. An API can return the expected response. A payment might complete successfully. A demo can work from beginning to end.

But production asks different questions because the environment changes.

Real users enter unexpected information, abandon processes halfway through and attempt things nobody anticipated. External systems become unavailable. Transactions fail between steps. Data needs to be recovered. Permissions suddenly determine who can see information they shouldn't. A process that worked perfectly with ten records may behave differently with ten thousand.

None of this means software built with AI is inherently unreliable. Traditional development teams have been producing these problems for decades.

The important distinction isn't AI-built versus human-built software.

It is the difference between software that has demonstrated functionality and software that is ready to assume a particular level of operational responsibility.

As that responsibility increases, architecture, testing, security, observability, performance and maintainability become more consequential. That is why rapidly built software sometimes needs to be evolved before assuming greater operational responsibility, rather than discarded simply because of how it was originally created.

Ready for what?

This distinction becomes particularly visible in healthcare and financial services.

If an experimental application helps someone organize a personal workflow and occasionally fails, the consequences may be manageable. The equation changes when that application handles clinical information, financial information, payments or data exchanged with a bank.

The same happens when software moves from helping one employee to becoming part of how an organization operates.

The code hasn't necessarily become worse.

The responsibility around it has changed.

That is why I don't think production readiness is a universal state that software either has or doesn't have.

The better question is:

Ready for what?

A product being tested by twenty early adopters doesn't necessarily need the same controls, architecture and operational maturity as a system exchanging sensitive information with a financial institution.

The objective shouldn't be to engineer every experiment as though it were already a mission-critical platform. That would simply recreate the old problem: committing too much before learning enough.

When building becomes cheaper, deciding what not to build becomes more important

There was another lesson hidden in my first friend's application.

He had built too much.

Not because the software was poor. In fact, the opposite was part of the problem. Building had become so accessible that many of the things described in the original RFP could simply be implemented.

Historically, engineering cost created a natural constraint. If every additional feature required days or weeks of development, teams had to make choices.

AI-assisted development weakens that constraint.

A founder can describe another workflow, dashboard, role or feature and discover that implementing it isn't particularly difficult.

The temptation is obvious: why not add it?

But the fact that something has become inexpensive to build doesn't make it inexpensive to learn from.

Every additional feature introduces another variable into the experiment. If users adopt the product, you need to understand what created the value. If they don't, you need to understand what failed.

This is why testing the assumptions behind an initiative becomes more important, not less, as implementation gets easier. The purpose isn't to slow development down. It is to distinguish what we know from what merely became easy to turn into software.

The ability to build something is not evidence that it should be built.

The first version still needs to earn the second

This connects to something I wrote about recently in What Makes a Software Project Successful?.

A good software project doesn't begin by trying to predict everything the final system will eventually need. Each phase should create enough value or learning to justify the next one.

AI-assisted development doesn't invalidate that discipline. If anything, it makes it more important.

If the next step is testing whether ten customers care about the problem, build for that.

If the next step is accepting payments, the responsibility changes. If it is integrating with a bank, it changes again. And if the system eventually becomes critical to daily operations, it changes again.

Architecture, controls and engineering maturity should grow with justified responsibility rather than imagined future complexity.

That allows founders to preserve one of the greatest advantages these new tools provide: speed of learning.

The role of software expertise is changing

All of this forces those of us who build software professionally to confront a useful question.

If our clients can increasingly build significant parts of their own software, where do we create value?

I don't think the answer is to dismiss what they're building. And I certainly don't think anything produced through vibe coding automatically needs to be rebuilt by "real developers."

I've seen enough to know that would be wrong.

These tools can produce impressive software. In the hands of someone who understands the problem, they can dramatically shorten the distance between an idea and something useful.

That should change the role of a software partner.

Sometimes the client will still need us to build the system. Sometimes they will need engineering capacity alongside their team. Increasingly, however, they may arrive with a significant amount already built.

The conversation can then start somewhere more valuable.

What are you trying to learn? What responsibility does this system need to assume next? What have you validated? Which parts deserve to remain? Where could failure actually hurt the business or its users?

Only after answering those questions should we determine whether the appropriate intervention is architecture work, UX improvement, security hardening, testing, integration work, additional engineering — or perhaps removing things that never needed to be there.

That is a different relationship from receiving an RFP and returning an estimate.

It is also closer to how I believe software should have been approached all along.

Building was never the entire problem

Twenty-five years ago, much of the value I could provide a founder came from something relatively scarce: the ability to turn an idea into working software.

That capability still matters. But it is becoming much more accessible.

And I think that's good.

A founder shouldn't need a large engineering budget merely to discover whether an idea deserves to exist. An operations leader shouldn't necessarily have to wait months before experimenting with a better way of working.

AI-assisted development is making that possible at a scale we haven't seen before.

But software eventually crosses a boundary where proving that it works is no longer enough. Real people begin depending on it. Real data and money may move through it. Other systems begin relying on it. The business assumes consequences when something goes wrong.

At that point, the question changes from whether we can make the software work to whether we understand it well enough to trust it with the responsibility we're about to give it.

That may be where experienced software judgment becomes more valuable, not less.

Because as building becomes easier, we are going to produce far more working software.

The harder decisions will increasingly be what deserves to be built, what deserves to survive, and when what we've built has earned the right to matter.