EventLink

EventLink is a two-sided marketplace that connects event creators with sponsoring brands. It allows organizers to publish events with tiered sponsorship packages, and sponsors to discover, evaluate, and negotiate deals — all within a single platform.

---

Problem it solves

Finding and closing sponsorships for events is slow and unstructured. Organizers chase brands through cold emails and spreadsheets; sponsors have no single place to discover relevant opportunities. EventLink centralizes the process: structured listings, clear pricing tiers, and a built-in deal room for negotiations.

---

User roles

Role	Description
Creator	An event organizer who publishes events and defines sponsorship tiers. Manages incoming proposals and negotiates with sponsors.
Sponsor	A brand or individual looking to sponsor events. Discovers events, sends proposals, and negotiates terms through the deal room.

---

Core features

For Creators

• Create events with full details: title, description, date, location, industry, expected attendance, tags, and a cover image.
• Define sponsorship tiers per event — each tier has a name, price (USD), and a list of benefits.
• Tier templates — save reusable tier packages that can be cloned into any new event, avoiding repetitive setup.
• Receive and manage proposals from sponsors, including the ability to counter-offer or accept/decline.
• Deal room messaging — a threaded chat with each sponsor to negotiate terms in context.

For Sponsors

• Discover events — browse a feed of published events, searchable and filterable by title, industry, and tags.
• View sponsorship tiers — see available packages, pricing, and benefits before reaching out.
• Send proposals — initiate a sponsorship proposal tied to a specific event tier, or propose custom terms.
• Deal room messaging — communicate directly with the event creator to negotiate and close the deal.

---

Application flow

%%{init: {
  "sequence": {
    "actorMargin": 200,
    "messageMargin": 56,
    "noteMargin": 28,
    "boxMargin": 18,
    "boxTextMargin": 12,
    "useMaxWidth": false
  },
  "themeVariables": {
    "fontSize": "17px",
    "actorFontSize": "17px",
    "noteFontSize": "15px",
    "messageFontSize": "16px"
  }
}}%%
sequenceDiagram
    participant S as Sponsor
    participant C as Creator

    Note over S: 1. Browse discover feed<br/>2. Select event + tier
    S->>C: 3. Send proposal
    Note over C: 4. Review proposal<br/>(accept / decline / counter)
    C-->>S: Counter-offer
    S->>C: 5. Respond to counter
    C-->>S: Accepted
    Note over S,C: Deal room chat open (negotiation and coordination)

Loading

---

Git commit convention

Use Conventional Commits: <type>(optional-scope): short imperative summary> in the subject line (about 50 characters or less; no trailing period).

Common types: feat, fix, docs, style, refactor, test, chore (build, tooling, deps). Use a scope when it helps navigate history, for example feat(events): add tier duplication or fix(auth): handle expired session.

Optional body for context; use a footer for breaking changes, for example BREAKING CHANGE: proposals API response shape updated.

Examples:

• feat(proposals): allow counter-offer from creator
• fix(chat): correct unread count when thread empty
• docs: link backend README from monorepo overview

Adjust types or scopes here if the team agrees on a stricter list.

---

Pull request workflow

1. Branch from the integration branch (usually main). The branch name must include the user story numbers you are implementing, plus a short slug:
   • Pattern: <type>/<story-id(s)>-<slug> using hyphen-separated IDs when more than one story is in scope.
   • Example: feature/7-8-sponsor-discover-filters (stories #7 and #8).
2. Keep changes focused — one concern per PR when possible; split large work across stacked or sequential PRs.
3. Open a PR whose title includes the same user story numbers (GitHub-style # references) and a readable summary, then a description with intent, key changes, and how to verify (manual steps or tests).
   • Pattern: Feature: #7 #8 Sponsor discover filters (adjust the leading word to match the work: Feature:, Fix:, Chore:, etc.).
   • Another example: Fix: #14 #15 Correct proposal counter-offer timestamps.
4. Review — at least one approval from a teammate before merge; address feedback with additional commits or discussion on the PR.
5. Merge — use squash and merge so the default branch keeps one commit per PR with a clean message. Avoid force-pushing shared branches after review has started unless reviewers agree.