I am building an iOS app for my family. I am also building a content-delivery platform and automating many of my day-to-day activities.
These are different kinds of work, but together they illustrate a change I find significant. I can now build entire applications that, in my earlier experience, would have required contributions from a team of developers, product managers, and people responsible for deployment and operations.
The responsibilities still exist. Someone has to decide what the application should do, how its parts fit together, whether it works, and how it will be maintained. What has changed is how much of the work I can undertake with AI assistance.
For me, the implication goes beyond being more productive. It changes which ideas I am willing to pursue.
A product does not need to serve a vast market to be useful. Sometimes it needs to solve a recurring problem for a family, a small business, or one team inside a larger organization. The effort required to create and maintain it has traditionally determined whether that was sensible.
As that effort changes, the range of problems worth solving with software changes too.
More ideas can cross the threshold from useful to feasible
Business leaders are familiar with ideas that are valuable but too small to justify a development project.
An internal tool could eliminate a frustrating handoff. A specialized application could fit a small customer segment better than a general-purpose product. A repetitive activity could be handled automatically. Each idea competes for a budget, people, and time.
AI-assisted development changes part of that calculation. A smaller initial commitment may be enough to build a narrow version and learn whether people actually use it.
My family app is an example of the scale of opportunity I mean. I am not claiming it proves a commercial business model. It illustrates that building for a small, specific audience can become a reasonable undertaking for an individual with relevant experience.
The content-delivery platform and everyday automations extend the same question into other areas of my work: what becomes worth attempting when implementation no longer requires the same team commitment?
This does not mean everyone can build every application. Experience still affects how well a person can define the problem, identify a weak design, and assess the result. But access to execution is changing, and business planning should take that seriously.
Examples from my current work. These illustrate the range of projects I am undertaking, rather than measured business results or completed launches.
There are two different economic changes
It helps to separate the cost of building a product from the cost of running intelligence inside it.
The first is the work of creating and changing software. Agents can assist with implementation, testing, documentation, and other development activities. The benefit depends on the work, the tools, and the person's ability to direct and verify the result.
The second is the cost of asking an AI model to perform a task while the product is being used. This is often called inference. A product might use it to interpret a message, extract information, summarize a document, or propose a next action.
These changes are related, but they are not interchangeable. An application built with AI does not necessarily use AI when it runs. My current projects illustrate the building side; I am not claiming they all depend on models performing tasks for users.
There is historical evidence for substantial reductions in the price of useful model capability. Stanford's 2025 AI Index reports that the cost of querying a model at a specified GPT-3.5-level benchmark performance fell from $20 to $0.07 per million tokens between November 2022 and October 2024. That comparison concerns a particular performance threshold, rather than every model or business task. See Stanford's research and development findings.
The strategic implication is that product teams should revisit assumptions about which features are too expensive to operate. A historical price decline does not establish the economics of a particular product today; those still need measuring.
AI can affect development effort and operating costs differently. The business case needs to include both.
Intelligence can become part of the workflow
When an intelligent operation is expensive, a product team has a reason to reserve it for a few important moments. If an operation becomes inexpensive enough, the design possibilities expand.
Consider a hypothetical service that receives business documents. It could identify the document type, extract required fields, flag missing information, and route an exception for review. These are several small tasks contributing to one useful outcome.
A customer might experience this as a service that understands what they submitted and helps them complete the process. They do not necessarily need a chatbot or a new interface to benefit.
The product designer's question becomes: where could interpretation, comparison, or a well-timed suggestion remove friction?
That might mean checking whether a request includes enough information before it enters a queue, or adapting an explanation to the context of a task. These are possibilities to evaluate, rather than features every product should acquire.
Cheap model access does not justify using a model for work a simple rule can handle reliably. Each additional step has to earn its place through a better customer outcome.
A low price per call does not guarantee a low-cost product
The economics can become misleading if we focus only on the quoted model price.
A feature may require several attempts, retrieve large amounts of context, invoke other services, and ask a person to correct the result. Individually inexpensive operations can accumulate. Usage can also grow when a feature becomes popular.
I would evaluate the cost of completing the customer's task successfully. That includes model usage, supporting infrastructure, review, correction, and support. It also includes the cases where the system fails and the work has to be repeated.
This changes the design conversation. A more capable model may cost more for a single call but require fewer retries. A narrowly defined feature may deliver more value than a general assistant that creates unpredictable work. A clear exception path may be more economical than repeatedly asking the system to resolve a case it cannot handle.
The same discipline applies to development. Generating code quickly does not establish how much effort was saved across design, integration, review, and maintenance.
METR's February 2026 update on developer-productivity research describes how selection effects and concurrent agent use complicate measurement. The researchers considered their newer results an unreliable estimate of the current effect. That is a useful reason to measure our own work carefully rather than borrow a universal productivity multiplier. Read METR's methodological update.
Smaller products deserve a fresh look
Lower development effort can change the minimum scale at which an idea makes sense.
A tool for a small professional niche may be worthwhile if it solves an expensive, recurring problem. An internal application may justify itself through better service or fewer errors even if nobody sells it externally. A personal application may be valuable simply because it fits the way its owner wants to work.
I find this exciting because so many software products must generalize to serve a large enough market. A smaller product can sometimes fit a particular need more closely.
However, building something custom also creates an obligation to look after it. For a business, the comparison should include existing products, configuration, integration, and the option to change the process without building software at all.
AI-assisted development makes building more plausible. It does not automatically make building the best decision.
Established companies should also consider this opportunity. A small team close to a customer problem may be able to test a solution without waiting for a large program. The company can provide common infrastructure and appropriate controls while keeping the experiment focused.
The scarce resource shifts toward choosing and learning
When more ideas become possible, choosing among them becomes more important.
A founder could use the new capacity to create a larger collection of unfinished features. A business could accumulate tools that nobody owns. The ability to produce more software does not resolve uncertainty about demand.
I would use cheaper experimentation to shorten the distance between an idea and useful evidence.
Start with a specific person and a recurring problem. Build the smallest version that can meaningfully address it. Watch what happens when that person uses it. Measure whether the result is better, what it costs to deliver, and what support it requires.
Then decide whether to expand, change direction, or stop. Keeping an experiment small makes that decision easier.
The people building the product need to stay close to the user throughout this process. Otherwise, rapid implementation can simply allow an untested assumption to become a much larger application.
A decision process for exploring opportunities. Customer value, reliability and ongoing ownership determine whether an experiment deserves further investment.
The opportunity is a wider range of useful products
My own work has changed how I think about the resources needed to pursue an idea. Building an app for my family, a content-delivery platform, and everyday automations is giving me direct experience of that broader reach.
The business lesson I take from it is to reconsider the opportunities we previously dismissed because the initial effort seemed too large. Some will still fail the test. Others may now be practical.
As intelligence becomes more accessible, leaders have an opportunity to build around smaller needs, learn earlier, and apply software where it previously felt uneconomical.
The standard for a good product remains demanding. It has to solve a problem, work reliably enough for its purpose, and justify the effort of keeping it useful. What is changing is how many people and organizations can attempt that work.