Do not pretend the feature works
A user wrote one line in his prompt that every prototype should carry: do not pretend that AI voice, memory or autonomous actions work unless they are actually implemented. Why an honest prototype is worth more than an impressive one.
Ilyos Olimov · · 4 min read
Last week a user typed this into AppX, in the middle of a prompt for an AI assistant app:
Do not pretend that AI voice, long-term memory, or autonomous actions work unless they are actually implemented.
I have read a few thousand prompts. That is the first time anyone wrote that sentence. And the app it produced was better for it, not worse.
What the app did with it
The assistant was built as an offline prototype. The chat works with local replies, and the screen says so in a small badge: "Offline prototype, local replies". The microphone button exists, looks right, and when you tap it, it tells you voice mode is coming soon. The settings screen has a row called "Connect a real AI service" that explains the local assistant is active and a real one can be plugged in later.
Nothing is faked. Nothing spins for two seconds and then shows a canned answer pretending it thought about it. The app is honest about what it is, and it is still a good demo, because the design, the flow, and the structure are real.
Why prototypes lie
A prototype is usually built to impress someone. An investor, a client, a co-founder, yourself. And the fastest way to impress is to show the magic moment: the voice command that works, the AI that remembers, the button that does the thing.
So people fake the magic moment. A hardcoded reply. A timer that pretends to listen. A "payment successful" screen that never touched a payment.
The problem is not ethics. The problem is that the fake moment is the most expensive part to make real, and the prototype hides that cost from exactly the people who need to see it. The investor prices the company on a demo that is 20 percent product and 80 percent theatre. The client signs for a delivery date that assumed the hard part was done. You, three weeks later, discover the hard part is still ahead.
What an honest prototype looks like
- It says what it is, on the screen. A badge, a line in settings, a "coming soon" on the button. Not in a README nobody opens.
- The placeholder is shaped like the real thing. A local assistant that answers in the right language and the right tone is a placeholder. A lorem ipsum chat is not. The point is to make every other part of the app testable now.
- The seam is visible. Where will the real service plug in? If the prototype has a settings row for the server address, the next developer knows exactly where to start.
- The real parts are really real. Notes saved on the phone are saved on the phone. The navigation works. The list scrolls. Nothing that works is pretending either.
What this means for how you describe an app
When you describe an app to an AI builder, say what must stay honest. It costs one sentence. Without it, the builder optimises for "looks like it works", because that is what most people ask for. With it, the builder puts the truth in the interface.
A good template:
Start with a working prototype. Do not pretend that [the hard features] work unless they are actually implemented. Structure the project so real [services] can be connected later.
The uncomfortable part
This applies to the companies building the tools too. AppX is an AI app builder. It would be easy to pretend that every app it makes is ready for the App Store on day one. It is not. A first build is an honest prototype: real screens, real navigation, data on the phone, no backend unless you add one. I would rather tell you that on the landing page than have you find out after the free credits.
The user who wrote that sentence understood something that took me longer to learn: the demo that admits what it cannot do yet is the one people trust with the next step.
Keep going
More practical ways to move your app forward.
- How to describe your app to AI: a prompt template
Write a clear AI app-builder prompt with a copyable template, a practical example, acceptance checks, and focused follow-up edits.
- How to turn a client brief into a mobile app prototype
Turn a client brief into a mobile app prototype with a copyable AppX prompt, a practical test checklist, and a focused client-feedback workflow.
- You can build your app with a coding agent. Here is why most founders should not.
Coding agents in the terminal are the best thing that happened to developers this decade. For a founder with no developer, they are a maze with no map. What the first week looks like with an agent, what it looks like with AppX, and when you should still pick the agent.
- Three emails a solo founder sends, and what came back
AppX now sends three short emails from me: when your first app is ready, when you built one and did not come back, and when you signed up and never started. 56 sent so far. Here is what they say and the mistake that means I cannot tell what came back.
- The 5-backtick fence: stopping prompt injection via Markdown
We ship user input into an LLM architect prompt every turn. A reviewer caught that a 4-backtick string from the user could close our 3-backtick fence and run arbitrary instructions on the model. The fix is one weird Markdown trick.
Ready to try your idea?
Start with a clear description. AppX will help you turn it into an app you can test.