Loading, Error, and Empty States:What AI Apps Forget
Loading, error, and empty states are the 3 states AI-built apps forget — and why they look broken 40% of the time. How to make yours feel like a product.
Loading, error and empty states are the three that AI-built apps forget: every screen has four states — loading, error, empty, and success — and most AI-built products only handle the last one. That is why they feel like prototypes. Fix the three forgotten states and your app instantly feels like something people would pay for.
I can tell within ten seconds whether someone shipped their app straight out of an AI coding session. I open it and see "Loading..." as plain text. An error takes down the entire page. Empty screens show nothing but whitespace. The features work. The product still feels broken.
The four states every screen has: loading, error and empty states, plus success
When your app fetches data — and almost every screen fetches data — four things can happen. The data is on its way. Something went wrong. There is no data yet. Or the data arrived and everything is fine. Most builders design only for the happy ending, because that is the state they see while building. Then their app looks broken 40% of the time, because real users spend real time in the other three states.
| State | When users see it | Prototype version | Product version |
|---|---|---|---|
| Loading | Every page load, 2–5 seconds | "Loading..." as plain text | A skeleton preview of the content |
| Error | Network drops, server hiccups | A raw error code, or a blank crash | A plain-language message with a retry button |
| Empty | First use, no search matches | Whitespace — looks broken | A friendly nudge toward the next step |
| Success | Everything worked | Built | Built |
Users judge your product by the state they are in right now, not by the one you designed for. Loading takes 2–5 seconds per page load. First-time users always land on an empty screen. Networks fail. If those moments look bad, your product looks unprofessional — no matter how good the features are.
Loading states: skeletons beat spinners
The plain-text "Loading..." fails twice. It looks terrible, and the layout jumps when the real content arrives. The fix is a skeleton: gray, gently pulsing placeholder shapes that match the layout of the content to come. A list of five cards loads behind five gray card outlines. When the data lands, it slots into the exact space the skeleton was holding.
Skeletons are my secret weapon. They make the app feel 2x faster even when it is not, because people perceive waiting differently when they can see the shape of what is coming. This is UX psychology, not performance optimisation — and it costs you nothing but a request to your AI.
The simple rule: use a small spinner for quick actions like a button press that takes under a second, and a skeleton for anything that loads a page or a list. Building a skeleton is a formula, not a design task: copy the layout of the real component, replace text with gray rectangles and images with gray circles, keep the same spacing, add a pulse animation. AI can do this in one pass if you ask for it.
Error states: helpful, not scary
The default error state in an AI-built app is a raw technical message — or worse, a completely broken page. Both terrify users. A good error state does three jobs: it says what happened in human language ("We couldn't load your applications"), it says what to do next ("Check your connection and try again"), and it offers a way to recover — a retry button, a back button, a support link.
There is one more layer most builders skip: a safety net around the whole page, so that when one component crashes, it shows a polite "something went wrong" card instead of taking the entire screen down with it. Ask your AI for an "error boundary" and you get exactly that — one crashing widget no longer kills the page.
Never show users an error code as the headline. Never lose the work they had in progress. And always give them a button to press — helplessness is what makes errors feel catastrophic.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Empty states: turn a dead end into a next step
The empty state is the most neglected of the three, and the most valuable. Every single new user starts on an empty screen. If that screen is blank, they assume the product is broken and leave. If it welcomes them and points at the next action, it becomes onboarding.
A good empty state has three parts: a clear visual that represents what is missing, a helpful title that explains what would live here ("No applications yet"), and a next step ("Share your application link"). Tone matters — "Get started" invites, "Nothing here" deflates.
Empty states should also change with context. No search results deserves "Nothing matches your search — try different keywords" and a button to clear filters. A first-time user deserves a welcome and a pointer to their first action. Same mechanism, different message — and each one turns a moment of confusion into a moment of guidance.
How to make AI build all four states, every time
Here is the part that makes this practical for a non-technical founder: you do not need to build any of this by hand. You need to demand it. When you ask AI for a new screen, most people describe only the success state — so that is all they get. Instead, spell out the states in the request:
Create the applications list screen. Loading: show a skeleton with five placeholder cards. Error: show a friendly message with a retry button. Empty: show a helpful message and a button to create the first application. Success: display the data. Follow the same pattern as the existing screens.
Five extra lines. The AI generates all four states automatically, and once one screen has the pattern, you can point at it as the reference for every screen after. This is the core skill of building with AI: you set the standard, AI implements it. The states everyone forgets are only forgotten because nobody asked.
Handling the three forgotten states is half of what makes an app feel real. The other half is consistency — every screen looking like it belongs to the same product. That is a system, not a talent, and it is exactly what design tokens and a component library give you.
12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →Frequently asked questions
What are loading, error, and empty states?
They are the three situations every screen can be in besides "everything worked": data is still arriving, something failed, or there is no data yet. Users hit all three constantly — every page load, every network hiccup, every first visit — so a product that only designs the success state looks broken a large share of the time.
Do skeleton screens really make an app feel faster?
Yes — perceived speed improves even when actual speed doesn't. Content-shaped placeholders make waiting feel roughly 2x shorter than a generic spinner, because users can see the shape of what is coming and the layout doesn't jump when it arrives.
What makes a good empty state?
Three things: a visual that shows what is missing, a title that explains what would appear here, and a button that leads to the next action. The best empty states double as onboarding — every new user starts on one, so treat it as your welcome mat, not a dead end.
Will AI add these states automatically?
Only if you ask. AI builds what you describe, and most people describe only the happy path. Add four lines to every screen request — loading, error, empty, success — and point at one well-built screen as the pattern. From then on, every new screen ships with all four states.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.