I built TagIn around a practical question: how do I keep the journey from registration to arrival connected, while giving the team on the ground a clear way to operate? A registration form is one part of that journey. Approval, credentials, badges, check-in and access to individual experiences all need to agree with it.

Why I started with the whole journey

My work sits between event technology and software development. When I design an event system, I think about both the person completing a form and the operator making a decision at the entrance. I wanted TagIn to give those two sides a shared foundation, with the organizing team able to configure the experience before the doors open.

That led me to a bilingual attendee operations platform: an organizer workspace, public registration journeys, QR credentials, badge preparation and check-in tools. I kept the scope focused on the work of an event rather than trying to turn the first version into every possible event-management service.

One person, an event, several experiences

I organized the system around Organization, Event and Experience. A contact belongs to an organization; a registration connects that contact to an event. Workshops, lounges and sessions can then have their own participation rules without creating a disconnected attendee record for each activity.

  1. Organization

    The team’s workspace, contacts, reusable templates and permissions.

  2. Event

    The registration journey, invitations, credentials, badges and arrival record.

  3. Experience

    A session or activity with its own schedule, approval, optional capacity and access rules.

An approved place in an experience and an approved event registration are different decisions. I kept that distinction explicit. A manual request can wait for review without consuming a capacity slot, while approved experience participation reserves one. Access still depends on the parent registration and the applicable gate rules.

TagIn Experiences and access gates for the synthetic QA Connected Summit event
The actual Experiences and gates workspace. The event, locations and capacity shown are synthetic examples, not a client deployment or measured capacity claim.

Registration that belongs to the event

I wanted organizers to shape the information they collect instead of adapting every event to one fixed form. TagIn supports editable fields, conditional questions, translated labels, sections and form artwork. Organization templates can be reused, but each new event or experience receives an independent copy so a later template edit does not unexpectedly change an existing registration journey.

Branding follows the same principle. TagIn’s Connected Identity belongs to the organizer workspace. Public attendee pages use the event’s configured identity, with organization defaults where appropriate. The software supports the event rather than making every attendee journey look like the platform.

TagIn registration form editor and preview using synthetic event data
The running form editor with reusable templates and an attendee preview. This is an existing product capture with synthetic data.

Keeping credentials, arrival and access separate

I did not want a single “checked in” flag to carry every operational decision. TagIn keeps registration approval, credential validity, event arrival, badge generation and experience access separate. A guest can have a valid event credential and still lack permission for a particular workshop; printing a badge should not silently record an arrival.

The QR credential uses an opaque, event-specific value rather than placing personal details inside the code. Operators can scan or enter it manually, and gates can allow repeat entry or one-time access. Printable badges and an emergency attendance list give the team another way to prepare, while the system retains a record of the decisions it makes.

Preparing for a connection that may disappear

I designed offline operation as a preparation step. While connected, an authorized operator prepares the device with the event data and selected operational assets it needs. IndexedDB stores that package and a durable action queue; the service worker keeps the application shell available. Private API responses and arbitrary uploads are not swept into a general browser cache.

Every queued action keeps its original identity, time and payload through a reload or retry. When the connection returns, the server checks current permissions and eligibility and reconciles the action. Repeating the same action returns its recorded result instead of creating a second arrival or registration.

I also made the limit visible: offline decisions are provisional. Another station may have recorded an arrival or revoked a credential since this device prepared its data. TagIn shows queued work and conflicts so an operator can see what still needs review. Separate disconnected devices do not share a live consensus.

TagIn offline check-in with a provisional result and one queued synthetic scan
A prepared device showing a provisional offline result, queued work and synchronization history. All names and references are synthetic. This image is not evidence of a live venue or physical scanner test.

Arabic and English are part of the workflow

I treated Arabic and English as part of the product structure. Operator screens, registration journeys, form labels, communication templates and badge typography support both languages. Arabic uses right-to-left layout, while identifiers and brand artwork remain readable in their own direction. A person can enter their name in one language; the workflow does not require duplicate Arabic and English identities.

The engineering behind the interface

I chose a React and TypeScript interface with a Django API and a relational data model. The API owns tenant permissions, registration rules, approval, capacity and replay decisions. The browser handles interaction and explicitly prepared offline work. SQLite supports local development; PostgreSQL is the hosted database target.

Keeping those responsibilities clear matters to me. Hiding a button is not authorization, and a prepared browser snapshot is not the final authority for access. Organization and event boundaries have to remain enforceable on the server, including when a device returns with work it completed while disconnected.

What I can show today

TagIn now has a working foundation covering registration, experiences, QR credentials, badges, check-in and prepared offline workflows. The project’s verification records include PostgreSQL concurrency checks, browser sessions with the network actually disabled, replay regressions and inspection of generated badge PDFs. Those records describe specific tested behavior, not a promise of unlimited capacity or zero downtime.

Hosted rollout remains a separate step: production infrastructure, email delivery, venue load, backups and physical camera or printer operation need their own validation. The screenshots here are actual software captures using synthetic events and attendees; they show the product without exposing operational guest data.

For me, TagIn is a way to bring system automation closer to on-ground execution. I want the team to know what has been approved, what has happened, what can happen next and what still needs a decision. That clarity is the product I am building through Pixel Pro Lab.