Add a database
Let your app save and retrieve structured information such as bookings, profiles, and orders.
A database lets your app save structured information and retrieve it later. Use it for bookings, profiles, inventory, requests, or any journey where refreshing the page must not erase the result.
Model one customer journey
Start with the nouns a customer recognizes and only the fields needed for the first result. A booking journey might need:
- Service: name, duration, price, and whether it is available;
- Booking: its service, date, start time, customer details, and status.
State relationships as product behavior. One booking belongs to one service; a service can have many bookings. Two confirmed bookings must not claim the same time.
Avoid speculative fields. Dates need a time zone, money a currency, and statuses a defined set of values.
Plan, then build
Choose Plan and ask for the model before asking Ahamo to change the app:
Plan the data for a booking journey. A service has a name, duration, price, and active status. A booking refers to one service and stores its date, start time, customer name, email, and status. Identify required fields, define the valid statuses, and prevent two confirmed bookings for the same service and time. Do not build yet.
Review unclear names, unnecessary data, missing relationships, access rules, and how existing records continue to work.
When the plan is correct, approve it and build the complete save-and-read journey:
Build the approved booking model. Validate required details before saving. Save one booking only once, show its service, date, and time on confirmation, and show a useful error if the time is no longer available. Add an upcoming-bookings view that reads the saved records.
Refresh or reopen the bookings view to prove the app retrieves the stored result rather than repeating form values.
Inspect the result
Open Runtime and Data. In the data browser:
- select the data authority for the environment you tested;
- choose the booking table;
- find the safe test row;
- compare its service, date, time, and status with the app;
- try invalid input and confirm no misleading row is created.
The interface may report Development, Staging, or Production. Read its authority notice: data can be shared live or use protected, separate authorities. Publishing does not copy development rows to protected production data.
If no row appears, confirm the authority and reported success. Then check validation, filters, permissions, and the owning table before submitting again.
Verify the journey
Before relying on the feature, confirm:
- valid input creates exactly one record;
- refreshing retrieves the saved result;
- invalid input creates no partial record;
- an unrelated or signed-out user cannot read protected information;
- an unavailable save never appears successful.
Use fictional records. The data browser inspects results; it does not replace app validation or permissions.
Continue with inspecting tables and rows, or add sign-up and sign-in when records must belong to a person.