A mobile knife-sharpening van needs something most booking tools don't do well: customers pick a street stop and a time slot, say how many knives (and scissors) they're handing over, and get a ticket number they show at the van. The owner needs a page with the day's queue that strangers can't open.

I gave that description to NoCoder as one prompt and recorded the whole run. The 40-second cut above is real footage; the build part is sped up 30× and the booking part 2.6× (both marked on screen).

What happened, step by step

1. The prompt. Plain English: the business, the stops, the slots, the ticket, the owner page.
2. A plan first. Before writing any code it laid out a plan for the app.
3. Code, run. It wrote the app and the server that saves bookings, then started it. About 12 minutes from send to "Ready", 43 files changed.
4. Checks before "done". This is the part I care about. It ran the type check and the production build, sent requests to the running app, and clicked through the booking flow in its own browser.
5. The result. On a phone: pick Northgate Estates, 2:20 PM, four knives and a pair of scissors, get ticket #6. The owner's queue sits behind a sign-in.

What I'd want to know as a buyer

• Did it actually work, or did it just say so? Step 4 is the answer I trust: a real build, a real request to the running server, a real click-through. A summary saying "done" is a claim; those are observations.
• What's fake? Names and phone numbers in the demo are made up (the phone number is from the UK drama range).

You can open the app and the exact prompt in the gallery and try your own: nocoder.codes/gallery/the-grinding-wheel.

What small business would you try this on?

Looking finished isn't the same as working for a real business, though. Below are the five checks I run on every AI-built booking app, including the ones we build ourselves. Each takes a couple of minutes, and you don't need to read any code.

1. Book from two different devices

This is the most common failure. Many AI builders make a frontend-only app that saves bookings in the visitor's browser (localStorage). In the preview it works perfectly: you book a slot and it shows up in the list.

Now book from your phone and look at the list on your laptop. If your phone's booking isn't there, every customer's booking is living on that customer's phone, and the owner's list will always be empty.

What to ask for: "a full-stack app with a database, so bookings from every device land in one list."

2. Try to take the last spot twice

Set a slot to 1 place. Open the booking page in two browser windows and book that slot in both at the same moment.

If both bookings succeed, the slot limit is only checked in the browser. Real customers will double-book you. The limit has to be enforced on the server, inside the same database transaction that saves the booking.

3. Open the owner page without signing in

Copy the URL of the owner or admin page and open it in a private window. Then try the API behind it, if you can see one in the browser's network tab.

A "hidden" link isn't a login. The owner side should refuse you, both the page and the data behind it, until you sign in with a real password.

4. Check what the customer keeps

After booking, does the customer get anything: a booking code, a ticket number, a confirmation they can show at the door? If they close the tab, can they find their booking again?

If not, you'll get "did my booking go through?" messages all day.

5. Change something without touching code

Ask the builder to add a new time slot, change a price or rename a service. Then run checks 1 to 3 again.

AI builders often fix one thing and quietly break another. A change that removes the database or the sign-in is a common way a working app stops working.

A real example, including what's still wrong

Here is one we built with NoCoder, the AI app builder I work on. It came from a single prompt:

I run a mobile knife sharpening van. I park at a different street stop each day of the week. Make a site where customers pick a stop and time slot, say how many knives (and if any are serrated or scissors), and get a pickup ticket number. I need an owner page showing the day's queue in order so I can tick knives off as done.

It's a Next.js app with Prisma and database-backed API routes. Each stop has slots with a capacity limit, customers get a ticket number, and the owner signs in to work through the queue. Signed-out and wrong-password requests to the owner side are refused. It passes checks 1, 3 and 4. We haven't run check 2 (the double booking) on this build yet.

It isn't perfect, and the gallery page lists what's still wrong:

• switching stops can briefly show "van is not at this stop" until you pick the date again, because two requests race;
• one panel says "Next show", a theatre word in a knife-sharpening app.

That's the point of the checklist. Whatever tool you use, don't take "done" as evidence. Run the five checks before a real customer does.

Disclosure: I'm on the NoCoder team. NoCoder's agent runs the build, sends a real request to the running app and clicks through it in its own browser before it says done. The checks above still apply to anything you build, with any tool.

1. "Coder" models that can't call tools

The first surprise: qwen2.5-coder has no native tool calling in Ollama. It writes nice code in chat, but an agent needs it to call read_file, write_file and run_command, and it simply doesn't.

Of the models we tried, the Qwen3 family handled tool calls best. llama3-groq-tool-use:8b worked for one call and then fell back to plain text on the next turn, which kills a multi-step loop.

Lesson: pick a model for tool calling first and coding second.

2. Thinking mode fights tool calls

Qwen3's thinking mode would reason at length and then fail to produce the tool call. Turning thinking off fixed it. For Qwen3 that meant appending /nothink; other models take a think: false API parameter.

3. Tool calls that arrive as text

Small models sometimes write the tool call as JSON inside a normal text reply instead of a structured tool call. We added a parser fallback for JSON blocks, <tool_call> tags and a few other formats.

Ollama also doesn't support tool_choice: "required", only "auto". So when the model replied with text only, we retried with a short nudge: "You must use a tool now."

4. A 4GB GPU is mostly a prefill problem

On a GTX 1050 with 4GB of VRAM, the model spills into system RAM and generates at roughly 4–10 tokens a second. That's slow but usable.

The real killer was prefill. A 3,000-token prompt took 30–60 seconds before the first token appeared. An agent sends a big prompt on every step, so the timeouts piled up.

What helped:

• Compacting history without another model call. Older steps get replaced with a short structured summary: files read, files written, commands run, errors seen. Roughly 3,000 tokens became about 100.
• A "tiny model" mode. For very small models we drop retrieval context, the file tree and long instructions from the system prompt, and cap tool output at a few hundred characters.
• Fewer turns in memory. A tiny model gets the last 6 messages, not the whole conversation.

5. Cloud agent, local model

If the agent runs in the cloud, it can't see localhost:11434 on your laptop. You need a tunnel or a public address, and if it's public, a key in front of it. Ollama Cloud avoids that, since it's already reachable.

What we'd tell anyone trying this

• Test multi-turn tool calling, not single answers. Some models pass the first call and fail on the next.
• Budget for prefill, not just tokens per second.
• Expect the smallest models to chat fine and still fail full-stack builds. Use the biggest coding model your hardware or plan allows.

Disclosure: I work on NoCoder, where you can connect your own Ollama server or Ollama Cloud key and build full-stack apps with it, including on the free plan. The lessons above apply to any agent you run on Ollama.