What should the first version remember?
Describe one action from screen to saved record. For a repair tracker, ask for a form that accepts a request and a list where staff can find it afterward. Anything’s database guide describes a separate development database and a production database. Publishing can copy the table structure while keeping test records separate.
What becomes public when you publish?
A web publish gets an address anyone with the link can visit, so decide what needs sign-in before sharing. Mobile publishing has store testing steps. If the phone app uses a database or server feature, check whether the web and backend also need to be published for that build.
What should you price before you start?
The current subscription guide says starting new generations requires a paid plan and credits refill on the billing date. Compare the allowance for building with any connected service bills. Check the plan for app-store publishing or a custom domain if either is part of your release.
How do you keep the code and the data?
Download the project source from the Code tab. The database viewer has a separate export from the code download, with one file for development data and one for production data. Label the files clearly, then list any accounts, uploads and integrations another host would need.
How would you spot a test request in the live list?
Draw a repair request called “Loose handle” in development and leave the live list blank. Plan what you expect to see after a release.
- Mark the structureDraw a request table in each environment with matching fields for the title and status.
- Mark the recordsLeave the made-up request in development. Show the empty live list before the first real request.
- Trace the data changeIf a later release removes the status field, note which live information could disappear and who needs to approve that change.