Software Before the Decision

About fifteen years ago, I took part in developing a project called Meetrical.

The idea was ambitious: use relationships, availability and context to bring possible encounters between people to the surface. The project belonged more to the world of social networks as they existed at the time, but some of its intuitions can now be found in Flechis, a project I am working on today.

To develop Meetrical, we had a team of five developers in India, a project manager and several months ahead of us. We had to produce specifications, answer questions, arbitrate choices, test successive versions and manage everything that normally accompanies software development.

This was not unusual. It was simply how a serious software product was built.

Above all, many decisions had to be made before we could see the product actually working. We had to decide what we wanted to build before we could try it.

That logic, I believe, is beginning to shift.

For some time now, I have been working on Flechis. Its central idea is simple: allow people who know one another, directly or indirectly, to signal openings—a place, a period, an intention—and automatically detect when an opportunity to meet exists.

But Flechis itself is not what interests me here. What interests me is how it has become possible to build it.

In a matter of days, through discussions, specifications and iterations with artificial intelligence systems, I went from a relatively abstract idea to a functional prototype, deployed and accessible in a browser, with user accounts, availability windows and an initial matching engine.

The software is still far from finished. Some ideas will probably be abandoned and others reformulated. The architecture will evolve. Problems I cannot yet see will emerge.

But that is precisely where the change lies.

I did not have to decide at the outset whether Flechis justified six months of development. I could begin building it in order to discover whether it deserved to be developed.

Building to understand

In traditional software development, especially when a project requires a team, a substantial budget or a contract with an outside supplier, there is strong pressure to decide early.

Features must be defined, a budget established, an architecture chosen, stages planned and resources assigned. The higher the cost of development, the more naturally we try to reduce uncertainty before beginning.

The problem is that a significant part of this uncertainty can only be eliminated by building something.

A prototype reveals questions that specifications do not. An interface can make an inconsistency obvious even though it seemed entirely acceptable in a document. A feature considered central can feel secondary after a few minutes of use.

I have already seen this with Flechis.

The possibility of creating recurring openings—being generally available whenever one is at home, for example—was not central to the original concept. It emerged while working on the system.

Another question then arose: are all openings equally important? Should an exceptional opportunity carry more weight than routine availability?

A potential user also asked whether Flechis could offer general messaging.

Technically, it would probably be fairly easy. But would it be desirable? Would the feature enrich Flechis, or would it begin turning the project into a messaging application or a social network like so many others?

In the past, each of these questions might have become a change request, an estimate and another decision to negotiate with a team. Today, some of them can simply become experiments.

The prototype no longer serves only to demonstrate what we have decided to do. It can help us discover what we should decide.

The invisible work around the code

When we talk about AI and programming, we instinctively think about code generation.

But anyone who has taken part in software projects knows that much of the work happens elsewhere. Environments must be configured, dependencies managed, data initialized, tests made to run and the application deployed. Someone has to understand why something works locally but not after deployment, read the errors, correct them, redeploy and begin again.

These are not necessarily the project’s hardest problems. They can nevertheless determine its pace and viability.

What impressed me about Flechis was therefore not simply watching AI quickly write a function I had described. It was seeing how far it could participate in the entire loop:

specify → build → test → deploy → observe → correct → repeat.

A 2026 NBER working paper based on data from more than 100,000 GitHub developers shows why this distinction matters. For the generation of autonomous agents studied, the authors measure a cumulative increase of 180% in commits. But the gain falls to 50% when they count projects and to 30% when they look at releases that were actually published.¹

Producing code is therefore not the same as producing a system that works, much less one that can be trusted.

A functional prototype does not resolve security, privacy, accessibility, maintenance or accountability on its own. AI can compress some of the work needed to learn without eliminating the obligations that come with durable software. This distinction is essential: the cost of the first experiment may fall much faster than the cost of long-term operation.

With Flechis, I can create two accounts, define openings that should normally produce a match and find that nothing happens.

From there, we can examine the real system. Is trust between the two people reciprocal? Do the periods actually overlap? Is the place the same? Are the intentions compatible? Is a rule preventing the encounter?

We correct the system, redeploy it and try again.

At that point, the software stops being merely the result of my thinking. It becomes a tool for thought.

The cost of trying

This is where I think we may be describing the effect of AI on software development incorrectly.

Yes, it can increase productivity. But what is falling is not only the cost of producing software. It is the cost of trying.

When that cost is high, many ideas are never tested. They remain in notebooks, presentations, conversations or simply in their authors’ minds because it is not reasonable to commit months of work to testing an intuition.

When the cost falls sharply, a hypothesis can become a prototype, and a poor direction can be abandoned without the experiment consuming weeks of work.

It becomes rational to build in order to learn rather than trying to decide everything before beginning.

This also changes the nature of the important questions. As more and more things become technically accessible, “is it possible?” loses some of its importance. “Is it a good idea?” gains more.

General messaging in Flechis is an example. The fact that it would be easy to add says nothing about whether it should be added.

The easier construction becomes, the more visible judgement becomes.

Late optionality

I call this late optionality: not postponing a decision through indecision, but avoiding making it before it becomes necessary when better information can be obtained in the meantime.

It does not mean refusing to choose. It means making a sequence of decisions small and reversible enough to preserve several possible paths until a larger commitment becomes justified.

AI-assisted development seems to me a particularly interesting instance of this logic.

I do not need to decide today whether Flechis should first become an iPhone application, an Android application or remain a web application. I can wait until I better understand how it will be used.

I do not need to decide immediately to add messaging because one person suggested it.

For the time being, I do not even need to decide whether Flechis should become a company. I can continue learning.

What strikes me, then, is not only the speed of development. It is the shift in the moment at which commitment becomes necessary.

The possible return of small software

This evolution could have an economic consequence that remains widely underestimated.

For several decades, producing serious software has required a minimum amount of capital, specialized expertise and coordination. This naturally favours certain kinds of projects.

Software capable of serving millions of people can justify considerable investment. Software intended for a few hundred or a few thousand people is much less likely to do so.

There is therefore an economic threshold below which many useful software products are simply never made: a specialized system for a small profession, a tool for a handful of municipalities or an application precisely adapted to one organization’s particular processes.

The market is not necessarily nonexistent. It is simply too small relative to the cost of making the software.

If that cost falls sharply, the threshold falls with it. This could make more specialized software viable, along with more companies that have no reason to become enormous.

A company with two or three people and a few thousand customers can be an excellent business if its operating costs are low enough. It does not have to become a global platform. It may not even need venture capital.

This possibility should not be idealized. Development is only part of a product’s cost: finding users, supporting them, protecting their data, complying with rules and maintaining the service remain real tasks. But by lowering the cost of the first usable system, AI can make markets explorable that were not before.

This is where my experience with Flechis begins to make me think about something much broader.

What if Silicon Valley is also a consequence of the price of software?

Silicon Valley is often described through its culture: appetite for risk, ambition, speed, venture capital and a desire to change the world.

But the model that developed there also corresponds to a particular cost structure.

Historically, turning an idea into a technology company required committing substantial resources before knowing whether it would work. A team had to be assembled, the product developed, the infrastructure put in place and then users found.

Someone had to finance that period. Venture capital provided an extraordinarily effective answer to this problem.

But its economic model imposes constraints of its own. Because many investments fail, the few companies that succeed must be capable of producing very large returns. A company with a good chance of becoming small, stable and profitable may therefore be an excellent business without being a particularly attractive investment for a venture capital fund. Josh Lerner and Ramana Nanda point out that only a relatively narrow band of innovations fits the requirements of institutional venture capital particularly well.²

There is also an interesting precedent.

The arrival of cloud computing in the 2000s considerably reduced the initial cost of many young Internet companies. It was no longer necessary to buy infrastructure in advance for growth that remained hypothetical.

A study of the arrival of AWS found that young companies in the sectors most affected raised about 20% less funding in their first round, while investors financed more initial experiments. For companies that survived at least three years, total capital raised did not decline: the large investments came later, after some of the uncertainty had been resolved.³

Cloud computing had reduced the cost of the infrastructure needed to try.

I wonder whether AI is beginning to do something similar to the cost of the work required to build the software itself.

When capital arrives later

If one person or a very small team can now build a functional product, deploy it, put it in users’ hands, discover what does not work and perhaps even find its first customers before seeking financing, the relationship with capital changes.

An entrepreneur does not necessarily have to ask for money in order to discover whether an idea works. Much more of that discovery can take place before financing is sought.

Instead of approaching an investor and saying, in essence:

Here is my idea. Give me the means to find out whether it works.

the entrepreneur can arrive with:

Here is the product. Here is what we have learned. Here are the users. Now, do we want to scale?

Capital is not eliminated. It arrives later.

And this, too, is a form of late optionality.

The founder preserves for longer the option to continue alone, remain small, seek capital or stop—and makes those decisions with more information.

Some projects will, of course, always require enormous sums. Foundation models, semiconductors, physical infrastructure and companies aiming to serve hundreds of millions of users do not fit this logic.

But much of software does.

If the teams required become much smaller and the cost of experimentation continues to fall, part of the software economy could gradually detach itself from the model that has dominated Silicon Valley.

Not because venture capital has stopped working, but because a growing number of projects may no longer need it as early.

Software before the decision

I do not yet know what Flechis will become.

The concept may work very well, evolve into something quite different or prove not worth pursuing.

Fifteen years ago, I would probably have needed a fairly firm opinion on that question before I could justify the resources required to go much further.

Today, I do not have to answer immediately. I can build before deciding.

That may be the most important change.

The prototype is no longer only a step toward the product. It can become a way of obtaining the information needed to decide whether the product deserves to exist.

When the cost of trying collapses, the best strategy may no longer be to make the right decision as early as possible. It may be to preserve enough options to make that decision later, when more is known.

References