Build It Yourself? Matthew Berman’s Case for Personal Software—and the Evidence It Still Needs

1. Host and Subject Background

Matthew Berman is the host and uploader of “They did it...,” an episode of Matthew Berman / Forward Future. The supplied metadata dates it to November 3, 2026, and gives a running time of 778 seconds, or about thirteen minutes. The transcript presents Berman’s own commentary and demonstrations; it does not establish an interview with an identified guest.

His relevant background within this episode is the activity he describes: testing models over a couple of years and building software for his own use. He approaches the subject as a user dissatisfied with existing tools, a tester seeking harder development tasks, and an advocate for a changing software economy. Those roles explain both the specificity of his examples and the enthusiasm of his conclusions. The episode moves from a PDF reader to video analytics, spreadsheet replication, open-source distribution, and maintenance. Its central question is whether generating a tool tailored to one person has become a practical alternative to buying an application designed for many.

2. What the Episode Covers

The opening problem is deliberately ordinary. While setting up a new PC, Berman needed to read a PDF and installed Acrobat. He describes being frustrated by features he did not need, promotion of other products, and pressure to log in. He acknowledges alternatives, but says Acrobat’s status as the standard drew him toward it. The experience led him to build his own reader. This is an account of his encounter with a product, rather than a comparative review of the PDF software available to every user.

Berman’s broader explanation has three parts. Models must be capable enough to complete the work, inexpensive enough to compete with purchasing software, and easy enough to use through autonomous agents. In his account, the model he calls Opus 5.5 marked a turning point: he could ask for an application or a clone and let the system proceed. He argues that lower task costs have now tipped the economics of building and maintaining personal software below buying or subscribing. The episode presents that conclusion as his experience, without a standardized cost comparison.

To illustrate capability growth, he traces his testing from Python Snake to a Rubik’s cube simulation and then to rebuilding Excel. Earlier attempts, he says, resembled Excel but retained rough edges and missing features. Recent models allegedly produced a browser version with complete functionality in roughly ninety minutes to a few hours. He cites about $10 in tokens, contrasting it with his quoted $180 standalone license price and $7–$10 monthly suite subscription. These are speaker-supplied figures and claims of completeness, not independently established measurements.

His narrower projects make the practical motivation clearer. Folio, his PDF application, is described as supporting drawing, notes, electronic signatures, and AI questions about documents. He calls it lightweight, fast, free, open source, and easy to extend. Outlier Tracker addresses his dissatisfaction with One of Ten: he says the latter accumulated unwanted features, required authentication, and occupied about 30% of the screen. His replacement supplies video statistics, tracking, and channel analysis, reportedly after about thirty minutes of development. Its stated purpose is to recover the functions he needs, rather than to demonstrate comprehensive equivalence with the original product.

3. Core Views: Reasoning, Examples, and Limits

The strongest idea in Berman’s argument concerns the definition of a successful application. Software made for one person can justify a feature that would never attract a broad market. That changes the development target: satisfying an individual workflow can be sufficient. Folio makes this appealing because the user can choose what to retain and what to add. Outlier Tracker illustrates a related possibility: a smaller feature set may be more useful when it removes interference from a familiar task. This reasoning supports selective replacement. It does not establish that the functions excluded from a personal tool lack value for other people.

That distinction becomes essential when the discussion turns to Excel. A recognizable spreadsheet interface, successful execution of common tasks, and complete feature parity are progressively stronger achievements. Berman repeatedly asserts the strongest version. The supplied account, however, does not enumerate a systematic feature assessment, compatibility evaluation, or complex file-round-trip test. His demonstration and description explain why he is impressed with the application; they do not let a reader independently verify the entire parity claim. The reported $10 token bill consequently cannot, by itself, establish the cost of a fully equivalent replacement. The object being priced must first be defined and tested.

Open source supplies a second mechanism in his argument. One person builds a base, publishes it, and allows others to adapt it at a fraction of the initial development cost. The important possibility is that later users avoid repeating the entire construction process. Berman presents Artcraft as an example, describing it as a free, open-source alternative to the Adobe suite and naming Photocraft, Vectorcraft, and Filmcraft. He says an AI was instructed to keep iterating toward a clone of existing software. Although he also uses the word “decompiling,” the episode does not explain a concrete reconstruction method or provide a comprehensive functional comparison. Its description should not be expanded into an unsupported technical account of how the project was made.

The step from reusable software bases to software having effectively zero value or cost is larger. Lower construction costs can alter an individual purchase decision. They do not settle who keeps an application working, handles failures, or verifies that a shared version fits a new user’s needs. Berman’s forecast that future software will be de facto open source therefore deserves separate treatment from his personal projects. The projects supply specific motivations and examples; the forecast projects a mechanism across the industry. The episode does not demonstrate that the mechanism will apply to every category of software or sustain every kind of application.

His recollection of the earlier “SaaS is dead” thesis introduces another distinction. In that enterprise-focused account, agents perform tasks while traditional databases preserve ground truth. The present consumer argument concerns people generating applications they can use themselves. Both ideas reduce dependence on a fixed application offering, but they address different questions. One concerns the division between execution and durable information; the other concerns who determines an application’s interface and functions. Their relationship is suggestive, rather than proof that both paths must converge on one architecture.

Maintenance and security remain the decisive unresolved conditions. Berman acknowledges that building software is insufficient: it must be updated and may contain vulnerabilities. His response is that better models should generate more secure code, continuously running agents could make upkeep cheaper than purchasing software, and other developers may maintain shared open-source tools. These are possible routes forward. In the supplied discussion, however, they depend on expected capability improvements, favorable operating costs, and continuing maintenance effort. No longitudinal maintenance accounting or security audit results establish that those conditions have already been met. The episode is best read as a concrete hypothesis about a changing economic threshold, with stronger evidence for individual motivation than for universal reliability or cost.

4. Learning and Application

A practical way to use this episode is to begin with a recurring task whose boundaries are clear. Folio suggests the right kind of question: what must this tool actually let its user do? Reading, annotating, signing, and asking questions about a document are distinguishable requirements. Write down the necessary operations before asking an agent to build anything. This is an application of the episode’s examples, not a success formula already validated by the program. A limited scope makes it easier to decide whether the result solves the original problem.

Then construct the economic comparison around a period of use. Berman explicitly includes both building and maintaining software in his argument, so an evaluation should record initial generation costs, human review, corrections, ongoing operation, updates, and security checks. Compare those inputs with a purchase or subscription over the same period. The first token invoice is useful evidence about one expense. It cannot stand in for every later expense. Frequent repair, substantial user attention, or a continuously operating maintenance agent could change the outcome. The episode supplies no long-term cost figure that can simply be carried into another project.

Match the acceptance criteria to the replacement claim. If the goal is to replace a few personal operations, test those operations with representative, controlled materials and examine the outputs. A PDF tool might be checked for whether annotations and signatures survive saving and reopening. A spreadsheet tool might be checked against calculations and file exchanges that its intended user actually depends on. These are proposed checks, not tests reported in the episode. A claim to replace an entire complex application requires broader validation. Capabilities outside the test scope should remain unknown rather than being inferred from an attractive interface or one successful demonstration.

Decide who will maintain the result before treating it as a dependable replacement. Berman offers two routes: maintain a custom version, potentially with an agent, or adopt an open-source application maintained by someone else. The first gives the user direct control over personal features while leaving them responsible for subsequent decisions. The second can reduce the burden of starting from scratch, but still requires examining who issues updates, how fixes arrive, and what happens to modifications made in a fork. Availability of source code does not itself answer those questions, and expectations about future agents cannot substitute for checking a particular project.

Finally, separate the immediate experiment from the wider vision. Berman mentions an operating system he calls Omaki to illustrate his enthusiasm for continuous customization, but his actionable invitation is to try a small application. That is a manageable place to compare expectations with results. His promotional laptop passage should also remain outside the software verdict: descriptions of personal hardware experience do not supply a controlled comparison of application completeness or development economics. The useful sequence is to define a need, test the output, account for maintenance, and then decide whether building has become the better option for that particular use.

Source

• Original episode: They did it...