An application's architecture as a building: hall, kitchen, store cupboard, freezer

An application's architecture as a building: hall, kitchen, store cupboard, freezer

Assembling an application 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 by which the structure reads without any programming.

Assembling an application 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 by which the structure reads without any programming.

You assembled it and do not understand what you assembled

Vibe coding is the most requested subject in my survey: 53.2%, first place.

And the most common complaint among those who tried it: it works but it is unclear how. Something happens inside, data sits somewhere, something gets sent somewhere. Opening it up and working it out is frightening; showing a client is more frightening still.

Selling something you do not understand genuinely will not do. The client will ask one clarifying question and the conversation will end.

But answering his questions does not require becoming a programmer. It requires a scheme by which you understand what sits where. Here is the one I use.

A building with four rooms

Any application, site or bot is built the same way. Four zones, each with its own job.

The hall — what the visitor sees

The screen, buttons, forms, text. 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's chat.

The client's question you can now answer: "how will this look on a phone?" — that is a question about the hall, and it is solved in the hall without touching anything inside.

The kitchen — where the work happens

The logic. What happens when a person 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 are made. If an application behaves wrongly, it has to be fixed here rather than in the hall.

The client's question: "could there be a discount when someone orders more than three?" — that is the kitchen.

The store cupboard — where the data sits

The base: enquiries, users, products, history. Everything that must survive after the person closes the tab.

What matters here: the store cupboard is the most valuable thing in the project. An interface is redone in an evening, logic is rewritten, but lost data does not come back.

The client's question: "where do the enquiries land and will they get lost?" — the store cupboard. And that is the question you have to be able to answer precisely, because his real fear sits behind it.

The freezer — what rarely changes but is needed

Settings, access keys, reference data, static material. It sits 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 is labelled: which room it belongs to. Literally as a comment in a file or a line in your description.

Why that is needed when a model writes the code:

You can come back. A month later you open the project and understand what is where in a minute rather than 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 correction. Not "make it work" but "change the discount rule in the kitchen, do not touch the hall". A model given a precise address corrects precisely. A model given "fix it" rewrites half the project and breaks what was working.

The last point is the main practical gain. Most problems with vibe coding arise not during assembly but at the second or third correction, 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 will a change cost?" Ask what exactly needs changing and identify the room. A correction 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?" The question is almost always about the store cupboard and the freezer: will the data be lost and will credentials leak. Answer about those two zones specifically rather than "it is all secure".

"What if I want to add payments later?" That is the kitchen plus the freezer. Say it honestly: it can be added, but it is separate work, because it touches two zones and requires testing.

Somebody who answers by address reads as somebody who understands his product — even if a model wrote the code for him. 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.

Assembled confidently: landing pages and multi-page sites, simple internal tools — calculators, forms, trackers, prototypes for showing an idea, small applications for yourself and your team.

Requires somebody who understands the consequences: anything working with payments, personal data or a large number of users.

Not assembled: high-load products, complex integrations with other people's systems, anything where the cost of a failure is high.

And the most common trap: a working prototype and a product that can go into service are different things. Between them lie testing, behaviour on errors, and the fact that somebody has to maintain it.

What to check before delivery

Four tests, one per 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 invalid data, on a double submission, with no connection.

The store cupboard: where the enquiries actually land, whether a notification arrives, whether they can be exported.

The freezer: whether access keys are sitting somewhere visible.

The last point is checked least often, and it is the only one of the four that can cost money rather than reputation.

What the platform offers for app architecture

Site templates — 343 ready prompts for generating animated sites. Each card is a thoroughly worked brief: structure, typography, colours, animation behaviour on hover and scroll. On average around 10 000 characters, the most detailed up to 75 000.

The prompts are written for an ordinary stack and are not tied to a specific service: they paste into any environment that can write code. The preview is visible before launch, so you know what you will get.

Plus plan.

Skills for Claude Code — over 10 000. Not prompts but chains of agents with the task divided into parts. The catalogue is open to everyone, the files come with Basic, advanced ones with Creator+.

The "Engineers" category 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 most recent project — the one a model assembled — 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. Two things usually emerge: half the files are identified immediately, and for the rest you now know which specific question to ask the model.

From that moment you have not "assembled something unclear". You understand the structure — and that is enough to sell it.

How to understand a structure without reading code

The four-room scheme is your map. There is a tool that fills it in.

The skill “Architecture diagram analysis” (advanced: Creator and above, or a one-off $9, or 1000 XP): you upload an image of a block diagram or an architectural drawing and get a structured breakdown — components, links, flow 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.

Where this is studied

The express course “Claude: from the first prompt to your own library of mega-abilities”, $9, Creator plan and above — structured prompts with XML tags as the frame of a task, for business tasks.

The “VIBE CODING” course, Creator plan — assembling an application without writing code by hand, but with an understanding of where everything sits.

The Application interfaces section, Plus plan — ready prompts for UI: dashboards, account areas, mobile screens. That is the same "hall, kitchen, store cupboard" principle, already sorted by somebody: you can see which rooms an application usually consists of.

Assistants, Basic plan: Software engineer, Programming mentor — analysing decisions and explaining why this way rather than another. Bot architect — if the application is conversational.

And the next step if you want to go deeper

The skill “Code base knowledge and architecture graph” (advanced) builds an interactive map of your project: components, dependencies, links. And “Deep breakdown of a module or function” explains the role of a specific file in the architecture and the data flow.

What that gives for this article's subject. An agent that sees your whole project can explain its structure better than any diagram — because it reads the code rather than a description.

Both skills are advanced: Creator and above, or a one-off $9, or 1000 XP.

What to take on the platform for this task

What to read next

From prototype to product — what gets added when users arrive.

Why a project falls apart at the third correction — how to correct precisely rather than blindly.

What vibe coding is — the general picture and the limits.

What sells from what you assemble — eight formats with prices.

Skills for Claude Code — the full guide to skills.

Also on AI SKILLS