What it does

Attendees get a guide to the side events around Salesforce conferences, with every imported event checked by a person before it is listed. Hosts can claim their listing and run their own guest list, from RSVPs to QR check-in at the door. One codebase runs the web app and builds the iOS and Android apps, so each change is made once for all three.

The situation

Large Salesforce conferences come with many unofficial happy hours, dinners, and parties, announced on scattered company pages and lists. Attendees had no single reliable place to find them. Hosts of smaller events also lacked a simple way to take RSVPs, run an approval list or waitlist, message guests, and check people in at the door.

What was built

One Expo and React Native codebase runs as a web app and builds for iOS and Android, with a Python API and a MongoDB database behind it. The conference calendar comes from public event listings. Side events are gathered, checked by a person, and imported, each linking to the host’s own registration page, and a real host can claim its listing.

Hosts can take RSVPs in the app, run request-to-attend lists with their own questions, send updates to guests through the app, and scan signed QR passes at the door. Attendees can build a profile, swap contact details when both sides agree, message each other, and report or block other users.

AI tools helped write the code and find side events, and a person approved every event before import. The web app is live, and the iOS app is on the App Store.

How it works

  1. Sync the conference calendar

    Once a day a background job reads two public event listings: Salesforce’s own events page and an independent community calendar. It removes duplicates by name and date. A new visitor lands on the conference an admin has pinned, or else the next one that has approved events.

  2. Import side events

    Side events found in public listings are de-duplicated and link-checked, and dead links are rejected. A person reviews the list before import. Each imported event points to the host’s own registration page and stores no organizer email. Imports use a narrow access key that can do nothing else, and running an import again updates events without creating duplicates.

  3. Hand listings to real hosts

    Imported events carry a claim link. A claim is approved automatically only when the person signed in with Google or Apple using an email on the same domain as the event’s registration page. Every other claim goes to a person for review.

  4. Browse and share

    Attendees browse a feed and a map with grouped pins, on the web or in the app. Each event has a share link that previews as that event.

  5. RSVP, request, or click out

    Each event uses one of three sign-up types: an RSVP in the app, a request to attend that the host approves, or a link to the host’s own page. A request checks the attendee’s profile and consent and the answers to the host’s questions. A full event never turns anyone away; the host gets a notice as it fills.

  6. Host reviews and messages guests

    The host marks each request as approved, waitlisted, pending, or not selected. The attendee gets an in-app notice and a push notification, and each change is logged. Host updates go out from the server, in the app and by email, at most three a day. Sending one does not show the host the guests’ email addresses.

  7. Check in at the door

    Each guest’s schedule shows a signed QR pass tied to them, the event, and an expiry time. The host scans it, and the server checks the signature, the expiry, the event, and the guest list before marking the guest checked in. Scanning a pass twice changes nothing.

How it is tested

The API has a Python test suite: fast unit tests that need no database, and integration tests that run against a fresh, seeded database. The app has unit tests and browser tests that click through it end to end. GitHub Actions runs the API tests and the app’s unit tests each time code changes on the main branch and on every proposed change, along with a dependency security audit and a test build of the web app. Railway, which hosts the API and the web app, skips any release whose checks failed.

A nightly run repeats the integration tests, runs the browser tests, tests the sign-in flows against a stand-in provider, and checks that the live site responds and is running the latest code. In August 2026, a functional and visual pass of the app, run with browser tests on three browsers and an Android emulator, found defects that were then fixed.

Tools, status, and who built it

Tools

Expo, React Native, React, Python, FastAPI, MongoDB, MapLibre, Railway, Postmark, Sentry, GitHub Actions, pytest, Jest, Playwright

Status

Live

Who built it

Stratyx Ventures

Back to all work

Talk to our team about your project

Whatever you’re building or fixing, you’ll leave the first call with a straight answer on what it would take.

After the call, AI work starts with a Workflow Review for $2,500, and a site or an app with a written scope you approve.