Glide (free plan) – QR code single-use per user + user-specific access

Hello,
I’m looking for help to finalize a system on Glide (free plan only).

:backhand_index_pointing_right: Level: beginner
:backhand_index_pointing_right: Goal: simple, reliable and easy-to-reproduce solution

1/ My need
Here is the full workflow:

  • I sell access physically → each customer gets a unique code
  • Customer fills a Tally form (email + code)
  • I manually verify:
  • code exists :white_check_mark:
  • code not already used :cross_mark:
  • I send a personal Glide link to the customer
  • Inside the app:
  • each customer has private access
  • they can see only their own modules (QR codes)
  • they can track which modules are used or still available
  • modules are the same for all users
  • Customer chooses a module and goes to a trainer/partner
  • The trainer scans the QR code:
  • if valid → accepted :white_check_mark:
  • if already used → rejected :cross_mark:
    :warning: Each QR code must be usable only once per customer

2/ Expected result
When the QR code is scanned:

  • If module not used → validation OK + mark as used
  • If module already used → show message “Already validated” + block

3/ User access (major issue)
I don’t understand how to:

  • Generate a unique link for each participant
  • Make sure each user sees only their own modules
  • Restrict access properly (user-specific data)
    :backhand_index_pointing_right: Looking for a simple solution compatible with free plan

4/ QR codes (major issue)
I also don’t know how to:

  • Create QR codes for each module
  • Store them (Glide Tables or elsewhere?)
  • Display them inside Glide
  • Link QR code ↔ module ↔ participant
    :backhand_index_pointing_right: Preferably without paid external tools

5/ Constraints

  • Glide free plan only
  • Glide Tables only (no Google Sheets)
  • No automations
  • Prefer to avoid Lookup / Rollup (or very simple explanation)

6/ What I’m looking for
:backhand_index_pointing_right: A clear step-by-step solution, including:

  • Exact table structure (names + columns + types)
  • User access / data filtering
  • How to generate or integrate QR codes
  • How to create the user access link
  • How to check “already used”
  • How to block second validation
  • Button / action / scan configuration
  • How to display error message
    :backhand_index_pointing_right: Even a simple workaround is fine if it works 100% on free plan

7/ Main blockers
I don’t understand:

  • How to technically prevent double validation
  • How to manage user-specific access
  • How to create and connect QR codes
  • Where to store the data (tables / columns)

Thanks a lot for your help :folded_hands:

You cannot publish apps under the Free plan, so if that is a main constraint for you, your other concerns are not worth considering.

Hello @Jeff_Hager ,
Thank you for your reply.
I understand your point about the limitations of the free plan. However, my goal is not to publish a fully scalable or commercial app at this stage, but rather to build a simple and functional prototype to validate my system.
I am a beginner and I have been trying for several weeks to implement this logic on my own, but I am currently blocked on the technical setup (especially user access, QR code handling, and preventing duplicate validation).
So my question is more about feasibility at a basic level:
:backhand_index_pointing_right: Is it technically possible, even with a workaround, to:
allow a user to access their own view (even in a simple way),
display QR codes,
and ensure that each QR code can only be validated once per user,
using only Glide Tables and the free plan?
I am not looking for a production-ready solution, just something simple that works reliably for a small number of users.
If the answer is strictly no, I understand.
But if there is even a basic workaround, I would really appreciate some guidance or direction.
Thank you for your time.

If you need to stay on the free plan, then the answer is no. On the free plan, Glide doesn’t let you publish an app in a way that people can log in, so your users wouldn’t be able to access the app to check anything.

Hello,

Thank you all for your previous responses.

They helped me better understand the limitations of the platform and pushed me to rethink my approach. I am still a beginner, and I continue to face technical difficulties, so I would still really appreciate any guidance.

I have now simplified my concept for a prototype.

Updated approach (simplified prototype) =>
Instead of using one shared QR code per module for all users, I switched to a simpler workaround :

  • Each client will have their own set of QR codes per module
  • Example: 5 modules → each client has 5 unique QR codes
  • All QR codes still point to the same module content
  • Each QR code has a status field: “unused / used”
  • When scanned by a partner, the QR is either validated or rejected depending on its status

This avoids the need for user login or individual app access while still allowing basic tracking and preventing reuse.

Partner role clarification =>

Partners do not need any app access or account.
They simply scan the QR code, and the system shows :

  • VALID (if unused)
  • ALREADY USED (if already scanned)

My question =>

Is this approach feasible as a simple prototype within Glide (free plan), or are there still technical limitations I should be aware of ?

I am not looking for a scalable production system at this stage, only a working prototype to validate the logic.

Any feedback or correction would be highly appreciated.

Thank you in advance for your time and help.

Jeff and Thinh have already answered, I’ll simply reiterate. Let’s focus on the term “publish”. In this context, “publish” means your app is accessible by users. Accessible on their phones, on their computers, in browsers.

On the the free plan, an app cannot be published. On the free plan, an app can only be edited by its editor/creator (you), the app cannot be accessed by any other user.

On the free plan, no it is not technically possible, even with a workaround. On the free plan, you cannot allow a user to access anything, period.

The limitations are not technical. The limitations are related to the nature of the plan. Your approach is not feasible on the free plan.