DEV Community: Raptor

Speed Demon 2026: Every Millisecond Is a Soul

Raptor — Thu, 15 Oct 2026 15:15:28 +0000

Most hackathons ask you to build something impressive.

Speed Demon asks a different question.

How fast can you make it run?

Not how fast your laptop says it runs.

Not how fast it ran once.

Not how fast you claim it is.

The organizers run your code themselves, on the same machine, against the same dataset, using the same benchmarking harness.

And then they rank what comes back.

Welcome to Speed Demon 2026, a 72-hour online performance championship by Hackathon Raptors where every millisecond counts, every optimization has a cost, and correctness is non-negotiable.

The challenge is simple:

Same task. Same data. Same machine. Beat the reference implementation.

And no, writing everything in C and hoping for the best is not necessarily going to win.

About the Hackathon

Speed Demon 2026 is a 72-hour online performance engineering competition organized by Hackathon Raptors.

Instead of building another application, participants optimize computational workloads that deliberately start with slow reference implementations.

You get the task specification.

You get the dataset.

You get the reference implementation.

Your job is to produce a solution that returns exactly the same output while using fewer resources and running faster.

At a glance

🌍 Online and open to participants worldwide
⏳ 72-hour competition
📅 October 30 – November 2, 2026
💰 $2,000 total prize pool
👥 Solo participation or teams of up to 4
💸 Free to participate
🧠 Five performance engineering tracks
🐳 Docker-based evaluation
🏆 Individual track awards and an overall championship
🤖 AI coding assistants allowed

The competition runs from October 30 at 18:00 UTC to November 2 at 18:00 UTC.

Participants can enter as many tracks as they want, but completing at least three tracks is required to qualify for the overall Speed Demon title.

The winning strategy is not simply to write the shortest code or achieve the lowest runtime on one task.

It is to build correct, efficient software that performs consistently across different workloads.

Why Another Performance Competition?

Performance optimization is one of those engineering disciplines that everyone talks about and surprisingly few people measure properly.

You will hear things like:

"This implementation is faster."

"This algorithm should scale better."

"Rust will definitely beat Python."

"This data structure is more efficient."

Sometimes those statements are correct.

Sometimes they are guesses dressed up as engineering decisions.

Speed Demon replaces those arguments with measurements.

Every submission is evaluated against a published reference implementation, using a controlled environment and a fixed scoring methodology.

The interesting part is that execution time is only one component of the score.

Consider two implementations.

Implementation A finishes in 0.4 seconds but consumes enormous amounts of memory, ships thousands of lines of complicated code, and relies on several heavyweight dependencies.

Implementation B finishes in 0.9 seconds, uses a fraction of the memory, and has a simpler implementation with fewer dependencies.

Which one is better?

That depends on the trade-offs.

Speed Demon makes those trade-offs explicit through a published efficiency coefficient.

You cannot win simply by optimizing one metric while ignoring everything else.

And you cannot win with an incorrect answer, no matter how fast your program is.

Five Tracks. Five Different Engineering Problems.

Speed Demon has five tracks, each designed to test a different set of skills.

You do not need to enter all five.

Choose the workloads that match your strengths, or challenge yourself by entering several.

Track A: Ingest

Parse 3.1 million log lines. Aggregate the results. Make it fast.

The task involves processing 312 MB of structured log data.

You must calculate per-endpoint request counts, p50/p95/p99 latency percentiles, and hourly error rates.

The reference implementation performs the task correctly, but inefficiently.

It reads lines, splits fields, parses timestamps using a date library, stores latency values, and sorts them later to calculate percentiles.

Every one of those operations is an opportunity for optimization.

You might investigate:

Custom line parsing instead of general-purpose readers.
More efficient timestamp parsing.
Reducing temporary string allocations.
Replacing expensive hash-based operations where appropriate.
Improving cache locality and memory layout.
Computing percentiles without sorting every individual latency.
Reducing allocator overhead.
Processing records efficiently across multiple threads.

The challenge is figuring out which optimization actually matters.

A faster parser will not help much if timestamp parsing remains your dominant bottleneck.

And a clever algorithm can still lose if its data structures cause excessive memory traffic.

Reference runtime: 41.2 seconds.

This is a good starting point for anyone interested in systems programming, parsing, and data processing.

Track B: Index

Build a search index. Answer 50,000 queries. Optimize both sides.

You receive a 250 MB text corpus and must build an inverted index that supports Boolean and phrase queries.

This track is particularly interesting because index construction and query execution are measured separately.

Build time contributes 40% of the combined time measurement.

Query time contributes 60%.

An implementation that builds an index incredibly quickly but answers queries slowly is not necessarily competitive.

You need to think about:

Inverted index representation.
Posting-list compression.
Efficient intersection of posting lists.
Boolean query execution order.
Tokenization and indexing.
Positional indexes for phrase queries.
Memory consumption.
The trade-off between preprocessing and query performance.

Phrase queries add another layer of complexity because the system must preserve token positions and match adjacent terms in the correct order.

The fastest data structure to construct is not always the fastest one to query.

That trade-off is the point.

If you enjoy search engines, databases, indexing systems, or query optimization, Track B deserves a serious look.

Track C: Join

The fast solution is easy. The edge cases are the actual task.

Track C involves parsing a 204 MB CSV dataset containing deliberately difficult input cases.

The file includes:

Quoted commas.
Escaped quotation marks.
Embedded newlines.
Mixed line endings.
UTF-8 byte-order marks.
Empty fields.
Trailing spaces.
Records that span multiple lines.

After parsing the input correctly, you must join it against a lookup table and produce sorted aggregates.

This is where assumptions become expensive.

A parser that splits every line on commas may appear to work on ordinary input.

It will fail when a quoted field contains a comma.

A parser that assumes one record per line will fail when a field contains a newline.

A solution that mishandles a byte-order mark may produce incorrect output even when the rest of the pipeline is perfect.

The interesting engineering questions include:

Should you use a hash join or sort-merge join?
How should you represent parsed fields?
Can you avoid unnecessary allocations?
How do you handle encoding edge cases without sacrificing performance?
Can you process the data efficiently while preserving exact output semantics?

A parser that is three times faster but produces the wrong output scores zero.

This track rewards engineers who understand both performance and correctness.

Track D: Traverse

Five million edges. Two thousand shortest-path queries.

Track D gives you a directed, weighted graph containing 5 million edges and asks you to answer 2,000 source-target shortest-path queries.

This is the algorithms track.

The gap between a competent implementation and an excellent one can be substantial.

Potential approaches include:

Efficient graph representations.
Adjacency-list and compact-array layouts.
Priority queue optimization.
Bidirectional shortest-path search.
Preprocessing for repeated queries.
Improved memory locality.
Contraction hierarchies or other suitable acceleration techniques.

Preprocessing is allowed, but its cost is included in the measured runtime.

That means you cannot simply ignore the time required to construct an index or auxiliary structure.

You must decide whether the upfront cost is justified by faster query execution.

This is a classic build-versus-query trade-off.

The right approach depends on the graph, the query workload, the available memory, and the cost of preprocessing.

If you enjoy graph algorithms and want a competition where constant factors matter alongside asymptotic complexity, this is your track.

Track E: Compress

Make the data smaller without losing a single bit.

Track E focuses on lossless compression of a 100 MB mixed corpus containing:

English text.
Structured logs.
JSON records.
Binary sensor data.

The score balances compression ratio and decompression throughput.

You cannot win by producing a tiny archive that takes forever to decompress.

You cannot win by decompressing instantly while barely compressing anything.

The engineering challenges include:

Identifying patterns in different data types.
Choosing appropriate compression representations.
Balancing compression ratio against runtime.
Improving decompression throughput.
Managing memory usage.
Handling heterogeneous input efficiently.
Ensuring exact round-trip correctness.

General-purpose compression libraries that solve the entire task are prohibited for this track.

You need to implement the compression approach yourself, within the published rules.

The interesting part is that this track changes the efficiency coefficient slightly: compressed size replaces peak memory as the corresponding resource metric.

It is the most direct exploration of the speed-versus-size trade-off in the competition.

How the Competition Works

Every track gives participants the same fundamental ingredients:

A published task specification.
A fixed reference implementation.
A defined dataset format.
A published execution environment.
A scoring formula.
A set of correctness and sandbox requirements.

You develop your solution locally and package it in a Docker image.

The organizers build and execute that image.

Your program reads its input from /data, writes the required output to /out, and exits successfully.

The dataset is mounted read-only.

Networking is disabled.

The root filesystem is read-only, with a limited temporary directory available for scratch space.

Your implementation must work within the specified CPU and memory limits.

This is not a benchmark where everyone submits numbers from different machines and hopes they are comparable.

The organizers run your code. Your reported timings do not count.

The machine

The official benchmarking environment is a dedicated Hetzner EX44 server in Helsinki, Finland.

The published hardware specification includes:

Intel Core i5-13500 processor.
Six physical performance cores available to submissions.
Twelve hardware threads.
8 GB memory limit per submission.
Docker with cgroups v2.
Debian 13.
Network access disabled during builds and scoring.

The CPU resources are pinned, and turbo boost is disabled to reduce variability.

Every submission is evaluated under the same execution constraints.

This matters because performance results are meaningful only when the measurement environment is controlled.

Your laptop is useful for development and profiling.

The official machine determines your score.

The Scoring System: Speed Is Not Everything

Speed Demon uses an efficiency coefficient called K.

The coefficient combines five ratios against the reference implementation.

The published formula is:

K = (Tref/T)^0.40 × (Mref/M)^0.20 × (Sref/S)^0.15 × (Dref/D)^0.15 × (Xref/X)^0.10

Here is what each factor means.

T: Wall time — 40%

How long does your implementation take to execute?

The official harness runs the program five times.

The highest and lowest timings are discarded, and the mean of the remaining three becomes the measured runtime.

This is the most heavily weighted factor.

M: Peak memory — 20%

How much memory does your implementation consume?

The harness reads the peak memory measurement from the execution environment rather than trusting a value reported by your program.

Using more memory to achieve lower runtime can be a valid engineering trade-off, but it comes at a cost.

For Track E, compressed size replaces peak memory in this factor.

S: Source size — 15%

How large is your normalized source code?

The source is measured after the specified canonical formatting, comment removal, and identifier normalization.

The goal is to account for source size without rewarding meaningless tricks such as renaming every variable to a single character.

Readable code is allowed to be longer.

It simply has to justify its cost.

D: Dependency weight — 15%

How much does your solution depend on external runtime dependencies?

Dependencies are allowed, subject to the track-specific restrictions, but they are not free.

The published calculation includes non-standard-library runtime dependencies and vendored source size.

A zero-dependency implementation can gain an advantage on this axis, even before its runtime is considered.

X: Scaling — 10%

How does your solution behave when the input becomes larger?

The harness compares your runtime at different input sizes against the reference implementation's scaling behaviour.

This helps identify solutions that perform well on small inputs but deteriorate as the workload grows.

Each factor is capped at 50×.

The weights are fixed before kickoff, so participants know the trade-offs before writing their code.

Turning K into points

The efficiency coefficient is converted into a speed score using a logarithmic scale:

Speed Score = 100 × ln(K) / ln(25)

The score is clamped between 0 and 100.

The important reference points are:

K = 25: 100 speed points.
K = 5: 50 speed points.
K < 1: Zero speed points.

Why logarithmic scoring?

Because performance optimization becomes increasingly difficult as you push beyond an already fast implementation.

Improving a solution from 1× to 2× can be relatively straightforward.

Improving it from 12× to 24× may require completely rethinking the algorithm or data representation.

The scoring curve reflects that reality.

Your final score

Machine-measured performance accounts for 65% of each track's score.

The remaining 35% comes from human judging:

Code quality: 15%.
Optimization technique: 12%.
Optimization log: 8%.

The overall championship requires at least three completed tracks and uses the geometric mean of the track totals.

That prevents one spectacular result from carrying two weak results.

To win overall, you need to perform well across multiple workloads.

Correctness Comes Before Optimization

There are four important evaluation gates.

Fail any required gate, and the submission receives zero for that track.

1. Exact output

Your output must match the expected SHA-256 hash.

Not approximately.

Not with the same values in a different order.

Exactly.

The specifications define the output format, ordering, and formatting rules. Sample datasets and expected hashes allow you to verify your implementation locally.

A solution that produces the correct answer four times out of five is still incorrect.

2. Performance floor

The published rules include a performance floor for the overall title.

A submission must be within 10× of the fastest correct submission in its track to satisfy this requirement.

3. Timeout

Each track has a hard timeout based on the reference implementation's runtime.

A program that hangs or exceeds the limit is not treated as a successful slow implementation.

It is a failed run.

4. Sandbox compliance

Submissions must respect the restrictions on networking, filesystem access, and dataset modification.

Precomputed answers, attempts to access protected data, or other methods of bypassing the intended task can result in disqualification.

This is a performance competition, not a contest to find loopholes in the benchmark harness.

What You Need to Submit

Each track submission needs a repository that can be built and evaluated without manual intervention.

The expected deliverables include:

Public GitHub repository.
OSI-approved open-source license.
Dockerfile.
Required source code and build scripts.
README.md.
PERF.md.
.speed-demon.toml.

Your Dockerfile must build without network access.

The resulting program must follow the track's input/output contract and satisfy the execution requirements.

The optimization log matters

PERF.md is not supposed to be a marketing document.

It should record what you actually tried and measured.

For example:

The baseline implementation took 41 seconds.
Replacing a hash map with a compact array reduced runtime to 8 seconds.
Manual line parsing reduced it to 2.1 seconds.
A SIMD optimization made timestamp parsing slower, so it was reverted.

That is useful engineering documentation.

It demonstrates that you understand your bottlenecks, tested your assumptions, and made decisions based on evidence.

Failed experiments count, too.

Sometimes the most valuable optimization lesson is discovering why an apparently clever change made the program worse.

The 72-Hour Strategy

Seventy-two hours sounds like a lot until you start optimizing five different workloads.

The obvious mistake is to spend the entire weekend chasing the biggest theoretical speedup without first establishing a correct baseline.

A more sensible approach is to work in stages.

Stage 1: Make it correct

Read the specification carefully.

Implement the straightforward solution.

Verify the output against the sample dataset and expected hash.

Do not start with clever optimizations before you understand the exact output requirements.

Stage 2: Establish a baseline

Run the implementation locally.

Measure runtime and memory.

Use profiling tools to identify where the time actually goes.

Do not guess.

If timestamp parsing consumes 60% of runtime, optimizing an unrelated loop is unlikely to move the needle much.

Stage 3: Optimize the dominant bottlenecks

Prioritize the changes most likely to improve your score.

Depending on the track, that might mean:

Choosing a better algorithm.
Reducing allocations.
Improving memory locality.
Replacing expensive data structures.
Optimizing parsing.
Changing the indexing strategy.
Improving query execution.
Reducing unnecessary dependencies.

Measure after each meaningful change.

Keep the changes that help and revert the ones that do not.

Stage 4: Verify every optimization

Run the correctness checks again.

A faster solution that fails the output hash is worthless.

Also test the solution under the same resource limits and execution assumptions used by the official harness.

Stage 5: Prepare the final submission

Make sure the Docker image builds offline.

Verify that the program reads from the correct directory and writes the expected output.

Complete PERF.md, README.md, and .speed-demon.toml.

Do not leave packaging and documentation until the final minutes.

Stage 6: Decide whether to enter more tracks

If your first track is strong and stable, consider entering another.

If your current solution is still incorrect or poorly optimized, adding another track may reduce your chances of doing either well.

For the overall title, you need at least three completed tracks.

For individual awards, a strong specialist submission can still be valuable.

Choose your strategy accordingly.

AI Tools Are Allowed

You can use AI coding assistants, including Claude Code, Cursor, Codex, GitHub Copilot, local models, and other development tools.

The competition does not score you based on whether you used AI.

It evaluates the software you produce.

AI can help generate an initial implementation, explore alternative algorithms, explain profiling output, or automate repetitive experiments.

But it cannot replace verification.

Generated code may contain incorrect assumptions, unnecessary allocations, inefficient data structures, or subtle correctness bugs.

If you cannot explain why your implementation is fast, your optimization log will expose that gap.

Use AI to accelerate the engineering process.

Then measure, test, and understand what you ship.

Prize Pool: $2,000

Speed Demon has a total prize pool of $2,000 across six awards.

Award	Prize
Speed Demon — Overall Champion	$800
Runner-up	$400
Third Place	$200
Highest Efficiency Coefficient	$200
The Lean Award	$100
Write-Up Side Quest — 3 winners	$300 total

Speed Demon — $800

Awarded to the overall champion with the highest geometric mean across at least three tracks.

The goal is to be fast everywhere, not just on one workload.

Runner-up — $400

Awarded to the second-place team on the overall leaderboard.

Third Place — $200

Awarded to the third-place team in the overall championship.

Highest Efficiency Coefficient — $200

Awarded to the submission with the largest efficiency coefficient recorded on any individual track.

This award recognizes exceptional optimization on a specific workload, even if the team does not qualify for the overall title.

The Lean Award — $100

Awarded for the best efficiency coefficient achieved with the smallest normalized source.

This recognizes solutions that achieve strong performance through effective engineering rather than unnecessary complexity.

Write-Up Side Quest — $300

Three winners receive $100 each for publishing an insightful account of their optimization journey.

Document the bottleneck you discovered, the changes you tested, the experiment that failed, or the small change that produced a major improvement.

The focus is on technical insight, not audience size.

Important Dates

All times are in UTC.

Event	Date
Registration opens	October 2, 2026
Team formation closes	October 26, 2026
Specifications and harness published	October 28, 2026 at 18:00 UTC
Sample datasets released	October 30, 2026 at 06:00 UTC
Hackathon kickoff	October 30, 2026 at 18:00 UTC
Code freeze	November 2, 2026 at 18:00 UTC
Official scoring runs	November 2–4, 2026
Judging window	November 3–12, 2026
Write-Up Side Quest closes	November 10, 2026
Winners announced	November 13, 2026

The full specifications, reference implementations, and scoring harness are published before kickoff.

The final datasets are released at kickoff, and the leaderboard opens.

Final scoring uses holdout data generated from the same distributions with previously unseen seeds.

The scoring formula is frozen before the competition begins.

Rules You Should Know

Before registering, keep these requirements in mind:

Teams must contain 1–4 members.
Solo participation is allowed.
Any programming language is eligible if it builds offline in a Linux container and runs on x86-64.
All project code must be written during the official 72-hour competition window.
Research, algorithm planning, documentation reading, and environment preparation are allowed before kickoff.
Code must not be committed before kickoff.
AI coding assistants and development tools are allowed.
Dependencies are permitted but contribute to the dependency-weight calculation.
Track-specific restrictions on libraries must be respected.
Output must match the reference implementation exactly.
Precomputed answers and input-specific shortcuts that bypass the intended task are prohibited.
Docker builds must work without network access.
Submissions must respect CPU, memory, timeout, and sandbox restrictions.
Repositories must be public at code freeze and use an OSI-approved open-source license.
The required documentation and submission metadata must be included.
The official harness determines the benchmark results.
At least three completed tracks are required for the overall Speed Demon title.

Read the official specifications and rules for the complete requirements before submitting.

Who Should Join?

Speed Demon is a good fit for developers who enjoy understanding how software behaves under pressure.

You might be a:

Systems programmer who cares about cache lines and memory allocation.
Data engineer who has strong opinions about parsing and aggregation.
Backend developer who wants to optimize a slow pipeline.
Database engineer who enjoys indexes and query execution.
Competitive programmer who wants to explore real-world performance constraints.
Algorithms enthusiast who likes finding better approaches to difficult problems.
Compression developer interested in the trade-off between size and throughput.
Student who wants to go beyond implementing standard algorithms.
Developer who has ever opened a profiler just to understand why something was slow.

You do not need to be an expert in every track.

You need a willingness to experiment, measure, and improve.

Why Speed Demon Is Different

Most hackathons ask:

"What can you build in 72 hours?"

Speed Demon asks:

"How much better can you make something that already works?"

There are no points for a convincing pitch.

No reward for claiming that your implementation is optimized.

No advantage to submitting benchmark results from a more powerful laptop.

The organizers run your code.

The output must be correct.

The measurements determine the performance score.

The judges evaluate the engineering behind the implementation.

That changes how you approach the entire competition.

A theoretically optimal algorithm can lose to a better-engineered implementation.

A faster solution can lose points because it consumes too much memory.

A tiny program can still fail if it is incorrect.

A clever optimization can make the code slower.

And the only way to know is to measure.

That is what makes performance engineering interesting.

It is not about writing code that looks fast.

It is about producing evidence that it is fast, understanding why, and knowing what trade-offs you made.

Final Thoughts

Speed Demon 2026 is a different kind of hackathon.

Five tracks.

Five distinct engineering problems.

A fixed machine.

A published scoring formula.

A 72-hour deadline.

And a reference implementation waiting to be beaten.

Build the straightforward solution first.

Make it correct.

Measure the bottlenecks.

Optimize the important parts.

Test every change.

Document what worked and what did not.

Then do it again.

The strongest submission will not necessarily be the one with the most complicated algorithm or the fewest lines of code.

It will be the one that combines correctness, measured performance, efficient resource usage, and sound engineering decisions.

Every millisecond is a soul.

Join Speed Demon 2026

🌐 Event Website: https://speeddemon.dev/

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

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

📅 October 30 – November 2, 2026

⏳ 72-hour online performance championship

💰 $2,000 total prize pool

👥 Solo or teams of up to 4

💸 Free to participate

Five tracks. One reference implementation to beat. One machine that does not care how good your idea sounded.

Make your code faster. Make it leaner. Prove it with measurements.

See you on the leaderboard.

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.

Why 1,500+ Developers from 30+ Countries Keep Coming Back to Our Hackathons ⭐

Raptor — Fri, 26 Jun 2026 06:25:34 +0000

Hackathon Raptors: Building a Global Community Around Open Innovation

AI Disclosure: This article was drafted with the assistance of ChatGPT and reviewed, edited, and fact-checked by the author.

The best hackathons aren't just competitions—they're places where strangers become teammates, ideas become working software, and learning happens faster than any classroom can replicate.

That's the philosophy behind Hackathon Raptors, a UK-based nonprofit Community Interest Company (CIC) focused on creating accessible, collaborative hackathons for developers worldwide.

Instead of rewarding polished presentations or ambitious pitches alone, our events encourage participants to build real software under realistic engineering constraints. Every hackathon runs for 72 hours, giving teams enough time to design, develop, test, and demonstrate working solutions while collaborating across countries and time zones.

Since launching the community, we've welcomed developers from 30+ countries, hosted 10+ international hackathons, supported 1,500+ builders, and seen more than 300 projects brought to life.

More importantly, we've watched complete beginners build their first full-stack application, experienced engineers mentor the next generation, and global teams collaborate despite never meeting in person.

What Makes Our Hackathons Different?

Many hackathons end when submissions close.

We aim to create a community that continues long after the winners are announced.

Participants join a shared Discord community where they can collaborate between events, exchange ideas, find teammates, receive feedback, and stay connected with builders from around the world.

During each hackathon, teams work on solving practical problems while balancing technical quality, usability, teamwork, and execution under tight deadlines. Projects are reviewed by experienced judges from industry, providing constructive feedback that helps participants improve—not just compete.

Whether you're exploring your first hackathon or you've attended dozens before, the goal is the same: build something meaningful while learning alongside talented people.

Participants often tell us they value:

Building real software instead of slide decks
Collaborating with developers across different countries
Receiving practical feedback from experienced engineers
Expanding their portfolios with complete projects
Meeting future teammates, mentors, and collaborators
Learning new technologies in a fast-paced environment

A Community That Grows Together

Hackathon Raptors is built around the belief that open collaboration leads to better engineering.

Our community includes students, professional software engineers, designers, researchers, founders, and open-source contributors who enjoy building together.

Every event becomes an opportunity to exchange ideas across disciplines while experimenting with emerging technologies—from AI and cloud platforms to developer tools, cybersecurity, web applications, and beyond.

The emphasis isn't on building the biggest product.

It's on learning by building.

Why Organizations Choose to Partner With Us

Hackathons are also valuable environments for companies looking to engage directly with builders.

Rather than traditional sponsorship focused only on logo placement, our partners have the opportunity to introduce developers to their APIs, SDKs, cloud platforms, and engineering tools through hands-on challenges.

This creates meaningful interactions between developers and technology companies while giving participants exposure to modern developer ecosystems.

Depending on the partnership, sponsors can:

Launch technology-focused challenge tracks
Introduce APIs, SDKs, and developer tools
Connect with talented builders from around the world
Support educational workshops and mentoring sessions
Increase awareness within an active global developer community
Participate as mentors or judges

We're grateful for the support of organizations that have partnered with us, including Turbo and Vectera, whose sponsorship has helped us continue organizing community-driven hackathons and creating opportunities for developers worldwide.

If your organization believes in supporting developers, open innovation, and technical education, we'd love to start a conversation about future collaborations.

Looking Ahead

Technology moves quickly, but communities are what keep people learning.

Our mission is to make high-quality hackathons accessible to anyone who wants to build, collaborate, and grow—regardless of where they live or where they are in their career.

Every new participant brings a different perspective.

Every mentor shares knowledge that helps someone else improve.

Every sponsor helps create opportunities for builders around the world.

If that mission resonates with you, we'd love to have you involved.

Whether you're looking to join your first hackathon, mentor aspiring developers, judge innovative projects, or explore sponsorship opportunities, there's a place for you in the community.

Learn More

🌐 Website: https://raptors.dev

💬 Discord: https://discord.gg/4WKvHaFRNN

💼 LinkedIn: https://www.linkedin.com/company/hackathon-raptors

𝕏 X (Twitter): https://x.com/raptors_hack

📷 Instagram: https://www.instagram.com/raptors.dev

Build. Learn. Collaborate. Create technology that makes a difference.