I was listening to an interesting conversation on Linus Tech Tips' WAN Show where Luke was talking about how some YouTubers were effectively building their own versions of video editing software.
Not competitors to Premiere Pro. Not products meant for a market. Just software built specifically around the way they work.
And I think there is something much bigger hiding inside that idea.
Software for one is not new
People have always built software for themselves. Excel monstrosities. Macros. Shell scripts. AutoHotkey setups. Custom Photoshop actions. Blender scripts. Internal tools nobody outside a company will ever see.
Developers have been doing this forever.
So the interesting part isn't that software can be built for one person. The interesting part is that the economics of doing it are changing.
Historically, building custom software for one person was expensive enough that it usually made no sense. Imagine spending six months building a video editor that only works for you. You'd need developers, designers, QA, infrastructure, and maintenance. By the time you were done, you might as well have learned Premiere properly.
So software naturally became generalized.
Premiere has to work for YouTubers, filmmakers, agencies, wedding editors, television studios, and probably fifty other categories of users. Which means it contains enormous amounts of functionality that any one user may never touch.
And then something slightly strange happens.
The user adapts to the software.
You learn how Premiere wants editing to happen. You learn where its buttons are. You learn its terminology. You structure your workflow around the assumptions baked into the product.
That made complete economic sense when software was expensive to create. I'm not sure it always will.
What if I only need 8% of Premiere?
This is where I think the argument gets more interesting.
It would be silly to claim that an AI agent wrapped around FFmpeg suddenly replaces Premiere. Professional video editing software contains decades of solved problems around codecs, timelines, GPU acceleration, color management, media pipelines, undo systems, asset management, and reliability.
But I may not need all of that. Maybe my workflow uses 8% of it.
Import these files. Sync these tracks. Cut silence this way. Normalize the audio like this. Use these transitions. Generate these captions. Place this intro. Export using these settings.
That is a much smaller problem. And AI changes the economics of solving small problems.
Instead of building a general video editor, I could build a thin editing harness around existing components. Maybe FFmpeg underneath. Maybe an existing timeline library. Maybe a few APIs. Maybe an LLM handling the messy parts.
At first I still perform most of the workflow myself. Over time I automate the repetitive pieces.
At some point what I have is no longer really "a video editor."
It is my video editor.
That distinction matters.
The minimum viable audience may be collapsing
Most software economics have historically revolved around scale.
If something costs ₹50 lakh to build, you need enough users to justify ₹50 lakh. If something costs ₹5 lakh, the market can be smaller. If something costs ₹50,000, smaller still.
AI pushes that curve down dramatically. Not to zero.
This is where I think we need to be careful with the phrase "coding is becoming free."
Code generation is becoming extremely cheap. Software ownership isn't.
Someone still has to deal with bugs, edge cases, broken APIs, security, authentication, dependencies, deployment, data migrations, and maintenance. And the wonderful moment six months later when something mysteriously stops working.
So software isn't becoming free. But the cost of getting to the first useful version has collapsed.
And that alone can completely change what is economically worth building.
Maybe the number of people required to justify a piece of software goes from 100,000 users, to 10,000, to 1,000, to 100, to 10.
And eventually, sometimes, to one.
That is what I mean by software for one.
Vibe coding is already happening. But what are people building?
There is a lot of discussion around vibe coding right now. People are building things in a weekend that might have taken weeks or months a few years ago.
But most of the conversation still assumes the old software lifecycle. You have an idea. You build an app. You launch it. You acquire users. You monetize it.
AI simply makes "build the app" cheaper.
I'm increasingly interested in the software that never needs to reach step two.
Someone builds a tiny CRM that makes absolutely no sense outside their own company.
A construction contractor builds a quoting tool containing the strange heuristics they've accumulated over twenty years.
A recruiter builds a system that cleans timesheets coming from five different VMS platforms.
A photographer builds something that imports photographs, sorts them, identifies the likely keepers, applies a specific preset, and prepares client albums.
A researcher builds a system around exactly how they collect sources, annotate them, challenge their own assumptions, and write.
None of these need product-market fit. None of them need a landing page. None of them need venture capital.
They just need to save enough time for the person who built them.
And there is a third category that I think becomes very important.
Build it for yourself first. Discover the market later.
That is almost the reverse of how we normally think about startups. Instead of identifying a theoretical customer, writing requirements, and searching for product-market fit, someone fixes an irritation in their own workflow. Then they discover that 50,000 other people have the same irritation.
This obviously isn't new either. A lot of great software has historically started as internal tooling.
What changes is the number of experiments we can now run.
If thousands or millions of people can cheaply encode tiny pieces of their workflows into software, the number of weird niche products being tested in the real world explodes.
Some stay software for one. Some become software for ten. And occasionally one becomes a company.
Tacit knowledge starts becoming extremely valuable
If implementation becomes easier, where does the advantage move?
I don't think the answer is simply "ideas." Ideas are cheap too.
I think one answer is tacit knowledge: the strange operational knowledge people accumulate by doing a job.
The construction estimator who looks at a drawing and immediately knows which number is probably wrong.
The recruiter who knows exactly which client's VMS export is going to break payroll.
The editor who knows that a particular kind of pause should never be cut, even though an automatic silence detector would remove it.
The founder who knows which metric in a dashboard is technically correct but practically meaningless.
A lot of this knowledge never becomes software because translating it into software has historically required another person.
You explain it to a product manager. They translate it into requirements. Someone turns those requirements into tickets. Developers implement the tickets. QA tests them.
Then six weeks later you discover that the subtle thing you cared about disappeared somewhere between the second and third translation.
AI shortens that distance. The person with the knowledge can increasingly encode it directly.
That might be one of the biggest changes here.
When implementation gets cheaper, knowing what should happen becomes more valuable than knowing the syntax required to make it happen.
And I don't mean that everyone magically becomes a software engineer. Generating code and judging whether that code is correct are very different things.
The advantage moves toward:
- domain understanding
- judgment
- decomposition
- verification
- knowing what not to automate
Personal automation, personalized software and adaptive software are different things
I also think we need to avoid lumping everything into one magical AI bucket. There are at least three layers here.
The first is personal automation. I perform a repetitive task and write something that performs it for me. This is old and well understood.
The second is personalized software. Instead of using a generic product with hundreds of configuration options, I construct a small application around my own workflow. AI makes this dramatically easier.
The third is adaptive software. The software observes how I work, understands my preferences, and changes its behavior over time.
This is the most exciting idea. It is also by far the hardest.
"AI watches what you do and automatically learns your workflow" sounds fantastic until the system learns the wrong lesson and silently changes something important. There are problems around observability, reversibility, permissions, trust, and intent.
So I don't think we're instantly jumping to completely self-evolving applications.
The nearer-term opportunity is probably much more boring and much more useful:
software that is cheap enough to reshape manually around a single workflow whenever that workflow changes.
That by itself is a massive shift.
The AI agent part is surprisingly ordinary
I've also been spending time looking through the code and documentation of tools like Pi, OpenCode, and other coding-agent harnesses.
Once you strip away some of the magic, the core architecture is surprisingly understandable.
You have a model, context, and an agent loop. The model decides whether to answer or call a tool. You execute the tool, return the result, and the loop continues.
Then you progressively add the things required to make the system useful: session management, permissions, context compression, planning, subagents, tool registries, sandboxing, caching, memory, observability, and different interfaces.
There is a huge amount of engineering involved in making all of this reliable. But the basic agent loop is increasingly becoming commodity infrastructure.
Which creates another interesting shift.
The question stops being: "How do I build another OpenCode?"
And starts becoming: "What environment do I build around the loop?"
A construction estimation agent and a coding agent might share a surprisingly large amount of underlying architecture. What makes them different is everything surrounding the model: the tools they can use, the data they can access, the constraints they operate under, the workflow they understand, the domain rules they carry, the approvals they require, and the context they receive.
Once the generic agent loop becomes commodity infrastructure, the environment around the loop becomes the product.
That feels much more interesting to me than endlessly rebuilding general-purpose agents.
General software isn't going away
There is an obvious counterargument to all of this.
General-purpose software has enormous advantages: reliability, interoperability, collaboration, regulatory compliance, network effects, support, deep user interfaces, and years of accumulated edge cases.
I am probably not going to vibe-code my own CAD kernel. I'm not building my own browser engine because Chrome has too many buttons. I'm probably not building a banking ledger from scratch because I don't like the interface of an accounting package.
There is still going to be a huge amount of generalized infrastructure underneath everything.
In fact, software for one probably makes that infrastructure more important.
The personalized layer doesn't need to reinvent everything. It can sit on top of Postgres, Stripe, FFmpeg, Chromium, OpenStreetMap, cloud storage, foundation models, existing APIs, and open-source libraries.
You could end up with a relatively small amount of extremely robust, generalized infrastructure underneath and an enormous amount of personalized, disposable software above it.
That feels like a very plausible architecture for the next generation of software.
Configuration versus generation
For decades, the software industry has solved customization through configuration.
We build one product. Then we give users settings, preferences, plugins, extensions, custom fields, rules, templates, dashboards, and no-code builders.
Eventually some enterprise SaaS products become absurd configuration engines, because they are attempting to represent every possible workflow inside one generalized product.
There may be another model.
Instead of: Build one product and expose ten thousand configuration options.
We might increasingly say: Generate a smaller product for this workflow.
The underlying components remain standardized. The interface and orchestration become specific.
Which leads to the question I keep coming back to.
How cheap does software creation have to become before customization becomes cheaper than configuration?
Because once you cross that line, some very old assumptions about software start breaking.
Maybe the future is software built around workflows
Today we buy applications and adapt ourselves to them. Tomorrow we might increasingly assemble capabilities and let software form around the way we work.
The underlying pieces may be surprisingly boring. A database. A browser. A few APIs. An LLM. Some open-source libraries. A small agent loop. A bunch of scripts.
But the combination becomes highly specific.
When I say "prepare this video," my system may know that means eleven operations. When someone else says exactly the same sentence, their system may perform eleven completely different operations.
At that point software starts looking less like a collection of fixed applications and more like a personalized execution layer sitting between humans and computers.
And perhaps the most important change is economic rather than technical.
For the last forty years, one of the fundamental questions of software has been:
How many customers can use the same software?
The next question might be:
How few customers does software need before it is still worth building?
Increasingly, the answer may be:
one.
When software for one becomes software for many
Sometimes the tool you built for yourself turns out to solve a problem thousands of other people have. That's the moment the questions change. Who else needs this? Will they pay for it? What does it take to turn something you trust for your own workflow into something other people can rely on?
That's the work we do at Ellenox. We partner with founders who understand a problem deeply, help validate whether it's bigger than one person, and build the product that turns tacit knowledge into a company. If your software for one might be software for many, let's talk.