Under the standard Appsheet pricing plans, each usage of your embedded app would be considered a user for billing purposes. So if you viewed the webpage with your app once then refreshed your browser, that would be considered two users for billing purposes. You can instead pay for Publisher Pro plan, which will reduce your bill if you expect more than five users a month.
Appsheet Subscription Plans
From the looks of this app, it is not designed to be used by customers but instead used by an employee to build orders for a customer, despite to misleading terminology. This is indicated to me by the fact that a list of all customers can be seen from the menu.
This app uses the traditional Order/Detail table relationship setup where a main parent record serves as the order and many child detail records/ line items are related to the parent record. While there is a bit more to the setup in this app, like 'blueprint' products and custom lists of selectable products per customer, the general idea of your public-facing app would be that no customer-generated records can be displayed within the app since there is no way to filter the records down to only the viewing customer's records without sign-in functionality.
To be clear, an order/detail setup means that for every quote, an Order record and one or more Detail records are being CREATED. This is not necessarily incompatible with an no-sign-in app, but is more complex than what is needed for a system that will not display the results of the relationship to the customer AFTER they create them, unless you are getting into quantities, which I dont think you are in your case.
Instead of an order/detail setup, I suggest having only a products (workshops) table and an order table. The customer would see a form to enter a new order record and on that form would be a field that is a EnumList of Refs to the Workshops table which would display to the customer as a multi-select checklist dropdown. Once they click save, they are taken to a successful submission screen that does not show them any details of their selections but does indicate to them to check their email. The Workshops table would be a normal, read-only table (not necessarily displayed to the user other than from the EnumList dropdown) and the orders table would have the 'Filter out all existing rows' setting set to true. This method would be substantially simpler than the demo app you found.
You could then build a second app using the same data sources for internal use only to edit the blueprint products and possibly take actions on or see a list of every order.
Hope that helps.
LinkedIn
Twitter
