AI can make something that looks finished in an afternoon. A few prompts, a nice-looking screen, a button that does something. It’s genuinely exciting, and I think it’s one of the best things to happen to designers in a long time.
But looking finished isn’t the same as working. And working for you isn’t the same as working for a thousand people at once.
I’ve spent the last year designing and building real software with AI coding agents: a walking game that’s live on the App Store, and a community app that a small group tests with me every week. Almost everything I learned that mattered, I learned after the prototype looked done.
The wall after the demo
Here’s a pattern I keep seeing. Someone builds a convincing prototype with AI. They show it to their leadership or investors, and it lands. They get the go-ahead, maybe even funding. That part is great.
Then real users show up, and the prototype starts doing things nobody planned for. It slows down. Someone sees data they shouldn’t. A phone does something a browser never did. And because they don’t know which questions to ask, they stop, and they pay someone a lot more to rebuild what they already “had.”
Going from a prototype to real, scalable software is a different story than building the prototype. That’s the story I want to tell, because designers are closer to being able to tell it than they think.
Figma isn’t going away. The bridge is getting built.
Designers aren’t abandoning Figma for code. Figma is still where we shape intent: what a thing should feel like, how it flows, what matters on the screen. What’s changing is what sits between the design file and the product.
At work, we designed our design system in Figma, then translated it into code: real components, built and documented in Storybook. Every component goes through a pull request that a developer reviews, alongside AI, before it’s merged. So we know the code underneath is solid, not just the way it looks. Now Claude can pull that front-end repo and see exactly how each piece is built: the spacing, the colors, the rules, all of it. So it doesn’t have to invent any of that every time we ask for something. It uses what’s already there, and everything stays consistent no matter which page we’re building or what we ask for. The point isn’t to skip design or skip engineering. We’re building faster, and we’re building it the right way: designed by designers, reviewed and tested by real developers, and used consistently by AI. That’s the difference between speed and slop.
Teams everywhere are wiring up their own versions of this: connecting their coding tools to their design tools so that design and code stop drifting apart. The designers who understand both sides of that bridge are going to be very useful.
What’s under the waterline
Every product has two halves. The front end is the UI: the screens, the buttons, everything people see and tap. That’s the part AI is great at, and it’s the part a demo shows.
The back end is everything that makes the UI actually work: the systems people never see. This is where most people get stuck, and not because it’s too hard. They just don’t know these systems exist, so they don’t know to ask for them. And AI builds what you ask for. If you never say who’s allowed to see something, it will make a guess, and it will sound confident about it.
You don’t need to know how to build these. You need to know they exist, what they do, and what to ask. Here’s the list I wish I’d had, with the lessons that taught me each one.
Database: where everything lives. Every person, group and message has to be stored somewhere, and someone has to decide what those things are and how they relate. That’s a design decision, not a technical one. Early on, one build treated a small group as if it were a whole ministry: right code, wrong idea.
Ask: “What are the things in my product, and how do they connect?”
Accounts: who someone is. Signing up, signing in, resetting a password, deleting an account. My walking game was rejected by the App Store partly because there was no way to delete an account and no way to play as a guest.
Ask: “How does someone get in, get back in, and get out for good?”
Permissions: what each person is allowed to see and do. This one has to be enforced on the server, not just in the UI. Early on, my app kept people out of private groups by hiding the button. But a hidden button isn’t a lock: anyone who knows how apps talk to their servers can skip the screen.
Ask: “Who can see this, who can change it, and is that checked on the server?”
Server logic: the rules that run off the device. What actually happens when someone taps a button, and what happens if it fails halfway through.
Ask: “What has to happen when someone does this, and what if it breaks in the middle?”
Live updates: things changing without a refresh. New messages appearing, counts going up, someone’s status changing.
Ask: “Does this need to update live, or is a refresh fine?”
Notifications and outside services: anything that leaves your system. Push notifications, emails, payments. None of them can be taken back. My app ran automated tests against the live system, and the tests cleaned up after themselves. But they had already sent notifications to real people’s phones.
Ask: “What leaves the system here, and what happens if it fires by mistake?”
File storage: photos, videos and uploads. They live somewhere different from the rest of your data, with their own limits and their own rules about who can see them.
Ask: “Where do uploads go, how big can they be, and who can open them?”
Hosting and compute: the actual machine. Everything runs on a real computer somewhere, and its processor and memory decide how fast your product feels. At one point, loading conversations in my app took 15 to 30 seconds. The database query took 79 milliseconds; the problem was the computer underneath it. It ran on one of the smallest servers Amazon Web Services offers, guaranteed only about 5% of one processor. And upgrading my plan didn’t change the machine. Those were two separate settings.
Ask: “What does this run on, and what happens when ten times more people show up?”
Scheduled jobs: things that happen when nobody is tapping anything. Reminders, cleanups, archiving old content. My app had an automatic job that archived past events, and another part of the app treated “archived” as “hidden.” So the calendar’s Past tab was always empty, and nobody had touched a thing.
Ask: “What happens automatically, and what else does it affect?”
Monitoring and keys: knowing when it breaks. Logs, alerts, and the access keys your product depends on. An access key I relied on quietly expired one day, and every tool that touched my database stopped working at once. On a side experiment, my alert checked whether the server was on, not whether the thing it ran was working, and it died silently for three weeks. Oh, and stopping a server isn’t the same as no longer paying for it.
Ask: “How will I know when this breaks, before my users tell me?”
None of this is glamorous, but all of it is the product. And every one of those questions is something a designer can ask.
AI can teach you, but you have to hit the wall
Here’s the part I find most hopeful. Every one of those lessons, AI helped me learn. When my app slowed down, I didn’t know what a “burst credit” was. I asked, I measured, and I worked through the possible causes one at a time with an agent until we found it.
But AI couldn’t have learned it for me. I understand compute now because my app got slow and I had to figure out why. I understand server-side permissions because I found a gate that only existed in the interface. You can read about these things, but you don’t really get them until you run into them.
That’s my case for building real things, not just prototypes. Ship something small that real people use. Let it break. Ask the agent why, and keep asking until you understand the answer. Every roadblock is a question you’ll know to ask next time, before it costs anyone money.
Where designers can go from here
I don’t think designers need to become backend engineers. But I think the most valuable designers in the next few years will understand the whole system well enough to make decisions in it:
- Know the shape of the stack. What lives on the device, what lives on the server, where the data is and who’s allowed to touch it.
- Design the states, not just the screens. Empty, loading, slow, offline, error, deleted. That’s where products earn trust.
- Treat your design system as code. When agents build from real components, your system becomes the guardrails.
- Ask what leaves the building. Notifications, emails, payments and anything else you can’t take back.
- Measure before you believe. “It’s fixed” means nothing until you’ve checked.
Anyone can make a demo now, and that’s a good thing. Building something people can rely on is still a craft. Designers who learn the rest of the iceberg are in a great position to own it.
Want to check your own app? I turned these ten systems into the Vibe Coding Checklist: ten yes-or-no questions, about two minutes, and a personal fix list with the exact prompt to give your AI for each gap.
Stuck on a fix? I do a few 1:1 sessions where you share your screen and I teach you how to check and fix it yourself.