Sponsorship Portal:
every promise, accounted for.

One sponsor.
Many moving parts.

An agreement might include a cash contribution, products supplied in kind, branding at an event, and hospitality for a sponsor’s guests. Outreach owns the relationship; other departments execute the work; finance needs to understand its cost.

The product challenge was to connect those responsibilities. A sponsor-level total needs to lead to individual deliverables, named owners, deadlines, and reviewable evidence.

From an agreement
to an accountable workflow.

The MoU anchors the relationship. Deliverables break it into work. Departments supply evidence. Review decisions update progress across the agreement.

Completion follows the review.

Approving a proof marks the matching department’s contribution as accepted. A deliverable becomes complete when every assigned department is accepted. A sponsor becomes complete when all its deliverables are complete.

Rejecting evidence records a reason and keeps the work in progress. This gives the department a specific correction to make and preserves the distinction between submitting a file and fulfilling a promise.

Keep the overview clear.
Keep the detail close.

The interface moves from a dashboard to a sponsor register and then to an individual sponsor’s overview, tasks, and finances. Tables support comparison; detail views carry the context needed to act.

Explore the original screens below. Each shows a different part of the same operating workflow.

Track the contribution.
Understand the commitment.

Cash, in-kind resources, and hybrid sponsorships have different operational implications. The portal records those values separately while retaining a combined view of the agreement.

Standard tasks track execution. Cost-associated tasks add estimates and expense detail, including printing, accommodation, and food. Finance can update actual costs as the event progresses.

A useful distinction in the numbers.

The implemented dashboard’s profit calculation subtracts estimated delivery cost from combined cash and in-kind value. Actual costs are tracked separately. That margin describes the portal’s value model; it should be read alongside the cash figures when planning expenditure.

Structured records.
Connected state.

The application uses Next.js 15 and React for the web experience, styled with Tailwind CSS 4 and reusable UI components. Route handlers and server actions connect the interface to Firebase Admin and Cloudflare R2.

Identity and task ownership.

Firebase Authentication handles sign-in. The server creates an HTTP-only session cookie and resolves a user record from Firestore. The application uses the stored role to select the relevant workspace; task assignments connect department users to the work they own.

Files and records have separate jobs.

Firestore stores sponsor, task, and proof metadata. R2 stores the MoU PDFs and supporting image, video, or document files. The upload route obtains a signed URL and sends the file to R2; separate routes provide signed preview and download URLs.

A review updates the whole chain.

The proof review route saves the decision, reason, and review timestamp. It then updates the matching department assignment and calls the shared status manager to recompute the deliverable and sponsor’s completion.

Built for an event.
Used across the organisation.

The repository documents use at Paradox ’25 across sponsorship, finance, and departments including outreach, hospitality, multimedia, WebOps, security, and student relations.

The work becomes traceable.

The practical result is a connected record: the sponsor’s agreement, the departments responsible, the proof they submit, and the financial view of delivery. The team can investigate an unfinished commitment at the task level instead of relying on a single completion percentage.

The published results describe the scale of use. A future evaluation could measure review turnaround, correction cycles, and time spent reconciling agreements to understand where the workflow saves the most effort.