DEV Community: Hackathon Raptors

Dogfood 2026: Build the Platform That Will Judge You

Raptor — Thu, 03 Sep 2026 12:53:38 +0000

Most hackathons ask you to build whatever you want.

Dogfood 2026 does the opposite.

Everyone builds the same thing: a submission and judging platform for hackathons.

The challenge is simple:

Build the platform that will judge you.

And there is a reason this is more interesting than it sounds.

Hackathon Raptors has run 35 hackathons across 85+ countries since 2023. They have seen the same problems appear again and again: registrations, teams, submissions, judge assignments, scoring, normalization, results, certificates, and exports all becoming separate pieces of an increasingly messy workflow.

Now they want to build the platform they actually wish they had.

That is what Dogfood is about.

About the Hackathon

Dogfood 2026 is a 72-hour online hackathon organized by Hackathon Raptors.

The event runs from September 25 to September 28, 2026.

At a glance

🌍 Online and global
⏳ 72 hours
💰 $2,500 prize pool
👥 Solo or teams of up to 4
💸 Free to participate
🔓 Open source
🐳 Self-hosted
🛠️ Build with the stack of your choice

But this is not a normal platform-building challenge.

The winning project is intended to be forked, self-hosted, and used for actual Hackathon Raptors events.

So instead of building a demo that gets abandoned after the weekend, you are building something that could become real infrastructure.

Why Build Another Hackathon Platform?

Hackathon platforms already have most of the features organizers expect.

Registration.

Team formation.

Project submissions.

Public galleries.

Judge scoring.

Community voting.

Organizer dashboards.

CSV exports.

So what is missing?

The difficult part is not building another CRUD application.

The difficult part is making the entire system reliable when real people start using it.

Consider judging.

Two judges can look at the same project and give completely different scores. One might give almost everything a 4 or 5. Another might rarely give anything above a 3.

Simply averaging those scores can produce a ranking that reflects the judges' scoring habits instead of the quality of the projects.

Then there is access control.

A judge should see the projects they are assigned to.

They should not see another judge's scores.

They should not see another track's submissions.

And hiding those things in the frontend is not enough.

If a judge can make an API request and retrieve another judge's ballot, the system has failed.

These are the problems Dogfood wants teams to solve.

Running a Hackathon Is a Data Problem Wearing a Party Hat

A hackathon looks simple from the outside.

Someone registers.

Teams form.

Projects get submitted.

Judges score them.

Winners are announced.

Behind that simple flow is a much larger pipeline:

Registration
Teams
Submissions
Eligibility
Judge assignment
Scoring
Normalization
Results
Certificates
Archive

Each stage has its own state and data.

Each stage feeds the next one.

If something goes wrong, the problem eventually reaches judging.

And judging is the part participants actually care about.

Dogfood asks you to build the system that manages this entire lifecycle.

The Tier Ladder

There are no tracks in Dogfood.

There is one product and four tiers.

The goal is to climb the ladder while keeping everything you build correct.

T1: Core

T1 is the foundation.

A submission that does not clear T1 is not judged.

You need:

Authentication and sessions
Visitor, participant, judge, organizer, and admin roles
Event creation
Configurable dates, tracks, and prizes
Team formation through invite links
Project submission
Draft and edit support until the deadline
Actual deadline enforcement
Public project gallery
Search and filtering

The submission system should support the usual project information:

Project name
Tagline
Long description
Thumbnail
Image gallery
Demo video URL
Repository URL
Live link
Technology tags
Track
Organizer-defined custom questions

This is the minimum.

It is not the target.

T2: Judging

This is where the interesting engineering starts.

T2 requires:

Judge invitations
Judge assignments
Batch or algorithmic assignment
Weighted judging rubrics
Backend-enforced role isolation
Judge progress tracking
Cross-judge score normalization
CSV exports

The weighted rubric is especially important.

Organizers should be able to define criteria and give those criteria different weights.

More importantly, the backend needs to enforce who can see what.

A judge should never be able to access another judge's scores.

A track judge should never be able to access another track's data.

If the only protection is a hidden frontend button, it does not count.

The authorization needs to hold up when someone calls the API directly.

T3: Public

T3 focuses on community participation.

This includes:

Community voting
Configurable voting access
Open-link voting
Email-gated voting
Authenticated voting
Comments on projects
Hidden results during the voting window
Randomized project ordering
Rate limits
Duplicate detection
Readable audit trails

You can also go beyond one-person-one-vote.

The brief mentions quadratic voting as one possible approach, but teams are free to implement something else if they can defend it.

The important question is not whether you added a voting button.

It is whether you thought about how people can abuse the voting system and what your platform does about it.

T4: Stretch

T4 turns the platform into something closer to infrastructure.

The requirements include:

REST API
Webhooks
API access for UI actions
Certificate generation
Record generation
Signed and publicly verifiable judge participation records
Embeddable gallery widget
Bulk import and export

T4 is optional.

Do not sacrifice a working T2 just to claim T4.

The organizers are very clear about this:

A clean, correct T2 is better than a broken T4.

What Counts as Done?

This is probably the most important requirement in the entire hackathon.

Your project needs to run locally.

The expected experience is simply:

docker compose up

The application should start with seeded fixture data.

No cloud account.

No hosted database.

No external authentication provider.

No external API.

No signup just to get the application running.

The organizers should be able to run your project with the network turned off.

That requirement exists for a reason.

The winner is supposed to be adoptable.

A project that depends on five external services is not something an organizer can simply clone and run.

The acceptance suite will run against your application and produce a tier by tier pass report.

That report becomes the evidence for the tier you claim.

If you claim T3 but the acceptance suite only confirms T2, you get scored at T2.

Honest scope is explicitly preferred over inflated claims.

What You Submit

A serious submission should contain something like:

your-portal/

├── README.md

├── ARCHITECTURE.md

├── DATA-MODEL.md

├── JUDGING.md

├── docker-compose.yml

├── src/

├── tests/

├── acceptance-report.txt

├── LICENSE

└── .dogfood.toml

You will submit:

A public GitHub repository
An OSI-approved open source license
A working portal
One-command startup
The acceptance report
README documentation
Architecture documentation
Data model documentation
Judging documentation
A 5-minute demo video

The documentation is not an afterthought.

ARCHITECTURE.md should explain how your system fits together and why you made those decisions.

DATA-MODEL.md should explain your schema and how data moves in and out.

JUDGING.md should explain judge assignment, scoring, and normalization.

"We averaged the scores" is technically an answer.

It is also a pretty weak one.

How the Projects Are Judged

The final score uses four weighted criteria.

Tier Completion & Correctness: 40%

How far did you actually get?

The acceptance suite verifies the functionality rather than relying on what you claim in your README.

Getting fewer features working properly is better than getting more features half working.

Judging Integrity: 25%

This is the hardest part of the platform.

Judges will look at things like:

Backend role isolation
Judge assignment
Score normalization
Audit trails
Vote abuse prevention
Whether your judging approach is documented and defensible

Adoptability & Operability: 20%

Could Hackathon Raptors actually run this?

That means:

One command to start
Seeded data
Clear documentation
Local operation
Import and export
No hosted-service dependency
A clean open source license

Code Quality & Innovation: 15%

Does the code look maintainable?

Is the schema sensible?

Are the APIs designed properly?

And did you make a technical decision that makes someone think:

"I would steal that."

Bonus Challenges

There are four optional bonuses.

Normalization Proof: +5

Implement cross-judge score normalization and demonstrate it using the provided fixture data.

Show the raw scores.

Show the normalized scores.

Show how the rankings changed.

Then explain the mathematics well enough that someone with a statistics background can understand and challenge it.

Pairwise Mode: +5

Instead of asking a judge to give a project an absolute score, show them two projects and ask which one is better.

Then use a Bradley-Terry style estimator to recover a global ranking.

This is based on an approach used by Gavel and is one of the more interesting technical directions in the brief.

It is also hard to get right.

Threat Model: +3

Write a proper threat model for voting and submission abuse.

Think about:

Sybil votes
Ballot stuffing
Submission scraping
Judge collusion
Deadline manipulation

Be honest about what your system prevents and what it does not.

API First: +3

Make every action available through a documented API.

Publish an OpenAPI specification.

If you design the application around the API from the start, this is much easier than trying to bolt an API onto the finished product.

The 72-Hour Strategy

Trying to build everything is probably the fastest way to build something mediocre.

You have 72 hours.

The scoring strongly rewards correctness, so the sensible approach is:

T1 → solid T2 → one strong differentiator → bonuses → polish

Get authentication and authorization right.

Get the data model right.

Get submissions and deadlines right.

Then spend serious time on judging.

If the judging engine is genuinely good, you already have a strong submission.

If you have a team, split the work around system boundaries.

One person can focus on the core platform.

Another can own the judging engine.

Another can work on public voting and the API.

Another can handle infrastructure, testing, and documentation.

The exact division does not matter as much as making sure someone owns each major area.

For a solo participant, scope matters even more.

A very strong T1 and T2 is a realistic goal.

Trying to ship every T4 feature alone in 72 hours is probably not.

The Interesting Engineering Problems

At first glance, Dogfood looks like a CRUD application.

It isn't.

The CRUD part is the easy part.

The interesting engineering is elsewhere.

Authorization

Can your permission model survive a direct API request?

You need to reason about relationships between users, roles, events, tracks, assignments, projects, and ballots.

A frontend permission check is not enough.

Judge Assignment

Imagine 40 projects, 30 judges, and three reviews per project.

Now add constraints.

Judges can belong to specific tracks.

Some judges may have conflicts of interest.

Workloads should be balanced.

Every project needs enough independent reviews.

This becomes an actual assignment problem.

Score Normalization

Different judges use scoring systems differently.

One judge might give 4 and 5 to almost everything.

Another might treat a 4 as an exceptional score.

A simple average does not necessarily solve that problem.

Your normalization method needs to account for judge behavior while remaining understandable and defensible.

Voting Abuse

"One account, one vote" sounds good until someone creates hundreds of accounts.

Now you have to think about:

Rate limits
Duplicate behavior
Suspicious voting patterns
Audit logs
Account behavior
False positives
Privacy

You do not need to solve every voting attack in existence.

You do need to show that you understand the problem.

Offline Operation

The platform needs to work without relying on someone else's infrastructure.

The ideal architecture is something an organizer can clone and run locally.

Not:

Frontend → Hosted Auth → Cloud Database → External API → Five SaaS Services

More like:

Docker Compose → Application → Local Database

Simple enough that another engineer can actually operate it.

AI Tools Are Expected

AI coding tools are allowed.

The brief explicitly mentions tools such as:

Claude Code
Cursor
Aider
GitHub Copilot
Local models
Other AI coding assistants

The organizers are not interested in policing whether you used AI.

They care about the result.

A generated CRUD application is not particularly impressive anymore.

A system with proper authorization, a defensible judging model, a sensible schema, reliable deployment, good tests, and documentation that the team can actually explain is much harder.

Use AI to move faster.

Just make sure you understand what you ship.

Important Dates

Event	Date
Registration Opens	August 24, 2026
Judging Panel Announced	September 4, 2026
Team Formation	September 21, 2026
Specification Published	September 24, 2026
Hackathon Kickoff	September 25, 2026 at 18:00 UTC
Code Freeze	September 28, 2026 at 18:00 UTC
Judging Window	September 28 to October 8, 2026
Winners Announced	October 9, 2026

The official event website and Discord should be treated as the source of truth for any future changes.

Prize Pool

Dogfood 2026 has a $2,500 total prize pool.

There are prizes for the top projects, along with a Best Judging Engine prize and the Write Up Quest.

But the most interesting part of the prize is what happens after the hackathon.

The winning project is intended to be forked, self-hosted, and used for Hackathon Raptors events.

The team keeps ownership of its repository.

There is no assignment, transfer, CLA, or exclusivity clause.

The organizers also intend to send improvements and hardening work back to the winning repository.

That makes this feel less like building a throwaway hackathon project and more like contributing to an actual open source product.

Who Should Join?

Dogfood is a good fit for:

Full-stack developers
Backend engineers
API engineers
DevOps engineers
Security engineers
Data and algorithms enthusiasts
Frontend and UX developers
Developers interested in open source
Students who want to work on a serious engineering problem

If you like building systems where the boring details actually matter, there is a lot to dig into here.

Authentication.

Authorization.

Data modeling.

Assignment algorithms.

Statistics.

APIs.

Security.

Testing.

Deployment.

Documentation.

All inside 72 hours.

Why This Hackathon Is Different

Most hackathons ask:

What can you build in 72 hours?

Dogfood asks:

Can you build something another engineering team would actually be willing to operate?

That changes everything.

A flashy landing page will not fix broken judge isolation.

A beautiful dashboard will not fix bad normalization.

A huge feature list will not matter if docker compose up fails.

The strongest project will probably be the one that feels boring in the best possible way.

It works.

It is secure.

The data model makes sense.

The judging system is explainable.

The tests pass.

The documentation is clear.

Someone who did not build it can run it.

And when the organizers look at it, they can imagine using it for their next event.

Final Thoughts

Dogfood 2026 is not another "build whatever you want" hackathon.

There is one product.

There is one specification.

There is a 72-hour deadline.

And there is a very clear definition of done.

Build the core.

Make judging trustworthy.

Enforce permissions in the backend.

Think seriously about normalization.

Make the application work offline.

Document the decisions you made.

Then use whatever time remains to build something clever.

The strongest submission probably will not be the one with the most features.

It will be the one where a judge can clone the repository, run docker compose up, look at the seeded application, and think:

"We could actually run our next hackathon on this."

Join Dogfood 2026

🌐 Website: https://dogfoodhack.com/

💬 Discord: https://discord.gg/xfYPDZYqeh

🦖 Hackathon Raptors: https://raptors.dev/

📅 September 25 to 28, 2026

💰 $2,500 Prize Pool

💸 Free to Participate

Build the platform that will judge you.

Zero Dependency 2026 — Build Real Software With No Packages. Prove It.

Raptor — Sat, 08 Aug 2026 12:19:33 +0000

Half your code is now written by an AI that hallucinates the other half's package names.

That's not a joke. Across 576,000 samples, 19.7% of the packages AI coding models suggested didn't exist — and attackers have started pre-registering those exact hallucinated names, waiting for someone to npm install a package that was never real to begin with.

Meanwhile, public registries catalogued 454,600 new malicious packages in 2025 alone, pushing the cumulative total past 1.2 million. A modern web app now pulls in 1,200+ dependencies once you count the full transitive tree — for software that, ten years ago, would have shipped with a fraction of that.

That's precisely what Zero Dependency 2026 is about.

Organized by Hackathon Raptors, Zero Dependency is a 72-hour online global hackathon where participants build genuinely useful software — CLIs, parsers, servers, databases, security tools — using nothing but their programming language's standard library. No frameworks. No packages. No supply chain to inherit. Just your language and your engineering skill.

Why Zero Dependency?

Modern AI coding assistants can generate code fast, and they reach for a dependency by reflex — sometimes one that doesn't exist.

But real engineering isn't judged by how many packages you imported. It's judged by questions like:

Do you actually understand what the library you'd normally import is doing underneath?
Can you build the thing yourself, correctly, from primitives?
Does your code handle the edge cases a package would've handled for you?
Is the implementation idiomatic, or a fight against the standard library?
Could a judge verify your dependency manifest is empty in five seconds?

Zero Dependency is designed around these questions.

Instead of rewarding whoever pulls in the most packages the fastest, the hackathon rewards teams who can prove they didn't need to.

About the Hackathon

🌍 Global Online Hackathon
⏳ 72 Hours
💰 $1,800 Prize Pool
👥 Solo or Teams of up to 4
🎓 Open to students, professionals, researchers, and developers worldwide
💸 Completely Free to Participate

Whether you're a backend engineer, a tooling/DX person, a security engineer, a database-curious systems programmer, or just someone who's felt something die inside after npm install-ing a one-line function — Zero Dependency offers a genuinely different kind of challenge.

What You'll Build

Every participating team will:

Pick one of six tracks.
Define a real problem worth solving.
Design and implement the solution using only their language's standard library.
Test the implementation against real edge cases.
Document every technical decision and trade-off.
Verify the final artifact has zero third-party runtime dependencies.
Submit a working demo and full dependency proof.

Unlike many hackathons, success isn't determined by flashy pitches.

The emphasis is on functionality, honest craft, idiomatic code, and a dependency manifest a judge can verify at a glance.

Six Tracks

Track A — Developer Tools & CLI
Linters, formatters, task runners, git utilities, file utilities. The daily-driver tools most people reach for a dozen packages to build.

Track B — Parsers & Data Formats
JSON/CSV/Markdown/config parsers, template engines, regex engines, serializers. The things everyone imports and almost nobody has written.

Track C — Web & Network
HTTP servers, routers, clients, static-site servers, DNS tools, raw TCP chat apps. Built on stdlib networking primitives alone.

Track D — Data & Storage
Key-value stores, embedded databases, caches, log-structured stores, search indexes. The layer most apps rent from a library and never look inside.

Track E — Security & Crypto Utilities
Password managers, TOTP/2FA generators, file encryptors, hashers, secrets scanners. Compose trusted stdlib crypto primitives correctly — never roll your own cipher.

Track F — Open / Wildcard
Games, visualizers, interpreters, compression tools, schedulers — anything genuinely useful that a reasonable engineer would assume needs packages. Justify the build in your README.

What Counts as "Zero Dependency"

The one rule that defines the event: zero third-party runtime dependencies.

JavaScript / TypeScript — Node/Deno/Bun built-ins only. package.json dependencies is {}.
Python — standard library only. No pip install.
Go — stdlib only. go.mod has no require block.
Rust — std only. Cargo.toml [dependencies] is empty.
C / C++ — libc and POSIX only. No vendored third-party libraries.
Java / Kotlin / C# — platform standard library (JDK/BCL) only. No Maven/NuGet runtime deps.

Your compiler, build tool, and a stdlib test tool are fine. If your language ships no test framework at all, a dev-only test dependency is allowed — but it must never ship in the artifact, and it must be disclosed in STDLIB.md.

Vendoring a library's source into your repo to fake an empty manifest still counts as a dependency. Disclose it, or it scores against you.

Submission Requirements

Each team must submit:

Public GitHub Repository
Working Implementation
One-Command Build Instructions
Empty Dependency Manifest
Dependency Proof (command output or CI log showing zero third-party deps)
README.md — what it does, how to run it, its limits
STDLIB.md — every stdlib-for-package substitution you made
5-Minute Demo Video

The project should build with a single documented command and be publicly accessible during judging.

Judging Criteria

Projects are evaluated using a weighted scoring system:

Functionality & Usefulness (35%)
Does it build with one command, run, and do something a real person would want?

Zero-Dependency Craft (30%)
How effectively did you replace what you'd normally import? STDLIB.md quality lives here.

Code Quality & Idiom (25%)
Does the code read as idiomatic to a senior reviewer, or as a fight against the standard library?

Innovation (10%)
Creative wildcard picks. Genuinely surprising things built with nothing but stdlib.

Bonus Points

Single File (+5) — Ship the entire project as one genuinely useful source file.
Reproducible Build (+5) — Build the artifact twice, produce byte-identical output, publish both hashes.
Package Killer (+3) — Cleanly reimplement a package people actually install, documented in STDLIB.md.
STDLIB Log (+3) — Submit a STDLIB.md with 10+ real, non-trivial stdlib-for-package substitutions.

AI Tools Are Allowed

Zero Dependency embraces modern development workflows.

Participants are free to use:

Claude Code
Cursor
Aider
GitHub Copilot
Local AI models
Other AI coding assistants

AI usage itself is not scored. What's scored is whether the final implementation works, follows the zero-dependency constraint, and can be explained and defended by the team.

Rules

Some important rules include:

Team size: 1–4 members.
All project code must be written during the official 72-hour hackathon.
Planning, research, and AI prompt preparation are allowed beforehand — no code commits before kickoff.
The final artifact must have zero third-party runtime dependencies.
The project must build using a single documented command.
Vendoring third-party source to fake an empty manifest is not allowed without disclosure.
Public GitHub repository required at submission time.
Submissions must target one of the six official tracks.
Open-source licenses must be respected.
AI coding assistants are permitted.

Important Dates

Event	Date
Registration Opens	31 July 2026
Team Formation	24 August 2026
Cheat-Sheets Posted	26 August 2026
Hackathon Kickoff	28 August 2026 · 18:00 UTC
Code Freeze / Submission Deadline	31 August 2026 · 18:00 UTC
Judging Window	31 August – 10 September 2026
Write-Up Side Quest Closes	8 September 2026
Winners Announced	11 September 2026

Prizes

🏆 Total Prize Pool: $1,800 USD

🥇 1st Place — $800 — Grand Prize
🥈 2nd Place — $400 — Runner-Up
🥉 3rd Place — $200 — Third Place
📦 Package Killer — $100 — Best Reimplementation

✍️ Write-Up Side Quest — $300 ($100 × 3)
Publish a technical write-up about your build: what you reimplemented, what the stdlib made painful, the package you made look unnecessary. Tag Hackathon Raptors. Top 3, judged on insight, not follower count.

Who Should Join?

Zero Dependency is ideal for:

Backend & Systems Engineers
Tooling & DX Engineers
Security Engineers
Database & Storage Curious Developers
Language Nerds & Compiler Folks
Polyglots & Generalists
Students looking to work on real-world engineering fundamentals

If you've ever wanted to know what's actually inside the library you import every day — or prove you can ship real software without one — this hackathon is for you.

Join the Community

All announcements, cheat-sheets, rule clarifications, FAQs, submission guidelines, and live support will be shared exclusively on the Hackathon Raptors Discord.

👉 Website: https://www.zerodepshack.com/

👉 Hackathon Raptors: https://raptors.dev

👉 Discord: https://discord.gg/XPfcH7VT2H

Final Thoughts

Zero Dependency isn't just another "build anything" hackathon.

It's a challenge centered on one of the most overlooked engineering problems of the AI era: we've outsourced so much to our dependency trees that most of us couldn't tell you what's actually inside them — and the AI writing our code doesn't always know either, sometimes reaching for packages that were never real.

If you're excited about systems programming, parsers, networking, storage engines, security, or just proving you still know what's underneath the packages you import — this is your weekend.

Registration is now open. Pick your track, empty your manifest, and build something real.

Port Mortem 2026 - Hackathon

Raptor — Fri, 03 Jul 2026 11:37:20 +0000

Port Mortem 2026 — Rewrite Real Software. Prove It Still Works.

The software industry is entering a new era.

AI can now rewrite thousands of lines of code across programming languages in minutes. Companies are investing heavily in AI-assisted migrations—from C/C++ to Rust, TypeScript to Go, Python to Rust, and beyond.

But there's a major problem.

Generating a port is easy.

Proving that the rewritten software behaves exactly like the original is hard.

That's precisely what Port Mortem 2026 is about.

Organized by Hackathon Raptors, Port Mortem is a 72-hour online international hackathon where participants port real-world open-source projects into another programming language while demonstrating behavioral equivalence through testing, benchmarking, documentation, and engineering discipline—not just AI-generated code.

Why Port Mortem?

Modern AI coding assistants can generate working code incredibly fast.

However, production software isn't judged by whether it compiles.

It is judged by questions like:

Does every feature still behave correctly?
Does the original test suite still pass?
Are concurrency semantics preserved?
Are performance characteristics maintained or improved?
Is the implementation idiomatic in the target language?
Can another engineer confidently maintain it?

Port Mortem is designed around these questions.

Instead of rewarding who generates the most code, the hackathon rewards teams that can prove their migration is correct.

About the Hackathon

🌍 Global Online Hackathon
⏳ 72 Hours
💰 $1,800 Prize Pool
👥 Solo or Teams of up to 4
🎓 Open to students, professionals, researchers, and developers worldwide
💸 Completely Free to Participate

Whether you're a systems programmer, backend engineer, open-source contributor, Rust enthusiast, Go developer, or simply interested in AI-assisted software engineering, Port Mortem offers a unique engineering challenge.

What You'll Build

Every participating team will:

Select a real open-source repository.
Rewrite it into a different programming language.
Preserve the original functionality.
Validate correctness using the original test suite whenever possible.
Benchmark the new implementation.
Document architectural decisions and implementation trade-offs.
Submit the completed migration for evaluation.

Unlike many hackathons, success isn't determined by flashy demos.

The emphasis is on engineering quality, correctness, reproducibility, and maintainability.

Migration Tracks

Participants can choose from eight migration tracks:

Track A

C → Rust

Track B

Zig → Rust

Track C

TypeScript → Go

Track D

Python → Rust

Track E

Go → Rust

Track F

JavaScript → Go or Rust

Track G

C → Zig

Track H

Open Pair (Any Language → Any Language)

This gives participants the flexibility to work on the language ecosystem they enjoy most while tackling real engineering problems.

Submission Requirements

Each team must submit:

Public GitHub Repository
Complete Working Implementation
Build Instructions
Benchmark Report
DECISIONS.md documenting architectural choices
Differential Testing / Fuzzing Artifacts (where applicable)
Demo Video

The project should build with a single documented command and be publicly accessible during judging.

Judging Criteria

Projects are evaluated using a weighted scoring system.

Functionality & Reliability (40%)

Successful build
Correct execution
Test suite compatibility

Behavioral Equivalence (30%)

Migration accuracy
Differential testing
Benchmarking
Performance analysis

Code Quality (20%)

Idiomatic implementation
Maintainability
Documentation
Engineering practices

Innovation (10%)

Creative improvements
Better architecture
Valuable enhancements

Bonus Points

Teams can earn additional points for:

Differential fuzzing
Discovering bugs in the original project
Exceptional engineering documentation
Minimal unsafe code

AI Tools Are Allowed

Port Mortem embraces modern development workflows.

Participants are free to use:

GitHub Copilot
Cursor
Claude Code
Aider
Continue
Local LLMs
Other AI coding assistants

However, AI-generated code alone won't win.

Teams are expected to justify architectural decisions, validate correctness, and demonstrate engineering rigor.

Rules

Some important rules include:

Team size: 1–4 members
All development must occur during the official 72-hour event.
AI coding assistants are permitted.
Public GitHub repository required.
Projects must build using one documented command.
Source-language runtime wrappers or proxy implementations are not allowed.
Teams should preserve the original test suite wherever feasible.
Open-source licenses must be respected.
Plagiarism or pre-existing ports may result in disqualification.

Important Dates

Event	Date
Registration Opens	29 June 2026
Registration Deadline	31 July 2026 (6:00 PM IST)
Hackathon Kickoff	31 July 2026 (11:30 PM IST)
Submission Deadline	3 August 2026 (11:30 PM IST)
Judging	3–13 August 2026
Winners Announced	14 August 2026
Community Choice Winner	22 August 2026

Prizes

🏆 Total Prize Pool: $1,800 USD

🥇 Grand Prize

$800

🥈 Runner-Up

$400

🥉 Third Place

$200

🐞 Bug Catcher Award

$100

Awarded to the team that discovers and documents the most impactful bug in the original repository through differential testing.

❤️ Community Choice Award

$300

Selected through community voting.

Every participant who successfully completes the event will also receive a Participation Certificate.

Who Should Join?

Port Mortem is ideal for:

Systems Programmers
Rust Developers
Go Developers
Backend Engineers
Compiler Enthusiasts
Open Source Contributors
Performance Engineers
Security Researchers
AI Engineers
Students looking to work on real-world software engineering problems

If you've ever wanted to contribute to a serious software migration project—or explore how AI can assist large-scale code transformations while maintaining engineering quality—this hackathon is for you.

Join the Community

All announcements, repository releases, rule clarifications, FAQs, submission guidelines, and live support will be shared exclusively on the Hackathon Raptors Discord.

👉 Website: https://coderesurrection.com/2026

👉 Hackathon Raptors: https://raptors.dev

👉 Discord: https://discord.gg/XPfcH7VT2H

Final Thoughts

Port Mortem isn't just another "build anything" hackathon.

It's a challenge centered on one of the most important engineering problems emerging in the AI era: software migration with provable correctness.

If you're excited about cross-language development, open source, testing, systems programming, or AI-assisted engineering, this is an excellent opportunity to build something technically meaningful while competing for $1,800 in prizes.

Registration is now open. Assemble your team, choose your migration track, and get ready to resurrect code.