App architecture as a building: hall, kitchen, store cupboard, freezer
Assembling an app in an evening works; explaining what came out does not. Selling something you do not understand is frightening, and rightly so. Below is a scheme of four rooms that lets you read a structure without programming.
Assembling an app in an evening works; explaining what came out does not. Selling something you do not understand is frightening, and rightly so. Below is a scheme of four rooms that lets you read a structure without programming.
---
You built it and do not understand what you built
Vibe coding is the most wanted subject in my survey: 53.2%, first place.
And the most frequent complaint from people who tried it: it works, but it is unclear how. Something happens inside, data sits somewhere, something gets sent somewhere. Opening it up is frightening; showing it to a client more so.
Selling something you do not understand genuinely is not on. A client will ask one clarifying question and the conversation will end.
But answering their questions does not require becoming a programmer. It requires a scheme by which you know what sits where. Here is the one I use.
A building with four rooms
Any application, website or bot is built the same way. Four zones, each with its own job.
The hall — what a visitor sees
The screen, the buttons, the forms, the copy. Everything a person interacts with.
What matters here: the hall stores nothing and decides nothing. It displays and passes on. A handsome hall with an empty kitchen is a mock-up rather than a product.
What belongs here in your project: the page, the interface, the bot chat.
The client question you can now answer: "how will this look on a phone?" is a hall question and gets solved in the hall, touching nothing inside.
The kitchen — where the work happens
The logic. What happens when somebody presses a button: where the data goes, what gets checked, what gets calculated, what gets sent.
What matters here: the kitchen is the only place where decisions get made. If the app behaves wrongly, that is where to fix it, not in the hall.
The client question: "could we give a discount on orders of more than three?" is the kitchen.
The store cupboard — where the data sits
The database: enquiries, users, products, history. Everything that has to survive somebody closing the tab.
What matters here: the store cupboard is the most valuable thing in the project. An interface gets redone in an evening, logic gets rewritten, and lost data does not come back.
The client question: "where do the enquiries land and can they get lost?" is the store cupboard. And that is the one you have to answer precisely, because their real fear is behind it.
The freezer — what rarely changes but is needed
Settings, access keys, reference data, static material. It sits there and waits, rarely touched.
What matters here: this is where things that must not be shown outside end up — credentials and keys. Their place is neither the hall nor the kitchen.
The labelling method
One habit that makes the whole scheme work.
Every piece of the project gets labelled with which room it belongs to. Literally as a comment in a file or a line in your description.
Why that matters when a model writes the code:
You can come back. A month later you open the project and understand where everything is in a minute instead of half an hour of reading.
You can explain. To a client, a contractor, the next person to work on it.
You can ask for a precise change. Not "make it work" but "change the discount rule in the kitchen, do not touch the hall". A model given an exact address makes an exact change. A model given "fix it" rewrites half the project and breaks what worked.
The last point is the main practical gain. Most problems with vibe coding arise not during the build but at the second or third revision, when every change breaks something else.
How to use this in conversation with a client
Three situations where the scheme settles the question.
"How much would a change cost?" Ask what exactly needs changing and identify the room. A change in the hall is hours. A change of logic in the kitchen is days. Rebuilding the store cupboard is a separate project. Now you have grounds for a range.
"Is this reliable?" That question is almost always about the store cupboard and the freezer: will the data get lost and will access leak. Answer about those two zones specifically rather than "it's all secure".
"What if I want to add payments later?" That is the kitchen plus the freezer. Say honestly: it can be added, but it is separate work, because it touches two zones and needs checking.
Somebody who answers by address reads as somebody who understands their product — even if a model wrote the code. And that is true: understanding a structure and being able to write syntax are different things.
Where vibe coding ends
An honest boundary, so you do not take on what you cannot deliver.
Builds confidently: landing pages and multi-page websites, simple internal tools — calculators, forms, trackers, prototypes for showing an idea, small applications for yourself and a team.
Needs somebody who understands the consequences: anything working with payments, personal data or large numbers of users.
Does not build: heavy-load products, complex integrations with other people's systems, anything where the cost of a failure is high.
And the most frequent trap: a working prototype and a product you can put into service are different things. Between them lie validation, behaviour on errors, and somebody having to maintain it.
What to check before delivery
Four tests, by room.
The hall: how it looks on a phone, what happens with an empty form, whether the text is readable.
The kitchen: what happens with wrong data, on a double submission, with no connection.
The store cupboard: where enquiries actually land, whether a notification arrives, whether they can be exported.
The freezer: whether access keys are sitting somewhere visible.
The last point gets checked least often, and it is the only one of the four that can cost money rather than reputation.
What is available on the platform
Website templates — 343 ready prompts for generating animated websites. Each card is a detailed brief: structure, typography, colours, how animation behaves on hover and scroll. Around 10 000 characters on average, the most detailed up to 75 000.
The prompts are written for a standard stack and are not tied to a particular service: they paste into any environment that can write code. The preview is visible before you run it — you know what you are getting.
The Plus plan.
Skills for Claude Code — more than 10 000. Not prompts but chains of agents where a task is split into parts. The catalogue is open to everyone, the files come with Basic, advanced ones with Creator+.
The engineering assistants — nine of them, including the bot architect and the programming mentor. From Basic.
Registration is free and opens three days of full Basic access.
Where to start today
One action. Open your last project — the one a model built — and sort it into the four rooms. Simply write on a sheet of paper what belongs to the hall, what to the kitchen, what to the store cupboard, what to the freezer.
Fifteen minutes. Usually two things emerge: half the files get identified immediately, and for the rest you now know the specific question to ask the model.
From that moment you are no longer somebody who "built something unclear". You understand the structure — and that is enough to sell.
---
How to understand a structure without reading code
The four-room scheme is your map. There is a tool that fills it in.
Qwen VLM for diagrams from the automations archive: you upload an image of a flow chart or an architecture drawing and get structured data — nodes, links, directions.
That works both ways: you read somebody else's diagram as a set of objects, and you can draw your own architecture by hand and turn it into data.
And the next step if you want to go deeper
Module 5, lesson 12 — installing an AI agent on your local machine. The lesson covers working with repositories, how to set programming tasks through an assistant even if you do not understand the subject, and how to build a Python bot published to a server.
What that gives for the subject of this article. An agent that sees your whole project can explain its structure better than any scheme — because it reads the code rather than a description.
Module 5 — Plus; Qwen VLM — N8N and Full.
---
What to read next
[From prototype to product](/en/blog/prototype-to-product) — what gets added once users arrive.
[Why a project falls apart at the third revision](/en/blog/spec-coding) — how to make precise changes rather than blind ones.
[What vibe coding is](/en/blog/what-is-vibecoding) — the general picture and the limits.
[What of this actually sells](/en/blog/what-sells-from-vibecoding) — eight formats with prices.
[Skills for Claude Code](/en/blog/claude-code-skills-guide) — the full guide to skills.