Your App Is Two Designs. You're Only Doing One.

Vibe coding turned everyone into a visual designer. Prompt, look, adjust, repeat. Taste became the skill, and honestly, watching people who never wrote code ship beautiful things is my favorite part of this era.

But every app you admire is actually two designs. There's the one you see: the layout, the colors, the flow. And there's the one you don't: what happens when a user pays, what runs every night at 2am, who is allowed to see which data, what talks to Stripe so your browser doesn't have to. The visual part and the system that supports it.

Most builders only ever design the first one. Not because the second is hard anymore, it genuinely isn't. Because nobody handed them the vocabulary for it.

Vocabulary is not for prompting. It's for thinking.

There are plenty of posts and skills out there teaching you the "right words" to prompt with, and they help. But I think they undersell what the words are actually for.

When you know the names of the parts, something shifts in your head: you stop seeing your app as one magic blob the AI made for you, and start seeing it as a small number of parts, each with a job, that you are allowed to combine. That notion, "I am building with parts of a system," is the difference between decorating a facade and designing a building. It's what lets you build better, more complex things without writing a line of code, because now you can ask for them.

And this is why I keep pointing builders at Supabase, whether it's under their Lovable app or on its own. Not just because it's good infrastructure. Because it's the clearest inventory I know of the parts a real product needs. Learn its vocabulary and you've learned what apps are made of.

The parts, in plain language

Six parts. Each one is a word you've probably scrolled past, a plain explanation, and the thing it lets you design.

A database that knows who's asking. Postgres stores your data, and Row Level Security (RLS) attaches small rules to it that run on every query: who can see this row, who can change it. It's less a spreadsheet and more a floor plan: which rooms exist and who each door opens for. What it lets you design: "users only see their own entries," "free accounts keep 30 days, Pro keeps everything," "removing a teammate revokes their access instantly." Your pricing page, written as rules.

Auth, which is bigger than the login box. Auth is your app's concept of identity: who this person is, how they proved it (Google, email, a magic link), and the session token that carries that proof around. The login screen is just the door. Identity is the whole hallway behind it. What it lets you design: invite-only areas, teams, roles, "sign in with the account your users already have," account deletion that actually deletes.

Storage with rules. Files (avatars, PDFs, uploads) live in buckets, and access to them is governed by the same policy system as your data. A file isn't just hosted, it obeys the floor plan too. What it lets you design: private user folders, paid downloads, share links that expire, "only the team can see the contract."

Server code: things that happen away from the browser. Edge functions and server routes are small pieces of your app that run on a server, where secrets are safe and outside services can reach you. Anything involving money, API keys, or another platform belongs here, not in the user's browser. What it lets you design: Stripe payments, webhooks, AI features with protected keys, an API a future mobile app can call.

Cron: things that happen on schedule. A cron job is a task your backend runs on its own clock: every night, every Friday, every hour. No user needs to be online. Your app gets a pulse. What it lets you design: weekly digest emails, automatic cleanups, reports that write themselves, reminders that fire while you sleep.

Realtime: things that happen live. Realtime pushes changes to everyone who's looking, the moment they happen, instead of waiting for a refresh. And who gets to listen is, again, a policy. What it lets you design: live dashboards, collaborative boards, presence ("Ana is typing..."), notifications that arrive now.

Features are combinations

Here's the payoff, and the moment this clicks for builders I work with. The complex features you admire in other products are almost never a seventh secret part. They're two or three of these six, combined:

• "Send my users a weekly summary" = cron + server code + a database query.
• "A live board my whole team can edit" = realtime + RLS.
• "Free vs Pro plans" = one policy on your data.
• "Accept payments" = server code + a webhook + one table.
• "Clients upload documents only their manager can see" = storage + policies + roles.

Once you see features as combinations, the ceiling on what you can build stops being your technical skill. It becomes your imagination times six parts. And your AI agent can assemble any of these combinations from a clear sentence. The sentence is your job. The parts are the vocabulary the sentence is made of.

Design the system like you design the screen

You already know how to iterate on the visual half: prompt, look, adjust. The system half deserves the same deliberate pass, and it's five questions, in plain language, before you build:

1. Who uses this, and what does each person own? (That's your data and its floor plan.)
2. What should happen even when nobody is online? (That's your schedule.)
3. What needs to happen live, between users? (That's realtime.)
4. What touches money, secrets, or outside services? (That's server code.)
5. What files exist, and who can see each one? (That's storage.)

Answer those five in sentences and you have designed a system, whether or not you ever call it that. Hand the sentences to your agent and it will pick the parts. It's genuinely that direct now.

And while you build, one rule closes the vocabulary loop for good. Paste this into your project's knowledge, once:

Rule for this project: every time a new technical concept
appears (RLS, cron, edge function, egress, migration, anything),
explain it in two plain sentences before applying any change.
Never assume I know the term.

The AI knows what every one of these words means. It just doesn't know you don't, unless you tell it. With that rule, every build session quietly becomes a systems class you never had to sign up for.

The other half of the craft

I see the opposite every week in support: builders blocked not by difficulty but by vocabulary. Someone loses days to an error word they'd never met. Someone thinks a healthy usage chart means their database is being shut off. Someone never builds the feature that was one sentence away, because nobody told them that room existed. The tool could do what they needed. They didn't know they could ask, or what to call it.

That gap doesn't close by learning to code. It closes by learning the names of the parts, and we just did: data with a floor plan, identity, files with rules, code that runs away from the browser, a schedule, a live wire. Six words.

Taste got you the screen. The vocabulary gets you the system. Design both, and what you ship stops being a pretty demo and starts being a product.

If you sketch your next app's five system sentences and want a second pair of eyes, send them my way. Reading those is genuinely one of my favorite things to do.