Flapi timeline archive

It was explicitly requested that “the current UI direction is good” and that “the specification should support a variety of store formats.”

Prepare the iOS distribution signing credentials interactively, then upload the latest build to App Store Connect.

The Docker build stopped with exit 127 when admin’s deploy.sh ran, so it needed to be aligned with the current Dockerfile structure used by Flapi’s app.

Redeploy admin and shop to production and verify that the admin screen and store portal start and connect to the API.

Shifted the focus from adding more entry points to filling the gaps that prevent confident use in production.

Because if users must wait to open it, see inconsistent state from screen to screen, and cannot add photos, the next round of usage testing cannot proceed.

In production, open the map from a QR code and verify the full flow through login and icon setup.

Does the wait before the public map opens still feel too long?

Before broadly expanding features, narrowed the priority to developing the public map first as a point of contact with new users.

Because official information distribution, search, social media, and venue QR codes can all connect to one entry point.

In production, verify the flow from scanning a QR code to viewing the map and beginning to use the service.

Changed the approach so the map appears first instead of waiting for the connection to complete on the initial screen.

Because the entry point to the encounter experience is having the map open immediately.

In production, verify the entire flow from first launch to map display and the subsequent loading of information.

In production, test the entire experience from anonymous start through encounters and collection.

When you see the top page or introductory copy, does the experience of “collecting cards through chance encounters” come through?