Skip to content
Practical technology, explained simply

Build with AI · making things

Building products with AI without programming

A realistic method for turning an idea into a useful prototype with AI, without over-building or promising what does not work yet.

Ibrahin·Published on 2 September 2026·3 min read

Text drafted with artificial intelligence. The topic, the angle and the final review are Ibrahin's. How AI is used here

A laptop showing a cassette-shaped music player, surrounded by pencil sketches of that same screen, a cassette tape and a pair of headphones.
Illustration, not a real screenshot.

AI lets you create prototypes without knowing how to program, but it does not remove the product decisions. Before choosing a tool you have to check that a problem exists, that somebody wants it solved, and that the result can be reviewed when the AI gets it wrong.

Short answer

Start with one specific problem, one input and one output. Test the flow with fictional data, measure the errors, and keep a human review before turning it into a real product.

1. Describe the problem without mentioning technology

Finish this sentence: “Someone needs ___ and today they solve it by ___.” If the answer is “I want an app with AI”, the problem is still missing.

Talk to people who might use it and ask what they do now, how much time they lose, and what solutions they have tried. Do not just look for people telling you the idea is interesting: look for examples of a need that already costs them time, money or frustration.

2. Reduce the prototype to one flow

A useful prototype can have:

  • a clear input;
  • a process;
  • an output you can check;
  • a way to correct or repeat it.

For example, taking some notes and returning a task list. You do not need users, payments, dashboards and ten integrations to find out whether the output helps.

3. Define what the AI can and cannot do

Write down correct examples and cases that must be refused. If the tool summarises, define how it should handle incomplete data. If it classifies, decide what happens when it is not sure. If it drafts, make clear that a person reviews before sending.

A convincing output can be wrong. The product should show the uncertainty or ask for review, not hide it.

4. Test with fictional data

While it is a prototype, use invented or public examples. Check whether the input is stored, who can see it, which service processes it, and how it is deleted. Do not use client information just because it makes the prototype look more real.

If the product needs personal information in order to work, define the minimisation, the permissions and the retention period before asking for it.

5. Measure before adding features

Log ten or twenty tests and note:

  • how many answers are usable without correction;
  • which errors keep repeating;
  • how long each result takes;
  • what each use costs;
  • when a person decides not to use it.

A new feature does not fix an accuracy problem you do not yet understand. Improve the main flow first.

6. Decide where a person is needed

Human review is compulsory when the output can affect money, health, employment, privacy or reputation. It is also advisable whenever the user cannot easily check the answer themselves.

In my experience building this project, the separation between Ibrahin, ChatGPT and Codex was not a formality. It stopped a technical tool deciding priorities, and stopped an automation treating an idea as a finished product.

7. Choose the tool afterwards

A no-code solution may be enough to validate the idea. Compare price, limits, exporting, privacy, integrations and maintenance. Do not choose on the flashiest demo.

Ask what happens if the provider changes the plan, shuts down, or alters its data policy. Keep the content and the decisions outside the tool wherever you can.

Common mistakes

Building before talking to users

A perfect prototype of a problem that does not exist is not a product.

Promising autonomy too early

If the AI fails on basic examples, a beautiful screen does not fix it.

Mixing test and production

Keep the accounts, the data and the permissions of the experiment separate.

Hiding the use of AI

Explain where it is involved and what responsibility the person keeps.

What I would do

I would choose a single flow I could explain in a minute, test it with five people, and write down the failures without dressing them up. Only then would I decide whether it is worth building more.

Final checklist

  1. Does the problem exist before the AI?
  2. Does the prototype have one input and one output?
  3. Can it be reviewed and corrected?
  4. Have the test data and the real data been kept apart?
  5. Do you know what it costs to keep running?

Sources

Review

Responsible for publication: Ibrahin. Date: 2026-09-02. Last checked: 2026-09-02.