For Van Gogh, speed was not a cult of carelessness, but a way to preserve the living structure of an impression. He did not think that a good painting is born “quickly” out of emptiness: on the contrary, he wrote that to grasp the essence of things one must work long and hard. But when the image had already matured, he considered it dangerous to polish it endlessly: in letters to Theo he admired the old masters for painting quickly, “putting” the form onto the canvas at once and, if the work succeeded, leaving it alone; separately, he formulated the principle of “painting in one go, as much as possible.” In another letter, he directly linked speed with the nature of observation itself: beautiful effects of light in nature require a quick hand, because the moment passes, and excessive reworking kills vitality. That is, for Van Gogh, the minimum time for a painting is not labor savings, but protection of the primary vision from disintegration under the pressure of perfectionism, criticism, and endless edits.

From this follows an important consequence for IT: a painting is not just an image of objects, but a compressed model of the world passed through the author's temperament. Van Gogh himself wrote that we see nature not literally, but through our own temperament; his numerous “sketches” in letters served as a way to convey to Theo not only the look of the future painting, but also the structure of the idea, almost like a visual technical specification before the appearance of Figma, Jira, and other civilizational punishments. In web application development, we do the same: we take a real process: manufacturing a part, processing a request, booking a client, warehouse work, money movement, and create its formalized picture. The database, interface, roles, statuses, scenarios, and constraints become brushstrokes from which a model of the real world is assembled. The “Van Gogh Method” in this sense is an attempt not to discuss reality endlessly, but to quickly fix the author's vision of the process in a finished digital artifact: not perfect and not eternal, but coherent enough to be shown, used, sold, or replaced with the next, more accurate picture. This directly continues the original idea of the dialogue about a software product as an immutable artifact-model of a business process.

The Van Gogh Method in creating web applications: rapid synthesis of finished software artifacts with AI agents

Abstract

The Van Gogh Method in the context of web development can be defined as an approach to creating small, finished, sellable web applications in an extremely compressed cycle: from understanding the subject area to generating a specification, implementation, testing, and publication. Its key idea is not to endlessly improve one product, but to quickly create many completed software artifacts, each of which represents a limited model of some real business process.

Unlike a classic MVP, which is created as a means of testing a hypothesis and almost inevitably implies iterations, the “Van Gogh” artifact strives to be an independent finished object: it is either sold, used, and scaled as a separate version, or left as part of a portfolio of experiments. This does not completely cancel maintenance, because web applications live in a changing environment, and people, as it turns out, change requirements faster than servers manage to reboot. But the method limits endless refinement: functional changes are framed as a new “painting,” not as eternal tinkering with the old one.

The historical metaphor of Van Gogh is important here not as a romanticization of suffering, but as a model of productivity and selection. Over a career of roughly a decade, Van Gogh created nearly 900 paintings and more than 1100 works on paper; his value arose not from one perfect “first brushstroke,” but from the density of practice, expressive style, consistency, and subsequent cultural selection. The myth that he sold only one painting during his lifetime is also simplified: Van Gogh Museum states that the exact number is unknown, but it was more than a couple, including a commission for 19 city views of The Hague and the sale of “The Red Vineyard”. (The Metropolitan Museum of Art)

1. Central thesis

The Van Gogh Method for web applications is not “vibe coding,” not chaotic code generation, and not another heroic fantasy about a programmer who wrote a CRM, ERP, accounting system, and the meaning of life overnight. It is a disciplined way to quickly create narrow web products, using AI agents as the executing force and the human as the source of intent, domain evaluation, and final selection.

The formula of the method:

Compress the domain → form an aggressively precise specification → generate the application → verify it with minimal objective tests → release it as a finished artifact → do not turn it into endless repairs, but create the next version or the next product.

In the original dialogue, this idea arises from the contrast between two modes: ordinary perfectionist prototyping, where the product may not appear at all, and the radical mode of “one long brushstroke,” where a tangible product result is created within a limited time. An important thought also appears there: 10 minutes may not be the time of full development, but the time of human involvement — 5 minutes for primary understanding of the niche and 5 minutes for forming a powerful prompt, after which the agent system performs the main work.

2. Why this is not just an MVP

A classic MVP in Lean Startup is a minimal product that allows the “build-measure-learn” cycle to begin as quickly as possible: build, measure, learn, and change direction if necessary. Lean Startup directly describes the MVP as an initial tool for learning and hypothesis testing, not as a finished artistic object. (theleanstartup.com)

The Van Gogh Method is close to an MVP in speed, but differs in philosophy:

That is, MVP says: “release the minimum to learn.” The Van Gogh Method says: “create a small but complete object so it can be bought, used, or discarded.” The difference is subtle but important. MVP lives in the logic of iteration. The Van Gogh Method lives in the logic of series.

3. Theoretical basis: why a web application cannot literally be “eternal”

The dialogue raises the question: is it possible to create a program that never needs to be edited again? For web applications, the honest answer is unpleasant, like a cloud bill after a “small experiment”: almost never, if the application is connected to a living business process.

Lehman's laws of software evolution are useful here. He described E-type systems as systems that solve problems or implement applications in the real world. For such systems, the law of continuing change applies: an E-type program that is used must constantly adapt, otherwise over time it becomes less satisfactory. (gwern.net)

This fits web applications perfectly. If an application automates appointments for manicures, cleaning, a warehouse, manufacturing, sales, or support, it depends on real people, regulations, payments, interfaces, access rights, taxes, APIs, browsers, and strange management decisions. All of this changes. Therefore, absolute immutability is possible only for very narrow and stable programs: converters, calculators, static generators, utilities, visualizers, local tools.

Fred Brooks in “No Silver Bullet” divided programming complexity into accidental and essential. Tools can reduce accidental complexity: syntax, boilerplate code, build, infrastructure. But essential complexity remains in the subject area itself: what exactly the application must do, what business rules it reflects, what exceptions the process has.

That is why the Van Gogh Method should not be “AI, write me a SaaS,” but a method for compressing essential complexity into a form that an agent can implement without endless clarification.

4. Why this has become practically possible now

AI tools have already changed development, but not as primitively as “the neural network will replace everyone except the person pretending to understand the prompt.” The data is contradictory, and that is exactly what matters.

In a controlled GitHub Copilot experiment, developers with access to an AI assistant completed the task of implementing an HTTP server in JavaScript 55.8% faster than the control group. This strongly supports the idea that AI is especially powerful in limited, formalizable, greenfield tasks. (arXiv)

But a 2025 METR study of experienced open-source developers showed the opposite picture: 16 developers performed 246 tasks in mature projects where they had an average of 5 years of experience; when AI use was allowed, they expected acceleration, but actually spent 19% more time. (arXiv)

Conclusion for the Van Gogh Method: AI is better used not as a “magical accelerator of everything,” but as a factory of greenfield artifacts on a standardized platform. An agent is more effective when the task resembles creating a new limited application, rather than carefully intervening in a mature codebase with history, context, and technical scars.

The industry is already moving there. Stack Overflow Developer Survey 2025 shows that 84% of respondents use or plan to use AI tools in development, and 51% of professional developers use them daily. At the same time, trust remains low: more developers actively distrust the accuracy of AI outputs than trust them, and the main frustration is solutions that are “almost right, but not quite.” (Stack Overflow Insights)

Large companies are also adopting AI in development. In Q3 2024, Google reported that more than a quarter of new code inside the company is generated by AI, after which it is reviewed and accepted by engineers. (blog.google) Anthropic, in an analysis of 500,000 coding-related interactions, found that Claude Code is used more often for automation than for augmenting a human: 79% of conversations were classified as automation; it also noted that JavaScript and HTML were the most frequent languages in the dataset, and UI/UX tasks were among the leading scenarios. (Anthropic)

This directly supports the chosen area: web applications, interfaces, micro-products, startup prototypes, and small business systems.

5. Definition of the method

The Van Gogh Method is a process for creating a series of finished web applications, where each application:

1. models one limited business process or one subject niche;
2. is created in a strictly limited cycle of human involvement;
3. is implemented by AI agents based on pre-prepared architectural primitives;
4. passes a minimal set of objective checks;
5. is published as an independent product artifact;
6. is evaluated by the market, usage, or sale;
7. does not turn into an endless backlog, but is replaced by a new version if necessary.

The key shift: we are not trying to create a perfect program for the ages. We create a “painting”: a completed model of a fragment of the real world. If the model becomes outdated, a new painting appears. Not endless restoration, not endless “let's add this too,” not corporate necromancy over a form no one asked for.

6. The gradient of “eternity” of web applications

Not all web applications are equally suitable for the method. A selection criterion is needed.

From this follows a practical rule:

The Van Gogh Method works better the more stable the domain is, the fewer external integrations there are, the lower the legal risk is, and the narrower the business process is.

7. Architectural model

For the method not to turn into “generated junk, deployed it, pray,” a platform is needed. The dialogue mentions “Fractal” as a possible product framework. In formalized form, this can be described as a generative platform for assembling niche web applications.

Its layers:

This is not just a set of prompts. It is a factory where the human is responsible for choosing the subject and final evaluation, and the system is responsible for repeatability of production.

8. The “5 + 5 + agent” cycle

An important operational idea appears in the dialogue: a human does not have to write code. In 10 minutes, they can prepare such a dense assignment for the agent that it will then complete the project. Let us formalize this.

Phase 1. Domain reconnaissance, 5 minutes

The goal is not to “study the industry,” because in 5 minutes you can study only the degree of your own self-confidence. The goal is to quickly obtain a working map of the subject area.

AI should output:

• who the users are;
• what pain the business has;
• what entities exist in the system;
• what processes are most often automated;
• what errors and edge cases are typical;
• what minimum product can be sold;
• what functions must not be included in the first brushstroke.

Phase 2. Aggressive specification, 5 minutes

Based on the reconnaissance, the human forms a “bold prompt”: not a request to “make a website,” but a directive where the following are specified:

• niche;
• target user;
• product result;
• stack;
• screen structure;
• user roles;
• data models;
• business rules;
• tests;
• constraints;
• readiness criteria;
• result format.

Phase 3. Agent implementation

Then the coding agent:

• creates the project;
• writes models and migrations;
• assembles the interface;
• adds authorization and roles;
• writes tests;
• runs checks;
• fixes errors;
• prepares deploy;
• creates README and a commercial description.

Phase 4. Human selection

The human does not have to proofread every line, but must make a decision:

• it is sold;
• it is sent to the portfolio;
• it is remade as a new version;
• it is destroyed, because some paintings are better not shown even to relatives.

9. “Never edit again”: the realistic version

Absolute immutability of a web product is dangerous. AI-generated code can contain vulnerabilities: an empirical study of Copilot-generated snippets found security weaknesses in 27.3% of 733 snippets, including 29.5% of Python and 24.2% of JavaScript snippets. (arXiv) CSET also highlights risks of AI-generated code: insecure code, vulnerability of the models themselves to attacks, and downstream risks for the supply chain; in their assessment, almost half of snippets from five LLMs contained bugs that could lead to exploitation. (cset.georgetown.edu)

Therefore, it is more correct to divide immutability into two modes:

This way, the method preserves the main idea: not to turn every small product into an eternal maintenance pit, where “one more tiny edit” becomes a way of life.

10. Metrics of the method

For the method to be not a beautiful fantasy but a researchable practice, metrics are needed.

Production metrics

Quality metrics

Market metrics

Engineering metrics

DORA proposes measuring throughput and instability through change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. These metrics are useful for the Van Gogh method as well, but they must be applied at the level of a specific application, rather than mixing different products into one mess, as reports like to do for the sake of feeling in control of chaos. (Dora)

DORA 2024 also shows an important nuance: AI increases individual productivity, flow, and satisfaction, but can negatively affect delivery stability and throughput, so small batches of changes and strong testing remain critical. (Dora)

11. Which web applications are worth “Van Goghing”

Best candidates:

1. Niche CRMs For example: CRM for a nail studio, cleaning, equipment repair, equipment rental, local delivery.

2. Calculators and configurators Calculating service cost, selecting a package, generating a commercial proposal, preliminary estimate.

3. Request systems FORMA → status → manager → notifications → report.

4. Mini client portals The client sees requests, documents, invoices, statuses.

5. Operational dashboards Simple admin panels for small businesses: orders, contractors, calendar, statuses, finances.

6. Document generators Templates for contracts, acts, instructions, checklists, commercial proposals.

7. Educational micro-products Knowledge bases, internal instructions, interactive simulators.

Bad candidates:

• medical diagnostics;
• fintech with real money;
• legally significant automated decisions;
• complex ERPs;
• products with a large number of API dependencies;
• everything where an error can cost a life, freedom, a client’s money, or a visit from a lawyer who only smiles when issuing an invoice.

12. Economic logic

Ordinary development is often arranged like this: a team spends a long time building one product, then hopes that someone needs it. The Van Gogh method proposes a different strategy: quickly create a series of small products and let the market select the ones that have value.

This is closer to a portfolio approach:

Not one large product with a huge bet, but many small finished artifacts, each of which tests a separate niche, pain point, or business process.

An important thought in the dialogue: the value of a product is measured not by how proud the developer is of the architecture, but by whether people buy it. That is blunt, but honest. The market is not obliged to respect your DDD, especially if the user simply wanted “requests not to get lost.”

The method is especially suitable for:

• startup founders who need to test niches quickly;
• small and medium-sized businesses that do not need a heavy corporate system;
• automation agencies;
• AI-first studios;
• companies that want to replace manual processes with microsystems;
• product teams that need a quick market scan.

13. Scientific hypotheses to test

For this to become not just a concept, but a research program, testable hypotheses can be formulated.

H1. For greenfield web applications with a limited subject area, the Van Gogh method reduces human time to first deploy compared with traditional development.

H2. The quality of the result depends not on the length of the prompt, but on the completeness of the domain structure: actors, entities, scenarios, constraints, acceptance criteria.

H3. AI agents provide the greatest gain in tasks for generating new applications and the smallest or negative gain in tasks for changing mature codebases. This aligns with the contrast between the GitHub Copilot experiment and the METR study. (arXiv)

H4. The lower the domain volatility and the number of external dependencies, the longer the lifespan of the “frozen” artifact.

H5. A portfolio of many small products can provide a faster market signal than deep polishing of a single MVP.

H6. With a ready-made platform of primitives, the quality of AI-generated applications grows faster than when generating “from scratch” for each niche.

14. A practical template for a “bold prompt”

Ты выступаешь как продуктово-технический агент, архитектор, full-stack разработчик и QA-инженер.

Цель: создать законченное веб-приложение для ниши: [НИША].

Целевая аудитория:
[Кто покупает продукт]
[Кто ежедневно пользуется продуктом]

Главная боль:
[Какая проблема должна быть решена]

Формат результата:
Создать production-ready MVP, который можно показать клиенту, продать как SaaS/white-label или использовать как демо.

Стек:
[Backend]
[Frontend]
[DB]
[Auth]
[Deploy target]

Ограничения:
- Не добавлять лишнюю функциональность.
- Не использовать внешние API без необходимости.
- Все бизнес-правила держать явно.
- Все формы валидировать.
- Все роли и права доступа описать.
- Не оставлять секреты в коде.
- Подготовить seed data.
- Подготовить README.
- Подготовить демо-сценарий.

Нужно реализовать:

1. Краткое доменное описание:
   - акторы;
   - сущности;
   - ключевые процессы;
   - edge cases.

2. Модели данных:
   - таблицы;
   - поля;
   - связи;
   - ограничения.

3. Роли:
   - owner/admin;
   - manager;
   - user/client;
   - при необходимости staff/operator.

4. Экраны:
   - dashboard;
   - список сущностей;
   - создание/редактирование;
   - карточка объекта;
   - отчёты;
   - настройки.

5. Основные сценарии:
   - создание заявки/заказа;
   - изменение статуса;
   - назначение ответственного;
   - уведомление;
   - просмотр истории;
   - экспорт/отчёт.

6. Критерии готовности:
   - проект запускается локально;
   - миграции выполняются;
   - seed data создаются;
   - ключевые сценарии проходят;
   - тесты проходят;
   - нет критичных security issues;
   - README объясняет запуск и демо.

7. Итоговый результат:
   - код;
   - структура проекта;
   - инструкция запуска;
   - список реализованных функций;
   - список ограничений;
   - идеи для следующей версии, но НЕ реализовывать их.

15. Example: a “Van Gogh-style” application for cleaning

Domain: a small cleaning company.

Product: a web application for requests, cost calculation, assigning contractors, and status control.

Entities:

• client;
• cleaning site;
• request;
• service;
• contractor;
• shift;
• invoice;
• status;
• comment.

Screens:

• public request form;
• cost calculator;
• request admin panel;
• contractor calendar;
• client card;
• report on completed work;
• service and price settings.

Why it fits the method:

• clear business process;
• low regulatory complexity;
• can be made without complex APIs;
• the value is easy to explain to a business owner;
• the product can be sold as white-label to several companies.

Boundary of the first brushstroke:

• do not make a mobile app;
• do not make complex routing;
• do not make accounting;
• do not make integration with every CRM in the world, because that is no longer a painting, but an administrative crime against common sense.

16. The main danger of the method

The main danger is confusing speed with value. AI can generate code quickly, but quickly created code is not the same as a useful product. Stack Overflow 2025 directly shows that developers use AI en masse, but face “almost correct” solutions and difficult debugging of AI-generated code. (Stack Overflow Insights)

Therefore, the Van Gogh method must have three mandatory filters:

1. Domain filter The application solves a real, understandable, sellable problem.

2. Engineering filter The application passes tests, security checks, and a basic UX check.

3. Market filter The application can be sold, implemented, or at least shown to a potential client without shame on the level of “I made this at 3 a.m. and now it is looking at me.”

17. Final formulation of the idea

The Van Gogh method is a technology for rapidly generating finished web applications, based on portfolio creation of small product artifacts. It uses AI agents to remove the accidental complexity of development: code, templates, interfaces, tests, documentation, and deployment. The human remains responsible for essential complexity: choosing the domain, understanding the pain point, limiting the form, accepting the result, and market selection.

The method does not promise eternal web applications. It offers something more realistic: creating applications that have a chance of being complete enough to be used or bought without long development. Their “eternity” is achieved not by the absence of changes in the world, but by the right boundary: a small domain, a clear model, minimum dependencies, a version as a finished object.

In this sense, a web application becomes not an endless project, but a digital painting of a business process. Not everything will become a masterpiece. Most will not. But with high speed, discipline, a series, and market selection, there is a chance to create not one bloated product, but an entire gallery of working solutions.

And this is no longer “vibe coding.” It is a factory of fast software artifacts. Almost civilized, which for web development is a rare event in itself.