How to Build an App with Claude Without Coding: A Safe Method

Can you really build an app with Claude if you can't code?

Yes, within limits that are worth knowing before you start. When you ask Claude to build something, it writes code, usually the kind web browsers understand, and can run it in a panel next to the conversation. Anthropic calls these creations artifacts, and its help centre lists single-page websites, dashboards, documents, diagrams and small interactive tools among the things they can be. You see buttons and boxes instead of a wall of code.

That covers a lot of everyday needs: a calculator for a sum you do weekly, a flashcard quiz, a chart from a spreadsheet export, a one-page website, a form that produces a tidy report. What it does not cover on its own is anything that behaves like a product: customer accounts, payments, stored personal data, or a service that must stay up while you sleep.

In our workshops at Bodhih Training we ask people to sort every idea into three sizes before they build. A toy is for you, for now. A tool is something you or a few colleagues will rely on. A system holds other people's data, needs logins or handles money. Toys and tools are fair game for a non-coder. Systems can be prototyped by conversation, but should not be launched without technical help.

What should you write before you type the first prompt?

Most disappointing builds trace back to a one-line request. 'Make a calculator for unpaid leave' leaves the assistant to guess how your company works out a daily rate, and it will guess the most common way. Every gap in your description is a decision you have handed over.

Spend ten minutes on a one-page spec with five boxes. Anthropic's own prompt engineering guidance points the same way: be clear and direct, and give examples. The worked example is the box people skip and the one that matters most, because it pins down the rule and becomes your first test.

• Outcome: who uses it, and what they can do afterwards
• Inputs: everything the user types, picks or uploads, with types and limits
• Outputs: everything shown back, with formats
• One worked example: a real case solved by hand, with the answer
• Done means: three to five statements that must be true before you call it finished

How do you run the build conversation step by step?

Building by chat has a rhythm. Keep to it and the work stays calm. Break it, usually by asking for five things at once, and you get a version where two features work and something that used to work no longer does.

The single most useful habit is one change per message. If a change breaks something, there is exactly one suspect. When a version works, say so and give it a name ('this is good, call it version 3') so you can return to it. And when a chat has gone around the same problem three times, ask for a summary and the current code, then start a fresh conversation with both.

How do you check that what Claude built is actually right?

A calculator that is wrong looks exactly like one that is right. So does a dashboard. Testing is the part of the job that stays with you, and it is less technical than it sounds: you write down some inputs, write down the answers you expect, then see whether the tool agrees.

Write the expected answers before you run anything. Cover five kinds of case: the worked example from your spec, a few normal inputs, the edges (zero, the maximum, month end, 29 February), empty boxes, and silly inputs such as letters where numbers belong. You can ask Claude to suggest test cases, and it is good at thinking of edges, but run them yourself. An assistant saying it has tested its own code is describing what the code should do.

With data projects, check before you chart. Ask Claude to describe the file back to you (rows, columns, blanks, duplicates, totals rows) and to give headline numbers as plain figures. Compare those with a source you trust. Totals rows counted twice and refunds ignored are the classic ways a handsome dashboard ends up a third too high.

For anything containing facts, open every source. The US National Institute of Standards and Technology published a Generative AI Profile alongside its AI Risk Management Framework in July 2024 to help organisations identify risks particular to generative AI, and confidently stated false content is one of the risks it names. A reference that looks real is a lead to check, nothing more.

What should you never paste into Claude or any AI assistant?

Sort before you paste. Green is public information, your own writing and made-up sample data. Amber is real work data that includes people or confidential details: strip it down first, and check that your employer approves the tool for it. Red never goes in: passwords, one-time codes, API keys, card and bank details, government ID numbers, medical records and information about children.

Three techniques make amber data safe enough for most builds. Minimise by deleting every column the task doesn't need. Mask by replacing names with codes. Or fake it: give the assistant your column headings and three invented rows, build the tool with those, and load the real file only inside the finished tool.

Look up the privacy settings for whichever assistant you use. Anthropic's privacy centre, for example, has a page explaining when chats from its consumer plans may be used for model training and how users control that, and notes that its commercial products are covered separately. Other vendors have their own equivalents. Your company's policy outranks all of them. This is practical guidance, not legal advice; data protection rules differ by country.

How do you share or publish what you built safely?

Three questions come first. Who can open it? What can they see and change? What happens if it disappears? A link that anyone can open is public in practice, because links get forwarded. Anthropic's help pages say a published artifact can be viewed by people who don't have a Claude account, and that unpublishing an artifact which uses storage permanently deletes its stored data. Both facts matter before you click publish, and both could change, so read the current page.

Then run through seven layers that sit under every app, whatever built it: spec, data, auth (who is allowed in), secrets (there should be no passwords or keys in it), deploy (where it lives), test and backup. For a toy the answers are one word each. The day one of them changes from 'just me' to 'our customers', your toy has become something else.

Be honest about security. AI-built apps often ship with flaws that are invisible on a nice-looking screen. The OWASP Top 10, the standard reference for the most critical web application security risks, lists broken access control first in its 2025 edition: people being able to see or do things they shouldn't. A non-coder cannot spot that by looking. So tools with personal, financial or confidential data, or anything public that stores data, should be reviewed by someone who codes before going live.

When do you need Claude Code or a developer instead?

Chat-built tools run in a sandbox. Some projects need what a sandbox can't give: many files working together, a real database, user accounts, a web address of your own, connections to other services. Coding agents such as Claude Code exist for this. They work directly in a folder of code and can run commands, which is why someone present needs to understand what is being run.

Signs you have reached the border: other people depend on the tool weekly, it stores data that would matter if lost or leaked, it needs logins or payments, the code has outgrown a single conversation, or you have fixed the same bug three times. At that point the right move is to find a guide, such as a developer colleague, your IT team or a freelancer, and bring them your spec, your test cases and the prototype. A working prototype is the clearest brief a developer can get.

Does the same method work in ChatGPT, Gemini or Copilot?

Yes. Nothing in the spec, the seven moves, the testing or the privacy sort belongs to one product. Other assistants have their own preview features, with different names, different sharing rules and different limits on saving data. If an assistant gives you only code and no preview, ask for 'a single HTML file with everything in one file', save it with a name ending in .html and open it in your browser.

Because product details move quickly, learn the stable layer and look up the specifics on the day. If you would like the whole method with practice material, the Build with Claude: The Non-Coder's Kit from Bodhih Training packages it as ten graded projects, 120 prompts, a build log workbook and fillable checklists. To measure your starting point, AssessAll's Task Specification and Prompt Writing Work Sample is a useful benchmark, and Jobulary's explainer on the 70-20-10 model shows why learning by building sticks better than reading alone.