Build hackathon demo data without copying real identities

Build hackathon demo fixtures from invented records. Keep the scenario useful without copying real identities into a repository, presentation or screenshot.

A convincing demo needs meaningful relationships: a task belongs to a team, an order has line items, a comment has an author. It rarely needs somebody's actual email, photograph or account history. Start with the smallest invented dataset that demonstrates the action you plan to show.

Define the fixture before generating records

Write three requirements in plain language. For a fictional task board, you might need two teams, one completed task and one task that nobody owns. These describe application behavior. They do not require a production export.

Give each record a stable identifier and keep the fixture in a separate file. A teammate should be able to recognize it as demo input without tracing the origin of every field.

{
  "fixture": "fictional-task-board-v1",
  "people": [
    { "id": "demo-person-1", "name": "Demo Member A", "email": "[e-mail]" }
  ],
  "tasks": [
    { "id": "demo-task-1", "ownerId": "demo-person-1", "done": false },
    { "id": "demo-task-2", "ownerId": null, "done": true }
  ]
}

IANA maintains example.com and example.org for documentation. Use those reserved domains for illustrative addresses. Their web services are best effort, so the demo must not depend on sending mail or making requests to them. Stub that action or show a clearly named local preview instead.

Keep the behavior, replace the identity

If your scenario needs a long name or duplicate display names, invent those cases deliberately. If it needs a non-Latin label, add a fictional label that exercises the rendering. Copying a real record and changing only the name leaves the other fields untouched. Create the whole fixture from your requirements instead.

Avoid borrowed avatars, real addresses and free-text notes from another system. These fields can reach screenshots and console output even when they are absent from the main screen. Review the fixture, browser display and intended submission files together.

Rehearse the exact action

Load the fixture and assign the unowned task. Check that the visible owner changes to Demo Member A and that the completed task remains completed. Reload or reset using the project's documented demo procedure, then repeat the same action. Record the fixture identifier beside the submitted commit so a teammate can reproduce your starting point.

Keep fixture storage separate from any service that sends messages or creates real accounts. Synthetic input does not prevent side effects if the app still calls a live integration.

When choosing a challenge in the Stavleak hackathon catalogue, read its data requirements before building the fixture. If the event provides a dataset, follow that event's access and submission rules. This task-board fixture is an educational example, not event data or a customer record.