How to organise a paid hackathon with clear participant rights

So you're planning a hackathon, and the venue, mentors and prize fund all need paying. Charging for entry seems reasonable. Then someone asks whether your sponsor will own whatever they build, and you realise the ticket page doesn't actually answer that.

To organise a paid hackathon, define the experience people are buying and the rules for the work they'll create before opening sales. Give participants a useful challenge, enough building time, fair access to help and a judging process they can understand. Make ownership and any permission to share their projects clear before they pay.

I'd start with the experience someone gets even if they don't win. A prize can make the weekend more exciting, but everyone else still bought a ticket. They should leave having built something, received useful feedback and understood what happens to their work afterwards.

We'll use a fictional event, Dockside Build Weekend, to work through the decisions. It's an independent, in-person event for adults, with up to 80 participants working in no more than 20 teams. It closes overnight. All prices, timings and calculations below are invented planning assumptions in USD, not market rates or results from a real event.

Decide what makes this hackathon worth paying for

A hackathon gives people a defined period to build and demonstrate a response to a challenge. That leaves plenty of room for different experiences. You could run a beginner learning weekend, a professional prototype competition or a specialist challenge for people already familiar with a technology. Choose the one you can deliver well.

For Dockside, the offer is a supported prototype weekend for people who can already use at least one relevant skill. Developers, designers and people with experience of the problem can join. It's not an introductory coding course, and we aren't promising that participants will launch a business by Sunday afternoon.

That distinction affects staffing. A mentor can help a team work through a problem, but can't teach an entire programming language between other appointments. If your likely buyers need structured tuition, our paid workshop planning guide explains how to build an event around teaching and practice. You might need that format instead.

Write the paid offer as a paragraph a potential participant can judge. Dockside includes two days of workspace, scheduled mentor access, team matching, participant meals, a demonstration opportunity and written judging feedback. Participants bring suitable laptops. Travel, accommodation and continued project support aren't included. Any software or paid account requirements need naming too.

Now test the offer with people you'd actually want to buy it. Ask what they'd build, which help they'd value and whether they'd come without a prize. If their main reason is access to a particular mentor, check that person's involvement before advertising them. If they're buying time with collaborators, protect that time in the schedule.

Don't describe an introduction to sponsors as a likely job offer. An employer might be interested in meeting people, but participants can't buy a recruitment outcome you don't control. Describe the session, who has confirmed attendance and whether joining it is optional. That gives the buyer something concrete to assess without turning an interesting possibility into a promise.

Choose a challenge people can tackle in a weekend

An enormous challenge can produce surprisingly little work. "Solve urban transport" gives teams too many decisions before they can start. "Help a first-time passenger understand a fictional bus disruption" gives them a user, a situation and something they can demonstrate within a weekend.

Dockside's brief asks teams to help that passenger choose a next step using a supplied fictional timetable and disruption notice. Teams can build an interface, a working tool or another demonstrable prototype. They must explain their assumptions and show how a passenger uses it. We aren't asking them to connect to a real transport operator or process live passenger data.

Prepare a short challenge pack with the following information:

• The person or group the project should help, and the problem they're facing.

• The materials every team receives and the permitted ways to use them.

• The expected submission, including what needs to work during the demonstration.

• The constraints, excluded activities and judging criteria.

• Where participants can ask questions and where everyone can read the answers.

Have someone outside the organizing team try the materials before you sell the event. Can they open the files, understand the fictional data and build a small example without special access? A broken account setup can consume the first building session before anyone reaches the interesting work.

Keep the challenge independent of a sponsor's confidential commercial backlog. If a business wants participants to build something it can deploy, that requires an explicit arrangement about paid work, ownership and permission to use the result. Don't advertise a learning competition while privately promising a company free production software.

You can still invite a business to describe a real problem. Ask it to remove confidential information and explain the context in terms all teams can use. Put answers to material questions in the shared challenge notes. A team that happens to sit next to the sponsor shouldn't receive a different version of the task.

Check the competition rules before collecting entry fees

Charging people who can win prizes creates questions beyond ordinary event admission. Where the organizer operates, where participants live, how winners are selected and whether chance affects the outcome can change the requirements. Get advice on your actual format before selling it across jurisdictions.

For Great Britain, the Gambling Commission explains the distinction between prize competitions and lotteries. Its test concerns the level of skill, knowledge or judgement required. Calling an event a hackathon doesn't establish that it satisfies the law. The Commission also says it doesn't approve these formats for organizers.

Don't add a random cash draw for paid participants because it sounds like an easy extra attraction. That introduces another prize mechanism to assess. Keep your proposed entry route, judging, tie decisions and any audience award together when you ask for advice. A separate spectator ticket doesn't resolve questions about the participant competition.

Your rules should explain eligibility, team sizes, entry deadlines, what entrants submit, how judging works and what the prizes contain. Include how complaints are handled and what happens if the event can't proceed. Make the important conditions visible in the sales material, with full terms available before payment and a version participants can retain.

The UK's ASA guidance on competitions addresses significant conditions, independent judging where selection is subjective, and awarding prizes as described. These are useful planning checks for a UK promotion; they aren't a substitute for checking the law in another country.

Agree your cancellation and refund approach around the event you're selling and applicable consumer rights. What happens if you cancel, a participant withdraws, a teammate drops out or a promised element becomes unavailable? Explain those situations separately. An organizer's cancellation and a participant deciding not to attend don't necessarily lead to the same outcome.

Explain ownership and permission in ordinary language

The first rights question is simple: what are you asking the participant to give you? Most organizers need enough permission to judge a submission and report what happened. That is a much narrower request than taking ownership of everything created during the event.

At Dockside, entering doesn't transfer participants' rights to the organizer or sponsors. Entrants remain responsible for identifying who owns their contributions and whether they have permission to submit them. Have that policy reviewed and documented, including what happens when an entrant uses work owned by someone else.

Separate work created before the weekend from work created during it. A participant might bring a personal template, employer-owned code or a collaborator's design. Your entry form can't turn those materials into the participant's property. Ask entrants to disclose the relevant prior work and check permissions before using it.

There is also a difference between an idea and its expression. WIPO's copyright guidance explains that copyright can protect computer programs and other original works, while ideas themselves aren't protected by copyright. Avoid promises that entering your event makes an idea exclusively theirs or prevents anyone building something similar.

Use a rights brief to agree the practical choices with your adviser. It should answer who can assess the private submission, what may appear in a public project listing, whether demonstrations are recorded and what permission any published recording needs. Specify the purpose, audience and duration of each permission rather than asking for unrestricted use because it's convenient.

At Dockside, the proposed approach is private assessment of the submission and an optional public listing containing a team-approved title, summary and image. Any recording or later promotional use needs its own clear arrangement. The team shouldn't discover after entry that a sponsor can place the entire demonstration in a sales campaign.

Give participants a contact for questions before they pay. Someone with an employer restriction might still be able to attend using a fresh project and permitted materials. Someone who needs confidentiality may find that your public demonstration format doesn't suit them. It's better to resolve that before the weekend than to promise secrecy your room and audience can't provide.

Here's a plain-language explanation you could adapt once the underlying terms have been checked: "Your entry doesn't transfer ownership of your work to us or our sponsors. Our judges need access to the materials you submit to assess your entry. The final demonstration takes place in front of the event audience, so don't include confidential information. A public project listing is optional, and we'll ask you to approve the summary and image before publishing it."

That paragraph explains Dockside's chosen approach. It isn't a complete agreement, and it must match what the formal terms and actual process say. In particular, don't describe a public final as private simply because the code submission is restricted to judges. Tell teams who can attend, whether recording is allowed and how you'll enforce the audience policy.

Have someone unfamiliar with the event read both versions. Ask whether they think a sponsor can sell their prototype, whether they must publish their code and whether their final presentation is confidential. If their answers differ from your intended arrangement, improve the explanation before accepting payment. You've found a misunderstanding while it's still inexpensive to fix.

Agree how the team will work together

A team also needs to understand its own arrangement. Four people can collaborate happily for a weekend and disagree later when one person wants to keep developing the project. Ask them to discuss that possibility while everyone can still make an informed choice.

Provide a team discussion sheet covering existing contributions, access to project files, credit, permission to continue development and how any prize will be divided. Have members record their agreed decisions. Where a binding ownership agreement is needed, direct them to appropriate advice; a short organizer worksheet won't settle every employment, contractual or joint-ownership question.

Name a practical project contact without treating that person as the owner of everyone else's work. They can submit the entry and receive administrative messages, but should confirm that the other members have seen the submission. Give individuals a private way to raise concerns if the team's account of contributions is wrong.

For a cash award, explain whether you pay one nominated recipient or each member, what information is required and when payment is due. Ask teams to agree their split in advance. Don't announce a prize per person when the budget funds one award per team, or leave winners to negotiate the meaning on stage.

Set rules for existing code, AI tools and sensitive material

"Build everything during the event" sounds clear until someone asks whether they can use a library, a design system or a tool they built last month. Write rules that match what you intend to assess. Otherwise teams will make different assumptions about the same competition.

Dockside permits existing libraries and tools where their terms allow the intended use. Teams disclose substantial prior project work. Judges assess the response developed during the published build period, and teams explain which parts they created then. We don't pretend that a modern prototype starts with an empty computer.

A public repository isn't automatically free to reuse. GitHub's Choose a License explanation of unlicensed code distinguishes public visibility from permission to use, modify or share it. Ask teams to keep a simple record of important third-party components, their sources and applicable licences. Don't tell them that adding a licence of their own removes existing restrictions.

Decide whether public code is required at all. Dockside allows private judging access, so participants can demonstrate a project without publishing every file. If your event requires open-source submissions, state that before entry and define the requirement with suitable advice. "Open source" shouldn't appear for the first time in the winner's email.

For AI tools, publish a rule people can follow. In our example, teams may use them, must disclose substantial use and remain responsible for what they submit. Judges can ask how an output works and what the team checked. The rule doesn't guarantee that generated material is accurate or free of third-party restrictions.

Prohibit uploading confidential material, personal information or secret access credentials to tools that aren't approved for that use. Give teams fictional data and temporary accounts where possible. Ask your technical lead to prepare a way to report an exposed credential, remove it from public materials and replace it promptly.

Define the finish rule too. Dockside stops project development at the submission deadline. A team can show a previously captured backup demonstration if the live tool fails, under the published evidence rules. It can't spend the judging period adding features. Decide this before the first broken demonstration makes everyone look to you for a ruling.

Work out whether the paid event can cover its costs

Build the budget around delivering the promised experience to every participant. Include your preparation and delivery time, mentor fees, judging administration, technical support and the prize fund. A sponsor donating software credits doesn't pay the venue invoice, and an unpaid organizer still has a cost to consider.

Dockside sells individual participant places at $125, with a maximum of 80. It has $4,000 of confirmed cash sponsorship. We assume that money is available when needed and that the fixed budget covers the sponsor's agreed benefits. If either assumption changes, the calculation needs updating.

The fictional fixed costs are $1,500 for the venue, $1,000 for technical production, $2,000 for mentors and judges, $2,200 for organizing and support, $2,000 for prizes, and $800 for insurance, advice and contingency. That's $9,500. These allowances also cover staff catering, nonparticipant attendance costs and any sponsorship collection charges.

Participant meals and consumables cost another $30 per person. For this simplified example, we assume ticket and payment charges together equal 3% of ticket revenue, with no additional fixed charge. That's an invented combined assumption, not Loopyah pricing. Supplier totals include any applicable sales taxes; the example excludes business income tax.

At 80 paid participants, tickets bring in $10,000. Add the $4,000 sponsor payment and total revenue is $14,000. Costs are $9,500 fixed, $2,400 for participants and $300 in charges. That leaves $1,800 after the costs we've included. It isn't a promise of what a real hackathon will earn.

To find the minimum sales, each $125 ticket leaves $91.25 after $30 participant costs and $3.75 charges. Sponsorship reduces the fixed amount tickets need to cover to $5,500. Dividing $5,500 by $91.25 gives just over 60 tickets, so 61 paid places cover these assumptions. At 60, the event is $25 short.

I'd avoid treating 61 as a comfortable sales target. Dockside plans its go-ahead decision around 64 paid places, which leaves only $340 under the same assumptions. A small cost increase could use that up. Check the remaining uncertainty and decide whether that amount is acceptable before committing, rather than calling any positive number a healthy profit.

Without the $4,000 sponsorship, even selling all 80 places leaves a $2,200 loss. That makes the sponsor payment essential to this version of the event. Have a decision date before nonrefundable commitments rise, and check cash timing separately from the final total. A signed promise to pay after the weekend won't fund a deposit due today.

Limit teams as carefully as individual places

Eighty people doesn't tell you how many projects you'll judge. If everyone arrives in pairs, you could have 40 teams. Dockside's judging plan supports 20, so selling 80 individual places without controlling team formation would create a problem even though the room wasn't oversold.

Set both limits. Dockside allows teams of two to four people, no more than 20 teams and no more than 80 participants. Existing teams reserve their team place and identify their members through the published booking process. Solo buyers enter the matching process with a clear explanation that a purchase doesn't reserve a separate team slot.

Before selling solo places, decide how you'll accommodate them within the remaining teams. Ask about skills, interests and practical participation needs without promising a perfect match. Track available team spaces as bookings change. Once the remaining team capacity can't support another buyer, stop selling until you have a workable arrangement.

For example, ten confirmed teams of four use 40 participant places and ten team slots. The remaining ten team slots can accommodate up to 40 more people. But if those ten slots become teams of two, all team slots are used at 60 participants. The remaining 20 person places aren't automatically saleable; existing teams would need to accept additional members.

If buyers prefer pairs, take that seriously before committing to a budget that needs 61 paid participants. You may need more judging capacity or lower costs. Don't rely on persuading established teams to take strangers once you've spent the money; ask about that willingness during registration and build the sales forecast around confirmed arrangements.

The ticket-selling tools in Loopyah let buyers choose ticket types at their current prices and pay online. Use clear participant and spectator descriptions if you sell both. Your competition still needs a reliable team allocation and eligibility process; don't assume a paid ticket alone confirms that a team can enter.

Keep booking confirmation, participant acceptance and project submission distinct in your communications. A buyer should know what they've paid for, whether any eligibility check remains and what they must do next. If you assess applications first, explain that sequence and when payment becomes due. Avoid taking money for a place you later discover you can't provide.

Sell sponsors useful access without promising participant work

A hackathon sponsor can fund mentors, technical resources, participant places or a relevant demonstration session. Choose benefits that improve the event and that your team can actually deliver. A logo on the backdrop is straightforward; an implied right to every prototype is a different commercial arrangement.

For Dockside's $4,000 deal, the sponsor receives acknowledged support, a defined demonstration session and an optional opportunity to meet interested participants. Its staff can explain the fictional challenge context to everyone. They don't receive ownership of submissions, automatic access to private project files or a participant contact list for recruitment.

If a sponsor wants a separate challenge award, publish its eligibility and assessment criteria before entry. Explain whether teams can enter both the main competition and that award, and whether using a particular tool is required. A sponsor shouldn't introduce a mandatory account or new rights condition after people have bought tickets.

Cost the benefit as carefully as the fee. A specialist workshop might need another room, technical support and preparation time. If those costs aren't in the existing budget, subtract them from the sponsor payment before calculating what it contributes. A large quoted fee can leave little to fund the rest of the event.

Our event sponsorship agreement guide helps you document benefits, payment and approval responsibilities. Loopyah's event sponsorship tools can present priced packages and what's included. Use the written agreement to settle the participant-rights boundaries and delivery details behind that offer.

Make sponsor involvement visible to participants. Tell them who is helping, what the business receives and whether its representatives judge any award. People can decide whether an optional conversation interests them when they understand it. Trying to disguise recruitment or product research as neutral mentoring makes that choice harder and creates complaints you could have prevented.

Design judging around evidence teams can actually show

Start with the promised challenge outcome. Dockside judges whether the prototype helps the fictional passenger understand the disruption and choose a useful next step. A slick presentation alone doesn't answer that question, and a long list of unfinished features doesn't establish that the response works.

Our fictional scoring gives up to 40 points for usefulness to the passenger, 30 for the demonstrated response, 20 for testing and reasoning, and 10 for explaining limitations. That's 100 available points. These are editorial choices for this event, not a standard hackathon scoring system. Publish them with examples of what judges should look for.

For usefulness, judges might ask whether a new passenger can find the next action. For demonstration, they check the submitted workflow. For testing, they look at what the team tried and changed. For limitations, they assess whether the team can explain where the prototype stops working or makes assumptions. Different skills can contribute evidence to those answers.

Give judges the same briefing and let them assess a practice submission before the event. If one judge interprets "demonstrated response" as production-ready software and another accepts a clickable prototype, your criteria aren't ready. Resolve that disagreement and clarify the entrant brief before people start building.

For that practice, take an invented submission with a clear passenger journey, a working disruption screen and a weak explanation of testing. A judge might award 32 out of 40 for usefulness, 24 out of 30 for the demonstrated response, 10 out of 20 for testing and 6 out of 10 for limitations. That totals 72 out of 100. The useful part is the explanation for each score, so ask the judge to record what they saw and what was missing.

Another judge may reasonably interpret the same evidence differently. Compare their reasons while you're rehearsing and improve any ambiguous criterion. Don't force identical scores or quietly adjust real entrants' marks to create a preferred ranking. Decide in advance how panel scores are combined, how finalists are selected and what happens when a judge must withdraw from an assessment.

Record conflicts of interest and appoint replacement judges where needed. A mentor who substantially helped a team, a sponsor assessing a close business partner or a judge working with an entrant should declare that connection. Put a named person in charge of deciding the appropriate response, and keep the decision with the judging record.

Dockside uses two first-round panels, each assessing ten teams. Every team has four minutes to demonstrate, two for questions and two for transition. Ten slots take 80 minutes; each panel has a further 20 minutes for interruptions and checking scores. That means two suitably staffed spaces and enough judges, rather than the same people attempting both panels.

Those first-round rooms are closed to the audience. The final demonstrations are public within the event, so finalists need a version they can show without confidential material. Say that in the entry terms and rehearsal instructions; private code access doesn't make a public presentation confidential.

Each panel advances two teams under published selection rules. The four finalists then demonstrate to the same final panel. Their final scores decide the main awards, with a published skill-based tie procedure and a further assessment if necessary. Don't compare raw totals from different first-round panels as if every judge scored identically.

Tell teams how to query a missing submission, an apparent arithmetic error or a conflict. Give them a contact and a realistic deadline. Keep disagreement with a judge's professional assessment separate from an administrative error. You need a fair process that can operate in the time available, with written reasons for any correction.

Protect building time in the running order

The easiest way to weaken a paid hackathon is to fill it with things participants didn't come to do. Sponsor talks, welcome speeches and repeated announcements all use the same hours people need for their projects. Put the building sessions in first, then add the support that makes those sessions better.

Dockside's first day opens at 9 am. Welcome, challenge clarification and final team matching run until 10. Teams build from 10 until noon, take lunch until 1 pm, and build again until 5. A short progress check finishes at 5:30. The venue closes afterwards; overnight access and overnight work aren't part of the competition.

The sponsor's short demonstration fits within the first hour, with the relevant challenge information also available in writing. Optional sponsor introductions happen during lunch. Neither takes time out of the published building sessions, and participants can decline the introductions without affecting their entry or judging.

On day two, building resumes at 9 am and runs until noon. Lunch ends at 12:45, then teams have until 1:30 pm to finish and submit. That's nine hours and 45 minutes of scheduled building across both days. Teams don't continue working overnight between those periods under our example rules.

First-round judging runs from 2 until 3:40 pm. Finalists are confirmed after score checks, with the final session from 4 until 4:40. Four eight-minute slots take 32 minutes, leaving eight for resets. Results are scheduled for 5, followed by closing and departure. The technical team needs setup and pack-down time outside that public schedule.

Offer a clear mentor booking method during build periods. Publish specialisms and available appointments, with a host managing delays. Leave some access for urgent technical blockers, but don't promise unlimited personal help. A quiet team should have a fair way to request support without interrupting another team's session.

Use an event run-of-show to give each cue an owner. When submissions close, who freezes the accepted files, checks completeness and prepares the judges' list? Who tells a team its presentation room? Those handoffs need preparing as carefully as the opening announcement, especially when several things happen at once.

Work backwards through preparation as well. Before sales open, Dockside needs its checked terms, confirmed challenge, delivery budget and essential supplier arrangements. Before the financial decision date, it needs paid bookings, team allocations and the sponsor payment status. Before arrival instructions go out, it needs tested materials, mentor availability and a working submission method. Give each outstanding decision a person and a date tied to the supplier or buyer commitment it affects.

Make the venue and technical setup fit the work

Visit the venue with the actual tasks in mind. Participants need to hear announcements, talk in teams, charge equipment and reach help without abandoning their project. Judges need somewhere they can hear demonstrations. A room's headline capacity tells you little about those simultaneous activities.

Ask qualified venue and technical suppliers to check power, network demand and the planned layout. Tell them the number of people and devices, expected software downloads and any activities that depend on outside services. Our event Wi-Fi planning guide can help you prepare the supplier conversation and agree acceptance tests.

Rehearse with the actual submission and demonstration method. Test a participant laptop joining the network, opening the supplied materials and sharing a screen in each judging room. Check how a team submits evidence without exposing passwords. Agree who can authorize a fallback if a service fails and how staff will communicate it consistently.

Build accessibility into registration, teamwork and judging. The W3C checklist for accessible events covers preparation and participation across event formats. For this hackathon, review the accessible route to workspaces and judging rooms, written challenge instructions and ways to ask questions without relying only on spoken announcements.

Ask about access requirements early and provide a private contact. Discuss adjustments with the participant and make sure the competition process can support them. Explain arrangements to the relevant staff without sharing unnecessary personal details. If the rules or schedule need clarification to make participation fair, resolve that before arrival where possible.

Publish a conduct policy and a reporting route that covers participants, sponsors, mentors and staff. Assign someone who can respond while the technical lead keeps the event running. A participant reporting harassment shouldn't have to argue their case in front of the team or person involved. Brief staff on immediate support, emergency arrangements and when to involve the venue or appropriate services.

Prepare submissions, privacy and failure decisions in advance

A short submission form makes judging easier if it asks for the right information. Dockside collects the team name, members' names or registration IDs, challenge response, demonstration link or file, relevant prior work, important third-party components and the permissions needed for assessment. Public project-listing choices are handled separately.

Ask only for information you have a defined reason to use. The UK's ICO guidance on data minimisation says personal data should be adequate, relevant and limited to what's necessary; its guidance is currently under review following legislative changes. Check the rules that apply to your participants and explain your purposes, access and retention arrangements.

Keep access appropriate to the job. A judge needs the submission and relevant eligibility information, not someone's dietary request or private complaint. A sponsor report can describe attendance and delivered benefits without including individual contact details. Decide how optional introductions work and avoid treating ticket purchase as blanket permission for future marketing.

Prepare a few failure decisions before the weekend. If the organizer's submission system fails, staff need an approved alternative and a way to tell every affected team. If one team's laptop fails, the response may differ. Your published policy should explain who assesses the situation, what evidence they need and how any adjustment preserves fair treatment.

Use the same care for missing teammates. A team of four losing one member may remain eligible; a team of two losing one falls below Dockside's minimum. Decide whether a transfer or team change can be approved before the relevant cutoff. Update the member record and permissions, and tell the team what happens if no suitable change is possible.

For suspected rule-breaking, preserve the relevant records, hear the participant's explanation and apply the stated process. Don't announce an allegation as a finding while staff are still checking it. Keep any decision proportionate, documented and limited to people who need to know. Public accusations are a poor substitute for administering your own rules carefully.

Finish the event by delivering what remains owed

Closing the venue doesn't complete the organizer's work. Send the promised feedback, confirm winners' details and arrange prizes under the published terms. Dockside's fictional $2,000 prize budget is split into team awards of $1,200, $500 and $300. These are total awards to the respective teams, not amounts for every member.

Check that the payment arrangement matches each team's recorded decision and any applicable identity, tax or reporting requirements. Confirm who is handling it and when the team should expect payment. If you need additional information, request it through the appropriate private process rather than collecting financial details in a public event chat.

Publish only the project materials you have permission to share. Send teams the proposed listing where approval is part of your process. Check names, credits and links, and remove credentials or sensitive information before anything becomes public. Winning an award doesn't grant the organizer every possible future use of the work.

Then compare the event you delivered with the offer people bought. Did every eligible team receive its demonstration slot? Did mentor demand exceed the available appointments? Did participants understand the rights terms before arriving? Separate those answers from whether the winning projects looked impressive in a highlight video.

Reconcile actual ticket income, sponsor receipts, refunds, supplier costs, charges and prizes. Include unpaid obligations and your organizing time. If you gave away places or applied discounts, use the amount actually collected rather than multiplying attendance by the headline price. That shows whether another edition can support the same experience at the same price.

Before opening the next event, fix the most consequential gap. If team matching caused delays, change the registration process. If judging overran, reduce project capacity or add properly staffed assessment time. If participants were unsure who could use their work, rewrite the explanation and have the terms checked before another buyer pays.