The most disruptive software decision may soon be whether to buy an application at all. As AI coding agents become more capable, the economics of building small, purpose-built tools are changing. For Canadian tech leaders, that shift raises an immediate strategic question: which software subscriptions still justify their cost when a tailored alternative can be created with AI?
The opportunity goes beyond generating code faster. It points toward software that fits an organization’s actual needs, rather than forcing employees to navigate oversized applications, unwanted features, and recurring fees.
That does not mean enterprise software has become worthless or that AI-generated applications are automatically production-ready. It means the boundary between buying and building deserves another look. Across Canadian tech, the next advantage may come from knowing exactly where that boundary has moved.
A Simple PDF Reader Reveals a Bigger Business Problem
The starting point is familiar: a person needs to open a PDF and encounters a heavyweight application packed with features, promotional prompts, and account requirements. The task is simple, but the software experience is not.
That frustration led Matthew Berman to build a PDF reader and editor called Folio. Rather than accepting an existing product’s design decisions, he used AI-assisted development to create something closer to his own requirements.
The example captures a persistent tension in business technology. Commercial applications serve many customers, so they accumulate capabilities intended for different audiences. Individual users may need only a small portion of them.
For Canadian tech organizations, the important question is not whether feature-rich software is inherently bad. It is whether the value of a commercial package outweighs its complexity for a particular task. AI makes that question more practical because customization no longer necessarily requires a traditional development project.
Three Forces Are Changing Software Development Economics
The case for personalized software depends on three conditions coming together: stronger models, lower development costs, and simpler execution. Any one of these improvements would matter. Together, they challenge assumptions behind the software subscription model.
1. AI Models Must Be Capable Enough
Early coding demonstrations often involved small, contained projects such as a Snake game. As models improved, more demanding tests emerged, including interactive Rubik’s Cube simulations and attempts to reproduce familiar productivity applications.
Berman describes moving toward spreadsheet applications as a more substantial test. His reported results suggest a major improvement in how much working functionality agents can produce from a broad instruction.
For Canadian tech teams, the relevant change is the widening scope of feasible projects. A model that generates a useful function is helpful. An agent that coordinates an application’s interface, logic, and iterative fixes changes the planning conversation.
2. The Cost Must Make Sense
Technical capability alone does not justify building. If an agent consumes more money and staff time than a ready-made product costs, customization may be difficult to defend.
The central comparison is therefore the total cost of creating and maintaining a suitable tool versus the total cost of purchasing and operating an alternative.
Berman argues that falling token costs are moving that comparison toward building in some cases. His examples are personal experiences, not universal pricing benchmarks. Still, they highlight a meaningful possibility for Canadian tech buyers: development effort may be shrinking faster than existing procurement assumptions suggest.
3. The Process Must Be Easy Enough
A capable model remains limited if a person must supervise every technical decision. Agent-based systems matter because they can undertake sequences of work, respond to errors, and continue refining an application.
This reduces the coordination burden between an initial request and a usable result. It does not remove the need for judgment, but it can make experimentation accessible to people who would not otherwise commission software.
The combined effect is significant. Canadian tech businesses may be able to test whether a custom tool is useful before committing to a larger implementation.
The Spreadsheet Example: Impressive Claims, Important Boundaries
Berman reports creating a browser-based spreadsheet application in roughly 90 minutes to a few hours, with about $10 in token expenditure. He describes the result as matching Excel’s functionality.
That is a striking claim, but reported feature parity should not be confused with independently verified equivalence. A familiar interface and successful demonstrations do not establish that an application handles every formula, workbook, integration, or demanding workflow identically.
The software prices discussed alongside the example are also illustrative rather than Canadian procurement quotes. Currency, licensing terms, and organizational requirements matter when evaluating any comparison.
The stronger business lesson does not depend on proving that an agent has completely reproduced Excel. Many organizations do not need every capability of a major spreadsheet platform for every task. A smaller tool that reliably supports one recurring process could still be valuable.
Canadian tech leaders should separate two questions:
- Can AI reproduce a recognizable application? This tests development capability.
- Can the resulting software reliably support a defined business process? This determines operational value.
The second question deserves greater weight in purchasing and deployment decisions.
Purpose-Built Software Can Beat Feature Overload
The most persuasive examples are not necessarily the largest. They are applications with clear boundaries and an obvious reason to exist.
Folio: A Focused PDF Workflow
Folio brings together PDF reading, annotations, drawing, notes, electronic signing, and AI-based questions about document content. Berman presents it as lightweight, fast, free, and open source.
Its significance is the relationship between need and design. Features can be added because a particular user needs them, without requiring a broader commercial market for the same request.
For Canadian tech teams, that suggests a different starting point for internal tools. Instead of searching for the platform with the longest feature list, a team can define the smallest useful workflow and assess whether existing or generated software can support it.
Document-related functions still need appropriate evaluation. An electronic-signing capability, for example, should not automatically be assumed suitable for every business requirement merely because it exists in an application.
Outlier Tracker: Replacing Only the Needed Features
Berman also describes building Outlier Tracker after becoming dissatisfied with a video analytics product. His concerns included unwanted functionality, authentication requirements, and an interface that occupied too much screen space.
The replacement focused on video statistics, tracking, and channel analysis. He reports building it in around 30 minutes.
This illustrates a powerful principle for Canadian tech entrepreneurs: a replacement does not need to recreate an entire product to replace its value for one customer. It needs to perform the specific jobs that customer actually relies on.
That distinction makes smaller applications strategically important. The competitive threat to a large platform may begin with one narrowly defined workflow rather than a complete rival.
Open Source Could Multiply the Impact
Custom development becomes more consequential when its results are shared. An application created for one person can become a starting point for others, who then adapt it rather than beginning again.
Berman’s projects are available through the Forward Future GitHub organization. This distribution model connects AI-assisted development with a longstanding open-source principle: shared code can support many different needs.
For Canadian tech, the potential advantage is cumulative. If an existing project already covers most of a workflow, an organization may need only a targeted modification rather than a full implementation.
However, free access and open-source availability are not identical. Organizations should examine the actual licence, project health, and maintenance arrangements before treating shared software as an unrestricted business asset.
The broader prediction is that software creation could become increasingly decentralized. More people could publish useful tools because the effort required to create them has fallen, not because each project has a large commercial market.
ArtCraft and the Difference Between Recreation and Equivalence
Another example is ArtCraft, presented as a free, open-source creative software suite. Its applications include Photocraft for image editing, Vectorcraft for vector work, and Filmcraft for video editing.
The project illustrates the ambition of AI-assisted software recreation. Instead of tackling a small utility, developers are attempting familiar categories associated with sophisticated commercial products.
For Canadian tech businesses, these examples are useful signals of experimentation, but they require careful interpretation. A recognizable layout does not establish equivalent performance, file compatibility, stability, or depth.
There is also a distinction between reproducing functionality and decompiling software. Decompilation concerns reconstructing a representation of compiled code. Building an application with similar behaviour is a different process. Neither description, on its own, establishes what rights apply to a particular project.
The practical lesson is to evaluate the software itself and its licensing, rather than relying on the dramatic appeal of a “clone.” The relevant business test remains whether it solves the intended problem reliably and appropriately.
Does Cheaper Code Mean Software Value Approaches Zero?
Berman advances a provocative thesis: as AI makes applications easier to reproduce, the cost and value of software could move toward zero.
The strongest interpretation concerns the declining scarcity of implementation. If many people can generate similar functionality at low cost, charging primarily for access to that functionality may become harder.
But software value includes more than code. A business also depends on the confidence that a system will work, remain supported, and fit its operations.
For Canadian tech companies selling software, the strategic response is not necessarily to abandon subscriptions. It is to identify what customers are actually paying for:
- Reliable execution of an important workflow.
- Ongoing maintenance and dependable support.
- Compatibility with existing systems and business processes.
- Trust in how information and operational risks are handled.
- Continued improvement without imposing extra work on customers.
AI can pressure the price of reproducible features while leaving these other forms of value highly relevant. The more replaceable the implementation becomes, the more clearly vendors must demonstrate the value surrounding it.
Enterprise Software May Shift Toward Agents and Data
A related idea is that enterprise applications could become less central as AI agents perform tasks directly. In this model, two layers remain especially important: agents that carry out work and databases that preserve authoritative information.
The distinction matters. An AI system can interpret a request and coordinate actions, but durable business records still require structured storage and management.
For Canadian tech architects, the implication is not that every application interface disappears. It is that some interactions may move away from navigating screens and toward expressing an intended outcome.
That possibility changes where organizations should look for lasting value. A polished interface can be useful, but the underlying information, workflow rules, and reliability of execution remain fundamental.
The consumer-facing argument extends this enterprise thesis. Instead of waiting for an agent to replace an application completely, individuals can already experiment with generating smaller applications tailored to their preferences.
Maintenance and Security Remain the Hard Questions
Building an application is an event. Operating it is an ongoing responsibility.
Berman acknowledges the objection that AI-generated software may contain vulnerabilities and require continual updates. His response is that models are improving and that agents could eventually inspect, update, and maintain software at a lower cost than commercial alternatives.
That is a plausible direction, not a guarantee. Better code generation does not automatically establish secure operation. An application still needs to be assessed against its actual use and exposure.
Canadian tech leaders should therefore treat maintenance automation as something to evaluate, not assume. An agent may help identify defects or prepare fixes, but someone must remain accountable for accepting changes and handling failures.
A sensible evaluation includes questions such as:
- What information will the application access?
- Which actions can it perform, and with what permissions?
- How will changes be tested before use?
- Who will respond when the application stops working?
- What happens if the original developer or project maintainer becomes unavailable?
These considerations do not invalidate AI-built tools. They determine where such tools belong. A personal utility and a business-critical shared system should not face identical approval thresholds.
Local AI Hardware and Customizable Operating Systems
The software discussion also connects to computing infrastructure. Berman describes using an NVIDIA-powered system for local AI experiments, development, gaming, and video editing, emphasizing unified memory and native CUDA support.
The broader relevance is that access to capable local computing can expand how developers experiment with AI. However, the low token-cost examples do not establish that specialized hardware is necessary or economically justified for every project.
Canadian tech organizations should distinguish between two decisions: whether a custom application makes sense and where the AI work used to create it should run. Those questions are related, but they are not interchangeable.
Customization could extend beyond individual applications. Berman also points to Omarchy, associated with Ruby on Rails creator David Heinemeier Hansson, as an example of interest in more adaptable operating environments.
The larger idea is compelling: software may increasingly conform to individual working habits, including at the operating-system level. That remains a direction of experimentation rather than proof that existing enterprise desktop strategies should be replaced.
A Practical Build-or-Buy Framework for Canadian Businesses
Canadian tech leaders do not need to accept the most sweeping predictions to act on the underlying shift. A controlled pilot can test the economics without putting essential operations at risk.
- Choose a narrow problem. Start with a repetitive task whose requirements can be described clearly.
- Identify the minimum useful functionality. Separate what employees actually need from the broader feature set of an incumbent product.
- Inspect existing open-source options. Adapting a suitable project may be more efficient than generating an application from scratch.
- Record the full development effort. Include staff time, testing, integration, and revisions alongside token expenditure.
- Test realistic cases. A successful demonstration should lead to practical validation, not immediate assumptions of completeness.
- Assign operational ownership. Establish responsibility for maintenance, updates, and failure handling before expanding use.
- Compare the result with buying. Assess ongoing value, not simply whether the initial build was inexpensive.
For a GTA business or a startup elsewhere in Canada, this approach makes the debate concrete. The objective is not to prove that all software should be built internally. It is to discover where a focused alternative provides a better fit.
The Next Advantage Is Better Software Judgment
AI-assisted development is weakening an old assumption: that purchasing a packaged application is always the practical choice for organizations without spare development capacity.
The examples of PDF tools, analytics extensions, spreadsheets, and creative applications show why the conversation is changing. More functionality can be attempted quickly, and open-source distribution can make each successful experiment useful beyond its original creator.
Yet the strongest opportunity for Canadian tech is not indiscriminate software replacement. It is more disciplined selection. Organizations can become more demanding about feature fit, more precise about total cost, and more realistic about the responsibilities that accompany ownership.
The future may contain more custom software without eliminating the need for trusted software businesses. The winners will understand which parts of software are becoming inexpensive and which parts still require expertise, accountability, and sustained investment.
Which recurring software expense should Canadian tech leaders reassess first, and what evidence would justify building an alternative?
