We Planted 180 Bugs in Copies of Real Open-Source Backends. Fix Your First One in About 20 Minutes

PushForces is a practice site where you fix bugs we planted on purpose in copies of real open-source backend code. The original projects are untouched. We're the small team that builds it. It's an early alpha (a first test version, open to everyone). It's free, and we have no plans to charge for it.

Every ticket today is backend work. The backend is the server side of an app (accounts, payments, stored data). We'll add other areas of software work over time.

That recording shows someone fixing a bug in real money-tracking software, inside a web page, with no account.

The software is Formance Ledger, an open-source program that keeps track of balances and payments. We cut a small slice out of it and broke one function on purpose. That function should add two amounts of money. It returned nothing. The fix is one line of code, blurred out so you can try it first. A button sends the fix to our checker. The checker runs tests the person never saw, and the screen turns green: accepted.

What you get

Each practice task is called a ticket, the word software teams use for one piece of work. Someone reports a problem. You find and fix the broken code in a real project someone else wrote. A machine checks whether your fix really works.

The quick facts:

Question	Answer
Cost	Free. There is no paid plan, and none is planned.
Account	Not needed for the 93 easier tickets. Harder tickets and deeper features need a verified account (email, gmail, github are welcome)
Install	Nothing for the easier tickets. They run in your browser.
Time	About 15 to 25 minutes for a 1-star ticket. About 2 to 4 hours for a 5-star one.
Scope	180 tickets built on 27 real projects, mostly well-known open-source ones. All of them are backend today. Other areas come later.

What each ticket gives you, in the order you'll meet it:

• A real project's code to read. Each ticket sits on a slice of a real project (a set of files cut from it). Examples include Formance Ledger (money), Ory Kratos (logins and accounts) and Navidrome (music streaming).
• A clue or a bug report, depending on the level. Easy tickets (1 to 2★) point you at the right file and mark the spot with a TODO, a note left where code is missing. They teach you how a real project is written. From 3★ up, you get only a bug report. It reads like a message from support: what broke, how to make it happen again, and what "done" means. You find the bug yourself.
• A clear pass or fail. Our checker runs tests you never see. You pass when every one of them passes.
• Practice at the first-week skill. Finding your way around code someone else wrote is a big part of starting any new job.
• A path to the team workflow. Harder tickets move to your own computer. You send your fix with git, the tool most software teams use to share code.
• No penalty for failing. A failed attempt costs you nothing. You read what went wrong and try again.
• A profile that counts your accepted fixes. It shows tickets finished, attempts judged, and how often you passed.

How it compares with other coding practice sites

PushForces trains one narrow skill: finding and fixing a reported problem in a backend someone else wrote.

LeetCode trains you to solve a clearly stated puzzle inside one function, and it does that very well. Many job interviews still include an algorithm round, so LeetCode practice keeps its place. PushForces is practice for the weeks after you get the job.

Here is how PushForces sits next to the practice sites we compared ourselves against:

Site	Good for	The code you work in	How you hand in your work	Price (checked Sep 2026)
LeetCode	Interview-style algorithm puzzles	One function or class per problem	Browser editor	Free; paid Premium plan
Exercism	Getting fluent in 80+ programming languages, with volunteer mentors	Small exercises that come with their own tests	Browser editor, or a small tool on your own computer	Free
CodeCrafters	Rebuilding well-known tools (a database, git, a command-line terminal) step by step	Your own code, written from scratch	Upload with git (git push)	Free tier; paid membership
SadServers	Fixing broken servers (the computers that run websites)	A real, throwaway rented server	Typing commands in the browser, then a check button	Free tier; Pro from $9/month
Buglyst	Bug-fixing drills, plus practice on outages and on code that fails to build	Mostly labs written for the site, plus a few rebuilt from real open-source fixes	Browser workspace	Free public challenges; paid Pro pass
PushForces	Fixing a reported bug in someone else's backend	A slice of one of 27 real projects, mostly well-known open-source backends	Easy tickets in the browser; harder ones with git push	Free

We took each row from that site's public pages in September 2026 (pricing: CodeCrafters, SadServers, Buglyst). If a row is wrong or out of date, tell us in the comments and we'll fix it.

Where PushForces stands out

1. Someone else's code, from a real project. Most tickets name the open-source project they come from, such as Formance Ledger, Ory Kratos, Casbin and NetBox. A few tickets also add a small module of ours, and the deep dive explains why. The other sites in the table mostly use exercises written for the site, or have you write your own code. Buglyst is the closest site we know of. It has 145 playable labs. It writes most of them for the site, and four are rebuilt from real fixes in open-source projects.
2. From 3★ up, you start from a report, and the checks you can see already pass. Only the bug report says something is wrong, and only hidden tests catch it. So you find and reproduce the problem yourself, the way you would at work. Warm-ups are gentler: they point you at the file and mark the spot. Many sites give you sample tests or a failing test to aim at. Hidden tests by themselves are common: LeetCode, Codewars and Buglyst all use them.
3. The workflow a team uses, on code that already exists. Harder tickets give you your own private copy of the code. You fix it on your computer, send it back with git, and an automated judge decides. CodeCrafters also takes work through git, for code you write yourself. What we add is the combination: existing code, a team-style git flow and hidden tests.
4. Harder tickets read like urgent incidents at work. They carry a severity level and a response deadline, like an alert from a live system. The catalogue covers logins, money, data sync, and two requests hitting the same data at the same moment. SadServers runs incident practice on servers, and Buglyst's incident labs grade your diagnosis. Here you finish by sending a code fix that has to pass the hidden tests.

Several other teams are also building practice for finding and fixing bugs (debugging), including Recticode, Buggr and debuginterview.dev. The deep dive below lists which of our parts are standard elsewhere.

Try it in about 20 minutes

1. Open LED-01, the ticket from the recording. It's a 1★ ticket on the money ledger.
2. Read the ticket. It names one function that should add two amounts of money and sends you to the TODO inside it.
3. Jump to the line marked TODO and fix the function.
4. Press Run smoke (a quick self-check), then Submit for CI (the judged run).

If you know Python better, PDC-01 is another good first ticket. Harder tickets (3★ and up) need a free, verified account. You sign in with GitHub or Google.

Why we built it

We built PushForces because friends who aced algorithm interviews struggled on their first day at work. They opened the company's code and got lost.

They could code well. They were used to one file, one function, and a problem statement that said exactly what to do. Real work hands you a bug report from support and a program you didn't write. It also hands you automated checks that must pass and a reviewer who asks why. We wrote the two lists side by side:

Harder tickets aim at most of the right-hand column: a reported symptom, code you can't rewrite, and a build that has to go green. The reviewer who asks why isn't built yet.

We posted an early version on r/SideProject, a Reddit forum for side projects. Two of the replies:

reading unfamiliar codebases and hunting down bugs is like 90% of actual dev work anyway compared to leetcode stuff

navigating someone elses codebase is the actual skill gap nobody talks about

It's one thread and a handful of comments. It was still the first time strangers described the problem back to us in their own words.

The technical deep dive

The rest of this post is for developers who want the details. It covers how a ticket is built, both ways to submit, the judging sandbox, the numbers, and what's still weak.

How a ticket is built

Each ticket starts from a slice of a real open-source project, with one bug planted on purpose. The bugs follow common kinds of production failure. None of them is a copy of one specific historical bug.

From 3★ up, a ticket is written the way an incident arrives at work: usually a summary, steps to reproduce, expected output and a definition of done. Warm-ups are shorter. They name the function to fix and mark the spot with a TODO. Some tickets accept more than one correct fix.

• The workspace is a slice of the repository. LED-01 is a 13-file extract of Formance Ledger with one editable file. LED-05, a 5★ ticket on the same project, carries about 25 upstream files.
• Some tickets add code of their own. When the upstream code has no good spot for a bug, we sometimes add a small module of our own.

The harder the ticket, the more it reads like an incident. A few 3★ tickets carry a SEV3 label. 4★ tickets carry SEV2, most with a 240-minute SLA (a response deadline). 5★ tickets arrive as SEV1, the most severe level, with a 120-minute SLA. The clock starts when you accept the ticket. The deadline is there for realism, and going over it costs you nothing. Some tickets come with an incident-artifacts/ folder of logs and traces to dig through.

Most of the 17 five-star tickets are concurrency races, such as double spends and check-then-act gaps.

Warm-ups run in your browser (1 to 2★)

The 93 easy tickets open straight into a browser workspace. It uses Monaco, the editor inside VS Code, on a small extract of the repository. There's no clone and no account. Most warm-ups have one editable file with a TODO marking the spot. They train you to read a real project's types and conventions. The hunting starts at 3★.

Here's LED-01, the ticket from the recording:

The ticket says MonetaryInt.Add in internal/machine/monetary.go is incomplete and points you to the TODO inside it. Jump there and you find this:

func (a *MonetaryInt) Add(b *MonetaryInt) *MonetaryInt {
    // TODO: return the sum of a and b as *MonetaryInt
    if a == nil {
        a = (*MonetaryInt)(&big.Int{})
    }
    if b == nil {
        b = (*MonetaryInt)(&big.Int{})
    }
    _ = a
    _ = b
    return nil
}

The fix is one line. We won't paste it, because finding it among the big.Int wrappers is the exercise. Hit Run smoke to check the basics, then Submit for CI. In this run, the judged checks took about 16 seconds:

The title bar still says "praxis CI". Praxis was the project's name before PushForces.

Guests can submit too. If you sign up later, your guest progress moves into your account.

The visible checks stay green

On 3 to 5★ git tickets, the public smoke tests pass before you change a single line. They only check baseline sanity. The tests that catch the bug live on our server, and CI injects them into your run. They never ship to you.

So a passing ./local-test.sh tells you very little. You read the report, dig through the artifacts, and reproduce the problem yourself.

We know some people will dislike this choice. It's the closest thing we found to how a bug actually reaches you at work.

Harder tickets: the git flow (3 to 5★)

Accepting a 3 to 5★ ticket gives you a private git remote and a token that works for that one repository only. main is protected, so you branch, fix, and push:

# clone your private remote (username = your handle, password = the ticket token)
git clone <remote issued when you accept>
cd <ticket-folder>

# main is protected, so branch off
git switch -c feature/<ticket>-fix

# reproduce first (these checks stay green, remember)
./local-test.sh

# fix it in your own editor, then ship
git commit -am "fix: <ticket>"
git push -u origin feature/<ticket>-fix

Each 3 to 5★ ticket page names the container image its tests run in (for example golang:1.26-bookworm or python:3.12-slim). That lets you match your local setup, or you can push and let CI answer.

What happens after you push

The push starts a judged run in a disposable container. It has no network, dropped capabilities and resource limits. The run goes through the public checks, then the hidden suite, then an integrity check. Pass all three and main advances, and the ticket is marked Accepted.

XP lands at that moment. A failed run costs nothing. You lose no XP. There's one limit. Each account gets 10 judged runs per rolling 24 hours across all 4★ and 5★ tickets. Pushes over that are rejected until the window resets. Our Terms don't cap 3★ tickets or browser warm-ups.

The whole loop is six steps: accept, clone, reproduce, fix, push, verdict.

Fine print on the comparison

Several parts of PushForces are standard elsewhere, and we'd rather say so before the comments do.

• Submitting with git push also exists at CodeCrafters, for code you write from scratch.
• Hidden tests are how most judges work, including LeetCode, HackerRank, Codewars and Buglyst.
• A browser editor plus a local option also exists at Exercism, through its command-line tool.
• Debugging practice on realistic code exists too. Buglyst has 145 playable labs and a hidden CI suite. Four of its labs are reverted from real fixes in axios, express, node-fetch and node-redis. It runs in the browser, and its local mode is listed as coming soon.
• Real repositories in hiring tests exist at HackerRank (Code Repository questions), Karat and SkillPanel. You only see those when an employer invites you.
• Open-source "good first issues" give you the full, real repository and real maintainers. If you want to contribute to a project for real, that is the better route. It comes with no guaranteed verdict or timeline, and issues can already be claimed.

Where it stands

PushForces has 180 tickets as of September 11, 2026, all in the Backend field. The board lists 28 codebases from 27 projects. The authentik project has one ticket family for its Go code and one for its Python code. A few tickets (the Dart app and parts of Stremio Web) sit in client-side code. We filed them under Backend for now.

The spread by difficulty:

Difficulty	Tier	Tickets	Time estimate	XP	Runs in
1★	Good first ticket	46	15 to 25 min	+160	Your browser
2★	Routine	47	30 to 45 min	+320	Your browser
3★	Standard	36	45 to 75 min	+640	Your machine
4★	Complex	34	1.5 to 2 hours	+1,280	Your machine
5★	Critical	17	2 to 4 hours	+2,560	Your machine

By the files you actually edit, about 80 tickets are Go, 36 Python, 19 TypeScript, 17 JavaScript, 11 Dart and 6 Java. The other 11 sit on the OpenTelemetry Demo, which mixes Go and Python.

Where the bugs live, by area:

• Formance Ledger: a programmable financial ledger in Go, and home of LED-01.
• Ory Kratos, Dex and authentik: identity and login. Email validation, OIDC scopes, PKCE, LDAP attribute sanitizing.
• Casbin: authorization rules, including KeyMatch2 RESTful pattern matching.
• Prisma and Ent: ORMs and query builders, where one missing quote ruins your day.
• JupyterHub, Kolibri, NetBox and CommCare HQ: large Python platforms with long histories.
• LiveKit, Navidrome and Stremio Web: real-time and media.
• Train Ticket and DeathStarBench (research benchmarks for microservices), plus the OpenTelemetry Demo (a demo app).
• BigCache, python-diskcache and node-lru-cache: small libraries that make good 1★ warm-ups.

Seven more projects fill out the list, including one Dart app. A few of them are smaller or less well known, and their ticket pages name them less clearly.

Usage is small. Across the whole site, people have shipped a fix 23 times. Our two team accounts shipped 17 of those while testing the pipeline. Those 23 fixes cover 18 different tickets, and the leaderboard has five names. If you ship one ticket today, you are a statistically significant share of our users.

Where it struggles

These are ordered by how much they affect you today:

• Backend only, for now. The Frontend, DevOps, SRE and Cloud fields already show on the board, and all four hold 0 tickets. We're starting with Backend and will fill the other four gradually. If you don't work on backends, there isn't much here yet.
• Early and quiet. Most fixes so far are ours (see the numbers above). The community discussion channels have 0 threads.
• 3★ and up need setup. You need a verified account (GitHub or Google sign-in), git, and ideally the project's toolchain. That's the point, and it's also friction.
• Difficulty is our guess. Every ticket at a given star level shows the same time estimate, set by us. Expect a 2★ that feels like a 4★ now and then, and please tell us when you hit one.
• No rating yet. Tickets are unranked, and progress shows as XP and levels. Our sign-up page and our "How a ticket works" page still mention an Elo rating (a chess-style skill score). That copy describes a rating we haven't turned on.
• Some language labels are wrong. About a dozen Python and Go codebases show up as TypeScript on the ticket board, and 55 tickets have no language label. The file extensions inside each workspace are correct.
• 180 tickets might not be enough. We don't know yet, and that's one of the things we're asking you.

What's next

Feature tickets come next. Fixing a bug is half of the day-one problem. The other half is building something new inside a codebase you didn't write. You have to find where the feature belongs, what it touches, and which conventions you're about to break. We'll also add the other four fields (Frontend, DevOps, SRE and Cloud) gradually, on the same kind of real projects.

One question for you: which open-source backend should we break next? If you try LED-01, we'd also love to know how long it took you, and whether 180 tickets feels like enough. We read and answer every comment ourselves.

Next in this series: how we break a real repository on purpose without turning it into a trivia quiz.

This post was drafted with AI assistance, then edited and fact-checked by the PushForces team. The story, the product decisions and the numbers are ours. Every PushForces number was checked against the live site on September 11, 2026. Details about other sites come from their public pages, checked the same month.