Your app accepts a form and shows the new item. But will another device see it? Will it still be there after an update? Can one customer accidentally open another customer's record?
Those are data questions, not design questions. Most products need three places: the browser for harmless preferences, a database for customer records, and file storage for uploads.
Which data belongs where?
| Example | Best home | Reason |
|---|---|---|
| Theme or dismissed tip | Browser storage | It is a preference on one device, not a business record |
| Customers, orders, projects | Database | The same information must appear after sign-out and on another device |
| Photos, PDFs, videos | File storage | Files need a separate place that keeps them after app updates |
Ask what would happen if the information disappeared. If a customer or the business would be harmed, do not keep the only copy in a browser or in the app's temporary memory.
What is the smallest record your product needs?
Start with the one action that must survive a restart. A feedback app needs to create and list feedback. A project tracker needs to create a project and change its status.
Write down each piece of information in plain language. Note who owns it, whether it is required, and whether every record needs a different value. Ask your coding AI to turn that list into the database structure. Avoid collecting information you do not need.
Why separate test data from customer data?
Use one database for experiments and another for real customers. These are often called the development and production databases. Test data should be safe to erase. A change to real customer data should be reviewed, written down, and repeatable.
A successful experiment is not a repeatable data change. Write down what changed before applying it to customer data.
When possible, use different private access keys for test data and real customer data. Let the live app do only the database actions its customers need.
How should the browser reach the database?
The browser should ask your app to save or load information. The app checks who signed in and whether the information is valid. Only then does it send the approved request to the database with a private key.
On JustDeploy, the app sends a secure web request to the database through the Query API. You do not need to set up a separate database address. Keep the Query API keys in the project's protected settings, never in code sent to the browser.
What happens when a save is repeated?
People double-click, and a slow network may try the same save again. The save may finish even when the success message never reaches the screen. Give payments, orders, invitations, and other one-time actions their own request number. If the action repeats, the app can return the first result instead of making a duplicate.
- Check the signed-in customer's permission before every change.
- Return a permanent record number after a successful save.
- Change only the intended record.
- Confirm the saved result before showing success.
- Never let the browser choose any part of the database it wants.
How do you replace sample data safely?
- List the records and fields the core journey needs.
- Create them in the development database.
- Connect one save-and-load flow at a time.
- Test a valid request, an empty one, a repeat, and a request from the wrong customer.
- Create the reviewed structure in production.
- Publish the app and repeat the tests at the live address.
Use a harmless test record, such as a project named Storage check. Sign out, sign back in, and look for the same record on a second device. Repeat after an approved app update. Do not use real customer details for this test.
Also open a private browsing window and use a second device. If the data disappears, some data is still stored only in that browser. If two customers see the same records, storage works but permissions do not.
When is customer data ready for launch?
You should be able to answer six questions:
- Where does each kind of data live?
- Who owns it?
- Who may change it?
- What happens if the same save runs twice?
- Does it survive a new release?
- How would you recover it?
Saving once is only the start. A live product needs data that lasts, stays private, and can be recovered.
What should you read next?
- File Uploads That Survive Refreshes and App Updates
- How to Add Login Without Exposing Customer Data
- Where Should API Keys Go?
Use the JustDeploy database guide when you are ready to create the production data structure.