Job app-error-and-empty-states-blank-screen · revised 11 October 2026
Fix a screen that goes blank or spins forever when data fails or is empty
One named screen shows a clear loading, empty, error-with-retry or partial-data state for each agreed failure instead of a blank page or endless spinner, proven with simulated responses.
You might be seeing
- The page turns completely white and the rest of the app disappears
- A loading spinner stays on screen after a request has failed
- A new user with no records sees an empty box or a broken layout instead of guidance
No passwords, keys, card details or admin invites needed to start.
What usually happened
The screen was built and tested for the case where data arrives in the expected shape. When a request fails, times out, returns nothing or returns a field in an unexpected shape, an unhandled error or a never-updated loading flag leaves the user with a blank page or endless spinner. Error boundaries do not catch every kind of failure, so each failure kind needs its own handling. The job covers one screen and a fixed set of failure cases.
Who it’s for: A founder or product owner whose app screen shows a white page, a spinner that never ends or a broken-looking list when the data service is slow, fails or returns nothing, and who gets complaints with no useful error to look at.
Usually starts when: Support reports of a blank screen, an error that appears only in the browser console, or a new customer with no data seeing a broken page.
The result: For one named screen, each agreed case (loading, success, empty, request failure, timeout, server error and a response missing an expected field) shows the agreed message and the right controls, never a blank page or endless spinner, and the rest of the app stays usable. You receive the change, a test per case and screenshots.
Check whether this job fits
These questions check whether this is one screen with a fixed set of failure cases. They need no access or code.
Checks you can run yourself
Look for the error behind a blank screen
Open the browser developer tools on the Console tab, reload the page and watch for a red message at the moment the screen goes blank. Also look at the Network tab for a failed or slow request.
Look for: The first red message, and the request that failed or never finished. Send the message text with personal data removed.
What you get
- A pull request with the changes and the tests
- A state table: each agreed case, the response used to simulate it, the screen shown and the test name
- Screenshots of each state at desktop and phone widths
- Reversal steps and any limits found
Included
- One screen, or one list-and-detail pair, in an existing React or Next.js application, and its data requests
- A list of seven agreed states and failure cases, written with you before work starts
- Handle each case in the component that owns the request, including failures in event handlers and background requests that error boundaries do not catch
- Add one error boundary around the screen where a rendering failure could still blank the page, with a retry action
- Write one test per case using simulated responses, and capture a screenshot per state at two widths
- Wording for each message, agreed with you, in plain language that tells the user what to do next
Not included
- Repairing or redesigning the data service or API behind the screen
- Application-wide error handling, monitoring or logging products
- Fixing the cause of a server error that sits in code we are not given
- New features, redesigns or changes to several screens
- Translating messages into several languages
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
For each of the seven agreed cases, the simulated response produces the agreed screen: a visible loading state, the success view, the empty guidance, a failure message with retry, a timeout message, a server-error message and a partial-data view when a field is missing.
Evidence: The state table and one named passing automated test per case.
In no agreed case is the page blank or does a loading indicator remain after the request has settled, and the rest of the app's navigation still works.
Evidence: Screenshots of each state at desktop and phone widths and a check that navigation works from each error state.
A rendering failure forced inside the screen shows the boundary's message with a retry, and the retry restores the screen when the cause is removed.
Evidence: The test that forces a render failure and the before and after screenshots.
The diff contains no secret, shows no raw error text to users and the existing tests still pass.
Evidence: The changed-file list, a secret scan of the diff and the test results.
Sign-off. You or your authorised maintainer review the state table and screenshots, try the failure cases on the copy, sign off in writing and merge. Payment follows sign-off.
If it fails. If any agreed case does not pass its test, you do not pay for this fixed scope. If a case cannot be handled without changing the data service or redesigning the screen, we explain what we found and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- The app is React or Next.js and the screen can run with simulated responses and no real customer data
- You can describe the data the screen shows and the failures you worry about
- The code can be inspected through an agreed company-controlled route after scope is agreed
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The screen cannot run without live data or credentials
- The failures are all caused by a faulty service we cannot see or change
- The screen is generated by a tool whose output you cannot edit
- Handling the cases would mean redesigning the screen
What could go wrong
Before merge, closing the pull request leaves the screen unchanged. After merge, your maintainer can revert the commit. The tests can be removed on their own without affecting the handling.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An error is swallowed and the screen looks fine while data is missing. | Each failure case shows a visible message, and the tests assert the message, not only that nothing crashed. |
| Error messages reveal technical or personal details. | Messages are written in plain words and the raw error stays out of the interface; the reviewer checks them. |
| A retry action repeats a request that should not be repeated. | Retry is offered only for safe read requests, and any writing request is handled separately and agreed with you. |
An independent reviewer tries two failure cases that were not on the list, checks that error text is useful and contains nothing sensitive, and checks the diff. Your maintainer reviews and merges.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- React's documentation explains error boundaries and what they do not catch, so a developer can add one without paying anyone. react.dev
- Next.js documents expected errors, uncaught exceptions and its error file convention. nextjs.org
Questions
Will this fix the service that is failing?
No. It makes the screen behave properly when the service fails. If the service fails often, that needs its own repair.
Is an error boundary enough?
No. React says error boundaries do not catch errors in event handlers or asynchronous code. Each failure kind needs its own handling, which is what the seven cases cover.
Can you do the whole app?
This job covers one screen. A project covers the main flows of the app together.
Do I need to supply live responses?
No. We use simulated responses and synthetic data. A redacted example of a failing response helps.
Send an enquiry
Send us
- The screen, what data it shows and what you see when it fails
- The framework and its version if known, and how the data is requested
- Any support reports or error text you have, with personal details removed
- Do not send credentials, customer data, source code or an access invitation in the first enquiry
Later, once you agree
- The source through an agreed company-controlled route, with a branch for the pull request
- Run instructions and a way to simulate responses, or example responses with synthetic data
- Your wording preferences and the agreed list of seven cases
- The name of the person who reviews and merges
You own the app, its data and its service. We work on a branch through a company-controlled identity, never a personal login, with simulated responses and synthetic data. Your team deploys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “app-error-and-empty-states-blank-screen” as the subject.