startup-pitch-contest

Startup Pitch Contest

You design and run a pitch contest: a demo day, a startup showcase, a pitch competition, held inside a larger technical event. It covers:

• Who gets on the stage.
• What they do once they are on it.
• Who judges, and on what.
• What a judge may do afterwards with a company they just watched.
• What the winner actually receives.

No build phase

A hackathon judges an artifact assembled inside the event, in a room the judges can walk into. You judge a company that existed before anyone arrived and will exist after everyone leaves. Three consequences run through every section:

1. Almost nothing that decides the result is observable in the slot. samber/dev-event-organizer-skills@hackathon-judging tells its reader to "Check the highest-weighted criterion is one a judge can actually observe in the slot." That instruction deletes most of a pitch rubric here. Traction, retention, margin and team history are claims about a world outside the room, so the reviewing problem becomes verification against an application, not observation on the day.
2. Readiness is a property of the applicant, not of the event. A hackathon can rescue an unfinished project with more hacking hours. Nothing makes a company more ready between the call closing and the stage, so everything that decides slate quality happens in the funnel.
3. Nothing here schedules a build, a venue for one, or mentors for one. There is no build phase, so there is no hand-off to make and no sibling skill owns one.

What you own, and what is already decided

• The block is not yours. samber/dev-event-organizer-skills@event-format-selection commits the hours in the shape, and samber/dev-event-organizer-skills@event-schedule-design places the block in the published grid. You design inside that block and never move a session.
  • The format-selection demo-structure menu (expo table, stage pitch, video only, two-stage) is written for hackathon teams presenting projects built at the event, and names no startup pitch contest.
  • The pitch format below is claimed here rather than agreed with it. Say that when presenting it.
• The scoring arithmetic is not yours, and you must not re-derive it. samber/dev-event-organizer-skills@hackathon-judging already solved the judge-time-budget problem in general form: the full-coverage ceiling, the coverage-per-team formula, the three allocation bands, and the feasibility gate all live in its own judge-allocation reference.
  • Open that skill, load that reference, feed it your own numbers, and consume the answer.
  • Only one input changes meaning: the hackathon per-team figure is dominated by setup and swap at a physical handoff, and a serial stage block has none of that. Take the formulas, and re-measure the input.
  • The full adaptation is in references/pitch-block-and-rubric.md.
• Founder-to-investor 1:1 meetings are not yours. samber/dev-event-organizer-skills@event-b2b-matchmaking owns them, and already names the configuration a pitch contest tends to grow into: "a curated founder-and-investor day, not a conference with a meeting corner." A pitch is a broadcast to a jury; a meeting is a booked pair. Route it there and build no booking mechanic here.
• Cash prize structure almost certainly does not apply. samber/dev-event-organizer-skills@hackathon-cash-prize is named and scoped to hackathons throughout, and its medium menu is built on one hackathon organizer's prize guidance. Do not reach for it by default.
  • Its refusal to state a threshold, a form name or a currency amount transfers and is adopted below.
  • Its routing shape transfers and is adopted below.

Do not state any of the following, in this skill or in anything built from it:

• Pitch length.
• Slate size.
• Judge count.
• Application volume.
• Acceptance rate.
• Prize amount.
• Equity percentage.

Those seven are exactly the quantities that feel safe to invent, and an invented number outlives the caveat attached to it. One published figure is the exception: DevOpsDays' organizing guide states people usually need at least 4-6 weeks to arrange travel or time off before a pitch event.

Every ranking below is a default, not a law. After the interview, re-rank all four menus against what you already know. Each of the following overturns a default rung:

• A fund partner already on the organizing team.
• An accelerator relationship that predates the event.
• A slate half-filled by invitation before the call opened.
• A stage block that cannot grow.

Interview

Ask one question at a time, multiple-choice where possible. The menus below turn on questions 4-6 and 9-10, and nothing else surfaces the facts they carry.

1. Is the contest already committed in the published programme, and what has already been said publicly about how a company gets on that stage? Read it before designing anything - a published route is a promise, not a starting position.
2. Who is the pitching population, described as a stage of company rather than a number: pre-product, first customers, or raising against traction? Who decided that, and is it written down anywhere an applicant can read?
3. Which block of the grid does the contest own, is that block already fixed, and how many companies is it expected to hold?
4. Who judges, named by role - active investors, operators, customers, sponsor representatives, a regional or public-sector representative where the event carries a regional or public mandate? For each investor judge, does their fund invest at the stage these companies are at? And was anyone, judge or audience, invited specifically because of who would be pitching?
5. What does the winner actually receive, item by item - and for each item, which party delivers it, and have they committed to it in writing?
6. Does any award carry capital, a convertible instrument, or equity in any form? If so: is placing that capital the reason the contest exists, or is it a prize attached to a contest that would run anyway?
7. Is any part of the contest sponsored, and does any signed agreement give a sponsor a say in who pitches or who wins?
8. Is the room recorded, streamed, or open to press - and were applicants told that before they applied?
9. One-off edition, or a recurring contest whose rules should still hold next year? By what date must the call and its criteria be published?
10. What is the effort ceiling: organizer hours across the application window, who reads applications, who chases a third party that promised the winner something - and what already exists that would overturn a default, such as named referrers who would nominate companies?

Workflow

1. Run the interview. Read what was already published (Q1) and the block you were given (Q3) before designing anything.
2. Decide the prize before the funnel - the same ordering samber/dev-event-organizer-skills@hackathon-cash-prize argues for its own domain. What the winner receives decides who applies, which judges will sit, and whether counsel has to see the structure at all.
3. Pick the funnel from its menu and write the published route down as a sentence before you build any form. Field lists are in references/application-and-slate-mechanics.md.
4. Publish the criteria and their weights in the call itself, before applications close. samber/dev-event-organizer-skills@hackathon-judging states the reason in one line that transfers without modification: "Undisclosed weights score a competition nobody entered."
5. Pick the pitch format from its menu, then take the arithmetic - not the numbers - from samber/dev-event-organizer-skills@hackathon-judging's allocation math and check the block actually holds the slate.
6. Build the rubric on what a judge can reach, splitting observable dimensions from claimed ones. Both lists and a positive/negative scoring pair are in references/pitch-block-and-rubric.md.
7. Set the conflict rule from its menu, and brief every judge on it before they see a single application - not before they score. Full ladder and the sponsor hard case are in references/investor-conflict-and-prize-policy.md.
8. Run the three gates below. If any one fires, counsel or the committing party reviews the structure before the award is announced.
9. Run the block. Announce from a prepared list, and state the same contest path samber/dev-event-organizer-skills@hackathon-judging prescribes: who receives a challenge, a window that closes before anything of value changes hands, and what can actually change.
10. Record what was delivered against what was announced, per item and per party, and hand nothing downstream - the award is yours to close out.

Present the design section by section for validation - prize, funnel, format, rubric, conflict rule - before the call goes public. A published call is a promise to founders who will rearrange a company's month around it.

If your harness has persistent memory, record the published route and its criteria, the prize items with the party who committed each one, every declared judge interest, and which of those items was actually delivered afterwards.

Selection funnel

Four rungs:

• Curated invitation: the organizer fills the slate from companies it already knows.

• Open application, single review pass.

• Open application with a screening call, before the slate is fixed.

• Nomination by named referrers: funds, accelerators or community leads each put companies forward, and the organizer selects from what arrives.

• effort (organizer hours across the window, review passes, and the promotion an open call has to sustain): open plus screening call > open single pass > nomination > curated invitation

• value, slate quality (pitches a judge and an audience would stay in the room for): open plus screening call > nomination > curated invitation > open single pass

• value, pipeline breadth (companies you would never have found on your own): open plus screening call == open single pass > nomination > curated invitation

• compliance cost, as the review it triggers and the reversibility it costs: open plus screening call > open single pass > nomination > curated invitation

• efficiency: open single pass > nomination > curated invitation > open plus screening call

The breadth == is argued rather than used to avoid a decision: breadth is fixed by who is allowed to apply, and both open rungs are open to exactly the same population. A second pass cuts the slate; it never widens the pool. The two rungs are genuinely equal on that axis and differ on every other one.

The compliance axis is real here and is easy to miss. Every applicant hands over material about a private company. The wider the call and the more people who read it, the more custody you take on and the less of it you can withdraw: a deck circulated to a reviewer cannot be un-circulated. The screening call tops the axis because it is the rung where a founder says more than the form asked for, with no record of what was said.

Dominance check, re-derived: 6 pairs, zero strict-dominance relations, and the reason accounts for all six in two groups.

• Four pairs, the screening rung against each of the other three, and nomination against curated invitation, are blocked the ordinary way: the rung ahead on value costs strictly more on effort and on compliance.
• The other two pairs are blocked because the two value axes genuinely disagree: open single pass against nomination, and open single pass against curated invitation. There, the open rung tops breadth and trails on slate quality, so neither rung can be at least equal on both.

Clean only by construction. The check catches nothing, and the efficiency line rests on the arguments below.

• Open application, single review pass - the default. It buys the whole reason to run a contest instead of booking the companies you already like, at one review pass. Its weakness is stated rather than hidden: paper review of strangers is the weakest available predictor of how a founder holds a stage, which is why it sits last on slate quality.
• Nomination by named referrers. A referrer's own standing rides on the company they put forward, and the pool is wider than the organizer's address book.
  • Promotion condition, keyed to Q10: named referrers who would actually nominate already exist.
  • Built for one edition from nothing, the rung stops paying: its recruiting and briefing cost lands before a single application arrives.
• Curated invitation. Cheapest on every axis, and it ranks third rather than first for a specific reason: the slate is one the organizer could have produced with no contest at all, so the mechanic earns nothing its own name promises.
  • Delete it, from this menu and from the axis lines above, when Q1 says a public route onto the stage has already been announced. Running a call and then filling the slate from your own contacts is the single most contestable thing in this skill.
• Open application plus a screening call - the starved option. Top of slate quality, top of effort, top of compliance cost, so efficiency never picks it. It is also the only rung that tests what the form cannot show: whether the founder can hold a room. Two promotion conditions, each traced separately:
  • Keyed to Q3: the block is fixed and short relative to the slate it must hold, so one weak pitch costs a share of the block you cannot get back.
  • Keyed to Q4: a judge or an audience was invited specifically because of who would be pitching. The slate was the offer, and the offer has to survive contact.

The open rungs' timeline carries over from the call samber/dev-event-organizer-skills@event-cfp-design designs: open early, close well before the event, review inside the gap. So does its one hard floor, the published lead time an accepted party needs to arrange travel. Below that floor the open rungs stop working and the slate goes to invitation. The anchors, the published figure and the limit on carrying it across are in references/application-and-slate-mechanics.md.

Pitch format

Four rungs:

• Stage pitch only: a fixed slot, no questions.

• Stage pitch plus judge questions.

• Stage pitch plus questions plus a closed-door deep dive with the finalists.

• Written or recorded submission scored before the day, with a stage pitch for finalists only.

• effort (block minutes consumed, judge hours, and rounds to run): deep dive > pre-scored plus finalist stage > pitch plus questions > pitch only

• value, evidence a judge actually holds when scoring: deep dive > pre-scored plus finalist stage > pitch plus questions > pitch only

• value, what the room gets (the audience the event sold this block to): `pitch plus q

...