The Products Study Portal

How it works

Every tenant-based product follows the same shape: a Keycloak realm provides the login/identity boundary, a backend microservice owns the product's data, and a web frontend renders the experience. What differs between products is the domain — what kind of thing the tenant is building and publishing.

Erevna — surveys & forms

What it is. Erevna is a survey and form builder. A tenant creates a survey, adds questions, publishes it, and collects answers — including from people who are not logged in at all.

Who it's for. Anyone who needs structured input: customer-satisfaction surveys, sign-up forms, feedback collection, research questionnaires, NPS tracking.

Core features. Erevna supports a broad set of question types and, crucially, answer-validation rules layered on top of them:

Validation rules constrain what a respondent may submit:

The standout capability is the public / anonymous respondent flow: once a survey is published, you can hand out the link and collect answers from people who have no account. This is what makes Erevna useful for real-world data collection rather than just internal forms.

How a user uses it. A tenant owner logs into the Erevna frontend (Keycloak realm questioner), builds a survey by adding questions and validation rules, publishes it, shares the public link, and later reviews the collected answers.

Architecture note. The backend is deliberately a "dumb store" — it persists each survey's questions as a JSON blob and does not branch on question type. Type-specific logic, validation, and scoring run mostly client-side. This is a real tradeoff to understand:

type is added; the store is generic and flexible.

it's handed; richer server-side analytics, type-aware querying, and scoring are harder and are the reason Erevna sits at ~65% complete with analytics as the next gap.

• Upside: the backend never needs a schema migration when a new question
• Downside: validation is enforced on the client, so the server trusts what

Erevna data shape (conceptual)
Survey
 └─ questions: [ { type, label, options?, validationRules? }, ... ]   ← stored as one JSON blob
 └─ responses: [ { answers: [...] }, ... ]                            ← anonymous responses allowed

Katalogos — online menus

What it is. Katalogos lets a restaurant or café build a digital menu and publish it as a public page — the kind of page you'd put behind a QR code on a table.

Who it's for. Hospitality businesses: restaurants, cafés, bars, anywhere a printed menu could be replaced (or supplemented) by a scannable page.

Core features.

Billing. Katalogos has billing tiers, and the enforcement is the interesting part architecturally:

• Free tier shows a watermark on the public menu.
• Premium removes the watermark and unlocks extras.

Enforcement happens on the backend, not the client. The menu service does not trust the browser to decide whether a tenant is paid — it asks the Payment service whether the tenant is subscribed. This is the correct pattern: a client could spoof "I'm premium", but a server-to-server subscription check can't be bypassed by editing the page.

Public menu request
  browser ──> Katalogos backend ──(is tenant subscribed?)──> Payment service
                     │
                     └─ subscribed? remove watermark : show watermark

How a user uses it. A café owner logs in (Keycloak realm onlinemenu), creates categories and items, adds variants/modifiers and photos, and publishes. The resulting public page can be linked from a QR code. On the free tier the page carries a watermark; subscribing removes it. A café on premium can also point its own custom domain at the menu.

Kefi — event pages with custom domains

What it is. Kefi creates event landing pages. A tenant spins up a page for an event; visitors can register / RSVP, and the page tracks which event was viewed.

Who it's for. Event organisers — a meetup, a party, a conference, a launch — anyone who wants a dedicated page per event with sign-ups.

Core features.

The per-event URL structure is worth internalising:

https://<host>/t/{tenantSlug}/{eventSlug}
                  │            └─ editable, identifies the event
                  └─ identifies the tenant

Custom domains are the most infrastructure-heavy feature here. A tenant adds a CNAME DNS record pointing their domain at the platform. The platform then provisions a per-host ingress, obtains an automatic TLS certificate, and uses a Traefik path-rewrite middleware so that a request to the tenant's bare domain is internally served as the tenant's existing event page (the middleware rewrites the path to the /t/{tenantSlug}/… form behind the scenes). The visitor sees a clean, branded domain; the platform serves it without the tenant having to host anything.

visitor → events.somebrand.com   (CNAME → platform)
            │  per-host ingress + auto TLS
            │  Traefik middleware rewrites path
            ▼
          /t/{tenantSlug}/{eventSlug}   ← the page that already existed

How a user uses it. A tenant creates an event, optionally edits the slug to something memorable, and shares the URL. To brand it, they set a CNAME on their own domain and the platform handles the ingress + certificate. Visitors land on the page and RSVP. Kefi is feature-complete.

Games & tools

What it is. A set of standalone browser apps that live on the platform but are not tenant-based SaaS products. They reuse platform plumbing — the deploy pipeline, analytics, and shared game libraries — without a per-customer account model.

Who they're for. The general public — anyone with a browser. There's no sign-up-and-own-your-data model the way Erevna/Katalogos/Kefi have.

What they share. Even though they're standalone, they aren't built in a vacuum. They use:

save-state (so each game doesn't re-implement "buzz the device" or "save my progress" from scratch).

• the same analytics instrumentation,
• the same deploy pipeline,
• shared game libraries for cross-cutting concerns like haptics and

Aurora is the richest example: a Phaser-based tile/puzzle game with its own synthesised audio engine (sound generated in the browser via WebAudio rather than shipping audio files) and device haptics for feedback.

How a user uses it. Open the URL, play. No login required.