Event project portal, light

01Intro

The light project portal bundles one event in one place – lean, not overloaded: schedule and timing, downloads and documents, contacts, open to-dos, optionally the registration. As a small tool of your own that you refill per event, instead of wiring up four tools every time. It's made of building blocks that already help on their own: a package calculator that shows the client the budget league up front; a trades status light that keeps the countdown in the team's view; an on-site check-in for the phone on event day. Together they're the "light portal" – and because it's yours, it looks like you, not like a standard off-the-shelf tool.

Straight up: prototype and product are two different things. A "light" portal is deliberately lean – sprawling software with rights, real-time and sync is its own decision, not a given. We build the small, clear benefit first and only grow it once it proves itself. That way it stays a tool, not a maintenance barrel.

02Demo

03How it works

1. 01

   Choose the small, clear process

   What's most annoying per event – the scattered downloads, the unclear status, the budget question in the first call? One building block is built first, the one that brings immediate calm.

2. 02

   Clarify data and roles

   What does the client see, what the team, what the trades? What details does each building block need? Small scope, clear limits – that's what keeps it "light".

3. 03

   Build the prototype quickly

   With real sample data from an actual event, a clickable building block takes shape in days, not weeks – a basis for decisions instead of a spec sheet.

4. 04

   Test at a real event

   The building block runs alongside a real project: does the package calculator hold, does the status light help, does the crew use the check-in? What holds, stays.

5. 05

   Bundle or leave as is

   Proven building blocks grow together into the light portal – or deliberately stay separate. Only when several processes belong together does the bundled portal with login pay off (Tier 3).

04Stages

Congruent with the prototype logic: the small benefit first, then – once it holds – more.

05Technical implementation

• Frontend: a small web app or microsite per event – in the agency's branding, usable on mobile.
• Building blocks as modules: package calculator (formula logic), trades status (reads the project board), on-site check-in (QR/live status) – each runnable on its own.
• Backend/data: Supabase/Postgres, Airtable or a lean file structure for prototypes – as much as needed, as little as possible.
• Hosting: Vercel/Netlify or comparable; data storage on EU servers when personal data is involved.
• Auth only when needed: a prototype needs no login; client access and roles come with Tier 3.
• AI optional and small: progress estimation from tasks, summaries – only where it brings real benefit.

for context · This shows how something like this usually gets built – not how it has to be built for you. What actually fits is worked out in the project: around your existing setup, your team, and what stays easy to maintain.

06Related building blocks

• Automation

  Custom event registration platform

  The building block that often comes first: the branded registration flow the portal docks onto.

• Knowledge

  Project knowledge base

  What feeds the portal and what it leaves behind: suppliers, processes and learnings the next event draws from.

• Strategy

  Data visualisation

  What becomes of the portal data: attendee and status figures as an image for client reporting.

• Strategy

  AI audit & baseline

  The honest check first: whether a standard tool is enough or the custom portal is worth the effort.