Talk-to-build: can you really make an app by describing it?

Can you really make an app by describing it? The question has been asked enough times to become a cliché, and the answer has kept changing underneath it. Here is where it actually stands in April 2026 — not the hype, not the backlash, but the shape of the workflow as it exists this month. We build Wemob, so we watch this corner of the industry closely, and we would rather describe it honestly than oversell.

What talk-to-build actually means

It isn’t “typing a prompt.” A prompt is a single instruction that produces a single output; you hand it a sentence and it hands you back a page. A conversation is iterative, stateful, and multi-turn, and the part that matters is that it remembers. The builder holds the state of your project across sessions. You talk to a thing that knows what it built last week, and you can pick the thread back up without pasting the previous twelve messages into a new window.

That sounds like a UX detail. It is closer to a philosophical move. The early-2023 pattern was a chat box next to a code block. It was impressive the first time and exhausting by the fifth, because every new request reset the world. You were not having a conversation. You were firing one-shot prompts at an amnesiac. The 2026 pattern treats the project as a living artifact the model is aware of, and treats your messages as edits to a document you are both looking at.

The difference shows up most clearly when you change your mind. In a prompt-first tool, “make the hero darker” requires you to remind the tool what the hero is. In a conversation-first tool, the sentence lands in the right place, because the tool knows. This is closer to the way you would brief a designer than the way you would query a search engine, and that shift is what the briefing essay was circling around.

What it’s good at today

Marketing sites and landing pages

This is the category the AI builders have genuinely solved. A bakery’s site, a photographer’s portfolio, a product launch page, a Patreon-adjacent tip jar — these ship in a conversation and they ship well. The structural work is familiar to the models because the web is full of examples, and the polish work responds to specific direction. If you describe a mood and point at a reference, the output is close to usable on the first pass and close to done by the third. A designer with real taste will still produce something more distinctive, and we are not pretending otherwise, but the floor has risen far enough that “I described this and it exists” is not a party trick anymore. It is a Thursday afternoon, and a reasonable result at the end of it.

Small shops and one-product stores

A commerce-wired builder ships these in a conversation too, and the small web is having a real comeback because the tools finally match the shape of small ambitions. A soap maker with thirty products, a zine publisher with a single issue, a ceramicist taking five orders a week — these used to require a Shopify account and a week of theme work. They now require a description and an afternoon. The result is not always pretty in the way a bespoke site is pretty, but it is honest, and it is alive on a real URL, and the person who made it can edit it without opening a code editor. That matters more than the category has admitted.

First-version apps and internal tools

CRUD dashboards, simple forms, internal-only tools, the tiny Rails-shaped thing an operations team needs and does not want to ticket engineering for. The zero-to-one pass is real, and teams are using this for kick-off versions they hand to an engineer later rather than for finished products. That is the right way to use it. The model does the boring 80%; the human does the interesting 20% that determines whether the thing survives contact with users. The fact that the first 80% is cheap now, and that a product manager can build it on a Saturday to show on Monday, is the story worth telling about this whole wave.

Where it still breaks

Complex state and heavy integrations

Multi-system workflows are still human work. Orchestrating three SaaS APIs, handling retry logic, designing state machines that survive partial failure, reasoning about eventual consistency — a conversation will not do this for you yet, and pretending otherwise is how bad apps get shipped. The model can scaffold the shape. It cannot reliably get the edge cases right, and the edge cases are where the real work lives. If your project has a sentence like “when the webhook fails, we need to reconcile” in it, you still need a human.

Production-grade auth and permissions

The scaffolds exist. Login pages, signup flows, session cookies — the builders generate these cleanly and they usually work. Hardening doesn’t come from a conversation. You still need a human who can reason about session invalidation on password change, token refresh under load, role-based access with inheritance, and the six different ways authorization can go quietly wrong in the fifth week of a new feature. A generated auth page that looks right is not the same as an auth system you would trust with a customer’s data. The gap is real and the category has not closed it.

Performance tuning

When the app starts to be slow, the conversation can’t tell you why. You need someone who understands where time goes in the stack — which query is the hot one, which render is wasteful, which cache would fix it, which would only hide it. This will improve. The tools will eventually grow real introspection and profiling. It isn’t there yet, and if your product’s first real problem is a performance one, you are out of the territory talk-to-build currently covers.

The 2026 state of the art

What is actually here in April 2026, as far as we can describe it plainly: real files rather than a sandbox you can’t leave. A URL at the end of every session. Commerce wired in quietly, not as a separate product or an SDK you bolt on, but as a first-class thing you can describe in a sentence and have back on a page. Conversation memory that carries across sessions and knows what it built last week, so you don’t start from zero when you open the tab on Tuesday. These are the pieces that make the workflow feel like a continuous project rather than a sequence of disconnected prompts.

The contrast worth drawing is with two adjacent approaches. Prompt-first tools like the ones described in the v0 comparison are optimized for speed of generation inside a specific ecosystem, and they are genuinely excellent at that. Sandboxed tools like the ones covered in the Lovable comparison are optimized for a managed environment that makes the first demo easy. Wemob’s betis that conversation plus real files plus commerce, together, match the shape of most small web projects better than either of the other two patterns. We could be wrong about that. We don’t think we are.

The honest version of the answer to the opening question is yes, with footnotes. You can make an app by describing it, if the app is one of the kinds the tools are good at, and if you bring specific taste to the description. You still can’t describe your way to a production auth system or a performance fix on a slow query. That gap will narrow. It has been narrowing every six months since this wave started, and there is no reason to think it will stop.

If the idea of building something by talking to it sounds worth a try, the fastest way to find out is to open Wemoband describe something small — a page for a friend’s dinner party, a one- product shop for the thing you make on weekends, an internal tool you’ve been meaning to build for a year. The worst case is you spend an afternoon. The best case is you finally ship the thing that has been sitting in your notes since last summer, which is the reason we made this in the first place.