Software is becoming summonable

Software is becoming summonable, which means the question is shifting from “can this be built?” to “was this small problem ever worth turning into a product at all?”

I call this the Ocarina thesis.

For most of software history, a useful idea had to pass a fairly demanding test before it could exist. Someone had to recognise the need, write a brief, fund the work, build the thing, distribute it, support it, and find enough people with the same problem to justify keeping it alive. A tool could be obviously useful to a few people and still never exist because the path from need to product was too expensive.

That path is getting shorter.

The interesting consequence is not that everyone will be able to describe a large application and receive a polished replacement for Salesforce by lunch. It makes a good flagship demo because it is easy to understand. The more consequential change is lower down the stack: the small, specific tools that were never serious businesses, never justified a backlog, and never survived the question of whether anyone should spend a week building them.

I ran into that distinction last week.

The notepad I did not build

I wanted a notepad that also handled dictation. One window, one place to type or talk, no separate transcription workflow to manage.

It felt like an idea. My old instinct would have been to sketch it, decide whether the transcription should run locally, choose a desktop shell, and spend a weekend making a small version of it.

Instead, I searched first.

OpenWhispr already provides local and cloud dictation, notes, and desktop transcription. open-wispr is a separate local-first project that transcribes speech and types it at the cursor. Handy is another open-source, offline speech-to-text tool that uses Whisper models and works across Windows, macOS, and Linux.

The names nearly collide because the need does too.

Three different people or teams arrived at a similar answer: speech should become usable text without forcing the person to move through a separate recording and transcription ritual. The details differ, but the underlying request is recognisable in one sentence.

The convergence was more useful than any individual feature list. It told me the idea was not rare, technically mysterious, or waiting for a new category to be invented. The components were already known: a speech model, a lightweight desktop shell, a place for the text to live, and a reliable route from voice to cursor or note.

The project stopped being a research problem. It became a known-quantity build that I no longer needed to do.

For me, that outcome is useful. The point is not to build every tool you can describe, but to know whether a need calls for a new product, an existing tool, a small adaptation, or nothing more than a prompt and a few minutes of setup.

Convergence is a market signal

When several unconnected people build versions of the same modest tool, it usually means the problem had enough shape to be recognised before anyone coordinated around it.

Convergence does not prove there is a large business behind the category. In this case, it may prove the opposite. The need may be too small, too personal, or too intermittent to deserve another subscription, another company, another onboarding flow, and another product roadmap.

It still deserves an answer.

This is where product thinking has to become more discriminating. A founder or operator can now notice a recurring irritation and reach for a build much earlier. Early build access helps, but it creates a new failure mode: treating every solvable problem as a product opportunity.

The first question should be more demanding.

Does this need a product with a future, or does it need a tool that can appear when the problem appears?

Those are different things.

A product needs a user model, a reason to return, support expectations, a maintenance path, and usually some commercial logic. A summoned tool may only need to remove friction for one person, one team, or one short-lived situation. It can be generated, adjusted, used for as long as the need lasts, and retired without creating a graveyard of abandoned accounts and half-maintained SaaS subscriptions.

The old economics forced these categories together. If it was expensive to build, the tool had to become durable enough to justify the cost. As the cost of bringing software into existence falls, durability becomes a decision rather than a prerequisite.

The bottleneck is moving upstream

The technical ingredients for the dictation notepad were not the difficult part. They were already well documented. OpenAI’s Whisper is available under the MIT license, and projects such as OpenWhispr and Handy show that local transcription, desktop packaging, and text insertion are now established implementation paths.

The harder work is deciding whether the tool is worth summoning in the first place.

That decision involves questions code cannot answer by itself.

  • Is the irritation frequent enough to deserve a dedicated interface?
  • Is an existing tool close enough once it is configured properly?
  • Would a small script solve the real job without creating a second system to maintain?
  • Is the apparent need actually a workflow problem, a missing integration, or a habit that should change instead?
  • If the tool succeeds, who will own the exceptions it creates?

These are product decisions, even when the build itself is cheap.

For that reason, I do not think the next wave is mainly about replacing established software. Big products carry data, organisational memory, regulation, operating routines, and many people with conflicting needs. They do not disappear because a model can scaffold an interface.

The larger opportunity is the long tail underneath them: the one-off calculator a team needs for a project, the temporary tracker for a difficult handover, the small conversion tool that saves an operator ten minutes a day, the locally generated interface that makes a known process usable without asking a product team to adopt it as permanent work.

Some of that software should never be sold. It should be called into existence, used, and allowed to disappear.

Generated software is not exempt from judgement. A throwaway tool can still handle customer information, shape an approval, produce a number someone trusts, or become the unofficial answer to a recurring problem. The easier it is to summon, the easier it is to create something that looks harmless until other people start depending on it.

I am not arguing for a new pile of invisible utilities. I am arguing for a more honest choice about what deserves a product lifecycle and what should stay local, bounded, and easy to remove. The ability to make software cheaply does not remove the need for ownership; it makes the ownership decision arrive sooner.

What this changes for teams

For a small company, the temptation will be to celebrate every new capability as a reason to build faster. Speed alone is not enough.

The more software becomes accessible, the more valuable selection becomes. A team that can summon ten internal tools in a month also has ten things that can drift, duplicate work, expose information, confuse ownership, and become unofficial infrastructure before anyone has decided they are important.

This is familiar territory for workflow-heavy B2B teams. The hidden systems are rarely the headline platform. They are the temporary spreadsheet, the side channel, the workaround that one person made under pressure, and the small utility that became essential without a named owner.

Making those tools easier to create should not make teams casual about what they allow to persist.

The thesis also connects to software being temporary by default. The useful future is not endless software creation. It is a better boundary between tools that deserve a roadmap and tools that should remain lightweight, local, inspectable, and disposable.

For founders and operators, that shifts the value of outside product and AI work as well. The question is less often “can you build this?” and more often “should this become a product, an internal tool, an existing workflow, or nothing at all?”

The question gets harder because the answer may be to use what already exists, teach the team to run it, or stop before a new dependency is born. Judgement becomes more valuable than a convincing first draft at that point.

The work is not to make every thought into software. It is making the right software appear at the right time, then letting the rest disappear when its job is done.

Keep Reading

Related Posts