How to Win Unfair Weekend: Build Less, Prove More

The winning project at Unfair Weekend will not simply be the coolest idea or the longest feature list.

It will be the project that creates the most belief.

Belief that the problem matters. Belief that the solution works. Belief that the team made difficult choices and executed them well. Belief that users could care. Belief that the small thing shown on Demo Day could become something much bigger.

A weekend is short, but the signal can be strong.

You can show a working product. Complete a real task. Test the hardest technical assumption. Put the product in front of users. Get a pilot commitment. Measure whether someone changes their behavior. Discover that your first idea was wrong and improve it.

That is what wins: not building more, but proving more.

Know What You Are Trying to Win

Unfair Weekend projects are judged on:

• •originality
• •functionality
• •design and user experience
• •technical execution
• •real-world impact or business potential

Treat these as five different questions your project must answer.

1. Originality: What Is Your Thesis?

Originality does not require inventing a category nobody has seen before.

It requires a specific belief that is not obvious from the category alone.

Weak:

An AI receptionist for appointment-based businesses.

Stronger:

A crash-test lab for voice receptionists. It calls an agent with 100 difficult booking scenarios, detects policy violations and double-bookings, and shows the exact conversation turn where the agent should have escalated.

The second version contains a thesis: deploying agents will become easy faster than trusting them becomes easy. It also has a credible reason to exist now. By March 2026, ElevenLabs reported that more than two million voice agents had already handled 33 million conversations that year. (Source)

It tells judges what the team believes, what changed recently, and what the product is designed to prove.

Ask:

• •What do we believe that the default products in this category miss?
• •Why does this work differently?
• •What will judges remember after seeing ten other demos?

Borrow the Shift, Not the Announcement

Dropping the name of a new model into a pitch does not make a project original. The interesting question is what becomes newly possible, newly necessary, or newly broken because the capability exists.

Weak: "We use managed agents to automate office work."

Stronger: "We give every agent action a before-and-after receipt, risk-based approval, and reversal path. The product exists because agents can now work for longer and act across real tools, but accountability has not caught up." (Why now: managed agents, May 19, 2026)

Weak: "We translate training videos."

Stronger: "A supervisor records one machine procedure. The product turns it into multilingual practice drills, preserves the supervisor's urgency, and checks a learner's video for skipped safety steps." (Why now: performance-preserving dubbing, May 28, 2026)

Weak: "We built an AI search engine for grants."

Stronger: "A funding-change radar continuously monitors selected European programs, proves exactly what changed, identifies which studios became eligible, and prepares the next action before the deadline." (Why now: information agents, May 19, 2026)

Weak: "We detect AI-generated media."

Stronger: "A provenance passport shows who consented to the original voice and likeness, every generated or dubbed derivative, where each version may be used, and what must disappear when consent expires." (Why now: multimodal generation and editing, May 29, 2026)

Notice the pattern: the stronger projects are not thin showcases for the new capability. They solve the second-order problem created by it.

2. Functionality: Does the Core Journey Actually Work?

A functional project is not a screen for every future feature. It is one important journey that works from beginning to end.

Choose your golden path:

A user arrives with this problem, takes these actions, and leaves with this outcome.

Build that path first. Cut anything that does not make it clearer or more convincing.

A narrow, complete workflow beats a broad product full of dead buttons. Judges should not have to imagine the value from mockups or architecture slides. They should see the product perform the job.

Ask:

• •What is the single most important outcome?
• •Can a judge or user complete it live?
• •What breaks when the input is messy or unexpected?

3. Design and UX: Can People Understand It Without You?

At Demo Day, clarity is a competitive advantage.

Good design is not decoration added after the build. It is how quickly someone understands what to do, what happened, and why the result matters.

The strongest demos have:

• •a short path to value
• •an obvious before and after
• •clear system status and feedback
• •useful outputs rather than walls of generated text
• •enough polish to feel intentional
• •a moment people want to photograph, share, or try themselves

Test the product with someone who has not heard the pitch. Stay quiet. Watch where they hesitate.

If the interface requires a founder narrating every click, it is not clear yet.

4. Technical Execution: What Difficult Thing Works?

Using advanced technology is not the same as demonstrating technical execution.

Judges need to see what was difficult, why it mattered, and how your team handled it.

That difficulty might be:

• •proving an agent completed the job without causing collateral damage
• •preserving a reliable action history across several tools
• •comparing changing source documents and explaining consequential differences
• •grounding a generated training step in the exact moment of a source video
• •preserving consent and usage rights across transformed media
• •making a system recognize uncertainty and hand control to a human

Do not bury the hard part in an architecture diagram. Put it in the demo.

Show the messy input. Show the system working. If possible, show how it handles failure.

5. Impact or Business Potential: What Did You Learn From Reality?

Big market numbers are easy to find and easy to forget.

Stronger teams reduce uncertainty.

They find out whether the problem is real, whether the user cares, whether the workflow works, and whether the offer is understandable.

Not all evidence is equal.

The Evidence Ladder

From strongest to weakest:

1. A user paid, returned, referred someone, or repeatedly used the product.
2. A real user completed the core workflow and received the intended result.
3. A potential customer made a concrete pilot or purchase commitment.
4. Users changed their behavior because of the product.
5. Target users shared data, time, access, or detailed workflow feedback.
6. Interviews consistently confirmed the problem.
7. Relevant strangers joined a waitlist or responded to a specific offer.
8. Friends said the idea sounded cool.

A waitlist is evidence of curiosity, not proof of demand. Interviews are useful, but behavior is stronger than compliments. One real completed workflow can be more convincing than one hundred vague signups.

Ask:

• •What is the riskiest assumption behind this project?
• •What can we do this weekend to test it?
• •What evidence would change our own minds?

Build the Demo Backwards

Do not wait until the product is finished to decide how to present it.

Imagine the strongest 60 seconds of your demo first.

What goes in? What changes? What comes out? Why is the result surprising or valuable?

Then build the minimum product required to make that moment real.

A convincing demo usually has:

1. A recognizable problem: The audience understands the pain immediately.
2. A live input: Something real, messy, or specific enters the product.
3. Visible work: The product does more than generate a paragraph.
4. A useful result: The audience can judge whether the outcome is good.
5. Proof: You show that someone used it, wanted it, or benefited from it.

The demo should carry the argument. Slides should help people understand what they just saw, not replace it.

A particularly strong demo reveals something the audience could not see before: the moment an agent silently broke a rule, the exact safety step a learner skipped, the sentence in a policy that changed someone's eligibility, or the consent chain behind a generated clip.

A Better Weekend Strategy

First Hours: Choose the Bet

• •Name the first user.
• •Write the problem in one sentence.
• •Define the golden path.
• •Identify the riskiest assumption.
• •Decide what evidence you want before Demo Day.
• •Sketch the demo moment.

If the team cannot agree on these, more building will not fix the confusion.

Middle of the Weekend: Make the Hard Thing Work

• •Build the end-to-end path before adding breadth.
• •Put realistic inputs through it.
• •Show rough versions to target users.
• •Cut features that do not strengthen the judging criteria.
• •Record evidence as you go.

Do not confuse activity with progress. A new settings page is probably less valuable than fixing the core result.

Final Stretch: Make the Value Obvious

• •Remove broken or distracting features.
• •Test the complete demo repeatedly.
• •Improve speed, feedback, and error handling.
• •Let a new person try the product without instructions.
• •Prepare a backup recording without replacing the live demo.
• •Turn what you learned into a clear story.

Polish the path judges will actually see.

How to Pitch

A good pitch is not a feature tour and not a miniature investor presentation.

It should quickly answer:

1. Who has the problem?
2. Why does it matter?
3. What did you build?
4. What is original or technically difficult about it?
5. What did you prove?
6. What could this become?

Show the product early.

A simple structure:

Problem: Show the painful moment.

Thesis: Explain what your team believes others miss.

Demo: Let the product perform the core job.

Execution: Reveal the hard part and how you solved it.

Proof: Show what happened when reality touched the project.

Future: Explain the larger opportunity without pretending you already built it.

What Usually Loses

Too Broad

"AI for productivity." "AI for education." "A platform for small businesses."

These describe markets, not products.

Too Familiar

The team builds a common hackathon idea and assumes adding AI makes it original.

Too Much Surface, No Core

The product has dashboards, profiles, settings, analytics, and a pricing page, but the main workflow barely works.

A Dashboard That Does Not Act

It describes the problem beautifully and leaves the user to solve it.

Fake Enterprise

The team claims to build for banks, hospitals, governments, or global logistics companies without understanding the buyer, regulations, workflow, or data.

Weak Proof

Friends joined a waitlist. An Instagram poll got likes. Nobody from the target audience used the product.

Invisible Technical Work

The team solved a difficult engineering problem but never makes it understandable or visible to judges.

A Demo That Requires Imagination

The pitch explains what the product will eventually do instead of showing what it does now.

The Final Checklist

Before you present, ask:

• •Can someone understand the value in 60 seconds?
• •Is there a specific, memorable thesis?
• •Does the core journey work end-to-end?
• •Is the experience clear without constant explanation?
• •Can judges see what was technically difficult?
• •Did we test the riskiest assumption?
• •Do we have evidence beyond our own enthusiasm?
• •Is there a moment that makes people think, "Wait, this could be big"?

The winning project will not necessarily be the biggest idea on paper.

It will be the project that makes the strongest small thing undeniably real.

Build less. Prove more. Make everyone else believe.

Recommended Reading

• •Building the Agentic Future: Google I/O 2026 Developer Highlights - recent context for judging whether an agent idea is genuinely newly possible
• •Introducing ElevenLabs Agents - useful evidence that agent reliability and testing are current product problems
• •Devpost's Guide to Judging and Public Voting - a useful explanation of how idea quality, implementation, and impact become judging criteria
• •Practical Design: User Observation by Y Combinator - a concise guide to learning by watching real users
• •How to Pitch Your Company by Y Combinator - practical advice on making the product understandable
• •They Built a $60,000 Focus Group for $6 - an Unfair Weekend example of combining a clear thesis, difficult execution, and a memorable demo