Build a Website or App by Talking: Idea to Launch

There are several ways to build a website or app by talking. You can work with Codex, Claude Code, Lovable, v0, Bolt, or Replit, using available voice input or system dictation to turn your ideas into text in the prompt box. The AI can then help you plan, design, and develop the product.

The voice entry point depends on the tool and interface. For example, Claude Code supports voice dictation into its prompt input. In other tools, system dictation can provide the speech-to-text step.

Getting from a spoken idea to a usable product still takes a few decisions. Follow the process below with one example: a website where a photographer shows their work and collects shoot inquiries.

1. Describe the job out loud

With a local coding tool, create a project folder and open it in the tool. With an online builder, create a project so the conversation, files, and code stay together. You do not need a perfect specification before you begin. Start with something like this:

I am an independent photographer. I want a website where clients can see my work, compare packages, and send a shoot inquiry. Right now, prices, reference photos, and date requests are scattered across chat messages. The first version should collect that information for me. No online payments or customer accounts yet.

This gives the AI an audience, an existing problem, and a first-version boundary. It is more useful than asking for a beautiful photography website without explaining what visitors need to do.

2. Save the PRD, then discuss the technical plan

Ask the AI to find the decisions you have not made:

Do not write code yet. Identify questions that affect the product flow and ask me one at a time. Once we have agreed on the answers, save the requirements as PRD.md in this project.

• Does a client request a preferred date, or reserve a confirmed time slot?
• Does each package have a fixed price, or does it need a custom quote?
• Where will the photographer see and process incoming requests?
• What should the client see after submitting, so they do not mistake an inquiry for a confirmed booking?

Suppose you choose manual confirmation. The PRD should say that a successful submission displays Request received — awaiting confirmation from the photographer, rather than Booking confirmed. That single decision affects the form, confirmation screen, and admin workflow. For more examples of this distinction, see business requirements versus functional requirements.

Then ask for an implementation proposal:

Using this PRD, recommend a suitable technical approach for the first version. Explain how the pages will work, where requests will be stored, how I will view them, and where the site will be hosted. Explain your choices first, then save the agreed approach as TECH_PLAN.md.

You now have a document describing what to build and another describing how to implement it. Keep both in the project so later changes have a shared reference. Lovable's Plan mode, for example, supports discussing an approach and preparing a plan before implementation.

3. Approve the screens before generating the interface

Before asking the AI to implement the whole product, choose reference images, sketch wireframes, or draw the key screens in Figma. For the photography site, settle these decisions:

Once the design is clear, use a tool that supports image-to-code or Figma-to-code to generate the first interface. These methods turn an existing visual direction into code. For example, v0 can read a screenshot's layout, colors, and components and generate an interface from it. See our frontend design workflow for working with visual references.

A picture explains appearance; add the behavior explicitly:

Build the interface from this design. Clicking Inquire about this package should open the form with that package selected. Disable the submit button while sending. If submission fails, keep everything the visitor has entered.

4. Build and check the complete flow

Now ask the AI to implement the agreed documents and screens:

Build from PRD.md, TECH_PLAN.md, and the approved design. Complete the flow from viewing work to choosing a package, submitting an inquiry, and reviewing it as the photographer. Show me a preview as each part is ready.

Review it by doing what a visitor and the photographer would do:

• Choose a package and check that the form carries the correct selection.
• Leave contact information blank and check that the error explains what to fix.
• Submit a request and confirm that the photographer can actually see it.
• Refresh the admin page and check that the saved request is still there.
• Check that a failed submission preserves the entered information.
• Complete the entire flow on a phone.

When something fails, report the action and result together:

I opened the form from the wedding package, but the saved request shows the portrait package. Check how the selected package passes from the page into the stored request.

That gives the AI a reproducible problem to investigate instead of a vague instruction to fix the website.

5. Deploy, then connect a domain

Deploy the product to hosting that supports your technical plan and obtain a public URL. An online builder may offer its own publishing flow and default domain.

If you want your own address, register a domain with Cloudflare Registrar or another registrar, then connect it to the host. Buying a domain and deploying a website are separate steps. Cloudflare Pages, for example, documents its custom-domain setup. If the app uses a database, authentication, or email notifications, configure those services for production too.

Finally, open the public address on your phone and send a test inquiry. Confirm that the site loads, the submission succeeds, and the photographer receives the saved request.

6. Voice input still leaves a cycle of submitting, waiting, and checking

This workflow lets you develop a product from spoken instructions. Speech-to-text reduces typing, but you still submit a request, wait for generation, inspect the result, and explain the next change.

A change of direction can affect more than the interface:

I originally wanted to collect inquiries. Now I want clients to pick an available slot and pay a deposit.

That changes the screens, availability rules, data model, and payment flow. The tools can continue editing the project, but you need to explain which earlier decisions no longer apply, update the requirements and design, and check the implementation again.

When the voice entry point transcribes speech into a prompt, that input step is automatic speech recognition, or ASR. Transcription handles how you enter instructions. It does not, by itself, coordinate an ongoing product discussion and its implementation.

7. Keep the discussion inside the build with SayCraft

SayCraft brings requirements discussion, the build plan, and the product preview into the same meeting. Describe an idea, add constraints, look at the interface taking shape, and continue discussing changes. The system turns the discussion into requirements and a plan, then advances the implementation.

For the photography site, you might look at the preview and say:

Change Book now to Ask about availability. The customer is requesting a date; I still need to confirm it. Explain that on the submission confirmation screen too.

You can keep adding ideas while a build is running. New requirements feed subsequent implementation, and the preview updates as the implementation changes. Code generation still takes time, but the discussion does not have to wait for each build to finish.

For a project whose requirements become clearer through discussion, this keeps the conversation attached to the same evolving product: what you see, what needs changing, and what should happen next.