Application prototype: what is really worth testing?

What question should the prototype answer?

A prototype is valuable when it reduces a specific uncertainty. You may be testing whether users understand a flow, whether a process saves time, whether data can be retrieved from an existing system, or whether a team will accept a new way of working. Each question calls for a different prototype.

Write the hypothesis in one sentence: who has the problem, how they solve it today, and what should change after using the prototype. Then choose the smallest part of the process that can show you the answer. Without a success criterion, it is easy to polish features for weeks without learning anything new.

• Does the user complete the task faster or with fewer errors?
• Does the problem occur often enough to justify solving it?
• Can the idea be tested with sample data instead of customer data?
• Will the experiment show what to build next and what not to build?

What can you build yourself with AI?

You can build a mockup, a simple landing page, a form, a one-off script, a small internal tool, or a demo with synthetic data. AI can speed up interface sketches, test data, flow descriptions, and a first code version. In the 2025 Stack Overflow Developer Survey, 84% of respondents were using or planning to use AI, while 46% distrusted its accuracy.

The safe boundary for a self-directed experiment is where mistakes are reversible and do not touch real data, money, or system access. Keep secrets outside the repository, record changes in version control, and ask the model to explain decisions you cannot verify yourself.

• good scope: mockups, manually run scripts, demos, and process tests;
• higher-risk scope: login, real data, automatic sending, and payments;
• bad shortcut: giving a model keys, unlimited permissions, or approval authority.

Design for the audience, not yourself

A prototype with fake data mostly answers whether the idea is understandable. Real data adds permissions, privacy, incomplete records, limits, history, and responsibility for the result. The same applies to design: one polished screen can look good while later pages lose consistency without a maintained style guide.

Do not design for the way you happen to work. Usage depends on the audience, place, device, and working conditions. If GA4 for a particular news site shows 90% mobile traffic, that does not conflict with a global benchmark; it means the average does not describe that audience. StatCounter’s worldwide July 2026 figure was 52.57% mobile, 45.93% desktop, and 1.50% tablet. That is a reference point, not a ratio to copy; first-party data and user conversations matter more than the phrase “mobile first”.

When a prototype starts serving others

If a prototype only serves you or a small group, it may already be a finished product for that use. HubSmith made my work with LLMs easier because a local landing-page preview shortened the agents’ prototyping loop.

Likewise, a small SVG animation editor built for trans.eu made it possible to see and correct the result instead of generating an animation without visibility into its problems. In both cases, the value was easier work, not selling a separate product. When a tool starts serving real people, data, or a recurring process, you do not need an architecture for millions of users immediately. You do need reproducible startup, separate secrets, basic logs, a backup, a rollback path, and a clear response to failure. Production is a process, not a server address.

If you need evidence from a larger group, run a small pilot: a limited group, one defined scenario, recoverable data, and observation outside the happy path. If the prototype already solves the problem and risk is controlled, the right decision may be maintenance rather than expansion.

• a separate environment and a clean configuration test;
• a backup and at least one restore attempt;
• logs, a cost limit, and someone watching failures;
• a rollback plan and a criterion for maintaining, expanding, or ending the experiment.

Not everything needs a rewrite or expansion

Do not rewrite a prototype merely because the code is inelegant. Stop when every change requires the same workarounds, the correct result cannot be defined, the environment cannot be reproduced, or securing the prototype costs more than rebuilding a small stable boundary.

You can discard the code while keeping the hypotheses, pilot data, and process description. You can also replace one critical boundary instead of rebuilding everything. If a tool already solves an internal problem well, it does not need to become a market-facing product just to justify its existence.

It is also important to separate the speed of the first draft from the result of the whole cycle. DORA’s 2025 report collected responses from nearly 5,000 people: 90% used AI at work, more than 80% believed it increased their productivity, but 30% reported little or no trust in AI-generated code. The report found a positive relationship between AI use, delivery throughput, and product performance, but a negative relationship with delivery stability. That does not prove AI harms every project; it signals the need for tests, review, and fast feedback.

In METR’s randomized 2025 experiment, 16 experienced open-source developers completed 246 tasks in large, familiar repositories. When allowed to use AI, they took 19% longer on average; METR later reported an uncertainty interval of 2% to 39% slower. Developers expected a 24% speedup and, after completing the tasks, still believed AI had made them 20% faster. METR explicitly cautions that the result concerns a particular group, repositories, and tasks, so it cannot support a universal claim about every developer. The modest conclusion is to measure the whole loop — understanding, verification, integration, deployment, and maintenance — instead of counting generated files.