How to Describe What I Want to Build So Claude Understands It -- Build with AI

What You Are Actually Building

The goal is to build this feature in Replit. When this is done, you will have a working Replit app with this feature live. Non-technical builders complete this in Replit using Claude to write all the code — you describe what you want, Claude builds it, you test it and describe any fixes.

The quality of what Claude builds for you depends entirely on how precisely you describe what you want. Here is the exact framework for outcome-description precision.

What You Need First

A Replit account (free tier is enough to start)
A clear description of what you want to build

You do not need to write any code. Claude handles all of it. Your job is to describe outcomes clearly and test what gets built.

How to Describe It to Claude

The most common mistake non-technical builders make is describing what they want at too high a level. "Add a database" is not specific enough. Claude needs to know: what data will be stored, what triggers the storage, who can access it, and what the data should look like when displayed back.

Start with the outcome, not the feature. Instead of "I need authentication," say "I need users to enter their email address, receive a six-digit verification code, and use that code to access a protected page at /dashboard."

Once Claude builds the first version, test it yourself. If something is wrong, describe the problem in plain language — what you expected to happen versus what actually happened. Claude fixes it. Repeat until it works correctly.

What the Working Version Looks Like

A correctly built version will have a working Replit app with this feature live. Run through the full user flow yourself before considering it done: create a test account, submit a test form, or make a test payment depending on what you built. If something breaks during your test, that is normal — paste the error message into Claude and describe what you were trying to do.

Common Mistakes and How to Fix Them

Describing too much at once — build one piece at a time, test it, then add the next
Trying to fix code directly instead of describing the problem to Claude in plain English
Not testing the full user flow — always go through every step a real user would take
Forgetting to set environment variables for API keys — never paste keys directly into code
Assuming it is broken when it just needs a page refresh or browser cache cleared

Frequently Asked Questions

How do I describe what I want to build to Claude?

Use the input-process-output framework: describe exactly what the user provides (input), what the app does with it (process), and what the user sees as a result (output). Eliminate all ambiguity -- every vague element produces a wrong assumption in the code.

What level of detail does Claude need to write good code?

Every specific element: all field names in a form, all database columns, all API calls with their specific services, all redirect URLs, all page content. If you have not specified it, Claude will assume something reasonable -- which may not be what you want.

What is the input-process-output framework?

A description structure with three parts: input (what the user provides or what triggers the app), process (what the app does with that input), and output (what the user sees or receives). Completing all three with no ambiguity produces buildable app descriptions.

How do I know if my description is specific enough?

Read it and ask: could this build in two ways that would be different from each other? If yes, it is not specific enough. A good description builds in exactly one way.

Should I include design details in my build description?

Include structural design details -- layout, sections, what appears where -- but not visual styling. For styling, tell Claude your brand colors and let it apply them. Structural specificity matters more than visual specificity at the description stage.