For hackathon builders, from a first attempt to an existing project

Make the demo clear. Give the project a next chapter.

Your build, submission and public update should tell one coherent story. Capture a few meaningful checkpoints, show what actually works and leave judges, peers or potential users with a clear way to understand the project and continue after the event.

Try the participant journeyOpen the full workspace

Participants · solo or team · your event’s own rules

No sign-in required. A fictional example with decisions and drafts you can change.

  1. Before: choose the question
  2. During: show what works
  3. After: keep the next step

Organizing a hackathon?

Explore a hackathon partnership

Make it your example

Make the working demo easy to understand.

Set the brief, respond to a build setback, prepare the story and choose the test you want after the event.

What you can prepare

A project story, a demo explanation and a specific tester invitation.

Interactive example · no account required

Continue in the full studio ↗

This workspace is saved in this browser. Imported files remain on this device. No social account is connected.

No sign-in required. Progress stays in this browser; nothing is submitted or published.

The guided workspace currently uses English. You can prepare content in English or French.

Concrete work to prepare

A useful story, with somewhere to go next.

Check whether a reviewer can describe the working path and remaining limit. Track submission readiness, time spent communicating and any agreed follow-up. A completed draft is not a submitted entry, an award or evidence of product demand.

A project brief and event checklist

The problem, audience, existing work, event constraints, separate deadlines and the person responsible for review and submission.

A demo and submission pack

A concise project description, a working-path demo outline, permitted visuals and the relevant links, with public updates adapted from the same evidence.

A recap and owned follow-up

What worked, what changed, the limits, relevant feedback and a chosen next action with an owner and date.

The friction

A good build can become a rushed explanation.

Near the deadline, the project has changed, screenshots are scattered and the person writing the submission is still asking what works. The interesting decisions and the limits of the demo can disappear in the rush.

Help someone understand the demo quickly

Lead with a real problem and show one working path. Make the input, result, current limits and contribution during the event easy to identify.

Prepare a coherent submission and public story

Reuse the brief, selected evidence and demo outline across the required submission fields and appropriate public formats. Confirm the event’s requirements before submitting.

Give useful attention somewhere to go

Offer an available demo, a project page or a specific follow-up test. Keep the resulting questions with the project so the conversation can continue after judging.

Why Tellshift

Keep the explanation ready while the build changes.

  1. Explain the same work to different people

    Prepare a concise demo for judges, a useful public update for peers and a specific invitation for potential users. Each version keeps the same source facts and current limitations.

  2. Capture the turning points as they happen

    A working slice, a failed integration or a changed assumption can explain the project better than a final screenshot. Keep a short record at natural checkpoints, within the time you reserved for communication.

  3. Leave with something you can use afterward

    Reuse the demo explanation in a project page or portfolio, keep the feedback and choose the next test. An event can become the first chapter of a longer project—or a documented decision to stop.

The workflow, roles and pace

Who this is for

Solo participants and teams entering an in-person, online or longer-running hackathon. Bring a new idea or the permitted context from an existing project. Check the event’s rules on prior work, team eligibility, public sharing, required formats and deadlines before choosing the plan.

A first useful result

A project brief and event checklist

The problem, audience, existing work, event constraints, separate deadlines and the person responsible for review and submission.

Prepare the attempt, capture the change, show the result, choose the next step

  1. Before: set the brief and event constraints

    Record the audience, problem, team roles and what you hope to demonstrate. Check the rules, distinguish existing work from event work, and record build, submission and demo deadlines with their time zone.

  2. During: keep a small evidence trail

    Capture a permitted screenshot or short note when something meaningful changes. Mark working behavior, simulated data and unfinished pieces. Update the plan when the scope changes.

  3. Demo: assemble the submission-ready explanation

    Start with the working path, explain the problem and show the result. Prepare the project description, demo outline and links. Rehearse, allow upload time and check the actual submission page against the event’s requirements.

  4. After: make the follow-up concrete

    Record what was built, what changed and which questions remain. Choose a tester conversation, next release, portfolio recap or a pause. Assign an owner and a date to any follow-up you commit to.

Fit the story around your event and your build

Start with the smallest useful capture

A brief, a checkpoint note and one demo artifact are enough to begin. Add a richer source history when it helps; preparing a public update should not consume the time needed for the submission.

No working demo yet?

Explain the attempt, the blocker and the next experiment honestly. Choose whether that is useful to share. A draft can stay private, and a missed checkpoint does not require a replacement post.

Already building this project?

Carry forward the project context while keeping event contributions explicit. Apply this event’s eligibility and prior-work rules; the ongoing public story can continue after the event ends.

A method you can use now

Prepare a hackathon story that carries beyond the demo

Build a clear project summary, a working-demo script and a useful follow-up around your event’s actual rules and deadlines.

Read the guide and copy the templateUnderstand the inputs

A first project

Bring the event. Keep the focus on the build.

Use the interactive participant example, then bring your event rules, dates and project brief. We will agree the outputs, review responsibilities and the attention you can reserve.

What a first pilot would include

  • A project brief and event checklist

    The problem, audience, existing work, event constraints, separate deadlines and the person responsible for review and submission.

  • A demo and submission pack

    A concise project description, a working-path demo outline, permitted visuals and the relevant links, with public updates adapted from the same evidence.

  • A recap and owned follow-up

    What worked, what changed, the limits, relevant feedback and a chosen next action with an owner and date.

Prepare my hackathon pilot

Proposed starting scope: one team, one event and the reviewers you choose. Agree the outputs, communication budget, manual preparation and any service price in advance. Your event’s rules govern eligibility and submission. The interactive example does not submit an entry, connect accounts or publish.

As your context changes