Notes

The Closed Loop: A Member's Case for Process at Hack Club

Hack Club grew extremely fast, and its authority structure did not grow with it. A two-year member's case for published rubrics, scheduled payouts, and separating peer review from money decisions.

Before I start

I’ve been in Hack Club for about two years, since I was twelve.

I want to be specific about what that has meant, because everything after this is going to sound like a complaint and it isn’t one. When I joined, I had been coding for a while and had never finished anything I was proud of. Hack Club gave me the first project I actually shipped, and then the second, and then the habit. It gave me people who understood why I cared about a thing that nobody at my school cared about. It gave me adults who talked to me like a person with judgment rather than a child with a deadline. I have been trusted here in ways I had not been trusted anywhere else, and that trust is the reason I care enough to write five thousand words about how it’s structured.

So this is not a leaving post. I’m not going anywhere. It’s the piece I’d want to read if I were eight months into the community and starting to notice that the gap between what Hack Club says about itself and how it actually works is widening.

Here’s the short version. Hack Club grew extremely fast, and its authority structure did not grow with it. A community that ran on informality because everyone knew each other now runs on informality as a system of who is closest to headquarters. That’s not a moral failure, and I don’t think anyone chose it. It’s what informality turns into at scale, the same way an unmaintained codebase turns into a codebase where nobody dares touch the auth.

The rest of this is the detail: what changed, who gets to decide what, why a peer holds authority over another peer’s money, what happened to a program I spent months building, what I think should change, and the strongest argument I can make against myself.

What changed

Stardance was the hinge.

Before it, Hack Club felt like a group chat that occasionally shipped something enormous. There was a rhythm: one big thing at a time, and a community organized around it. After Stardance, the numbers are different in kind rather than degree. The 2025 annual report says about 23,000 projects shipped, up from 5,600 the year before. Roughly 80% of staff are under 19. Twenty teenagers were hired into paid gap years. Tens of thousands of members. Those are genuinely extraordinary figures for a nonprofit, and I don’t want them lost in what follows, because the thing I’m criticizing is downstream of the thing that worked.

But look at what those numbers actually mean in practice.

23,000 projects means 23,000 reviews. Not 23,000 clicks, 23,000 judgment calls about whether a thing is finished, whether it’s good, whether it’s worth hardware, whether it’s worth cash, whether it counts. Every one of those decisions has a teenager on one side of it and, increasingly, a teenager on the other.

20 gap years means 20 people who went from being members to being staff, in a community where they were already known, already had friends, already had a reputation, and in some cases are now in a position to decide things about the people they were competing with last year. Nobody designed that. It fell out of hiring people you already trust, which is how every small organization hires, and which stops working at exactly the moment the organization stops being small.

80% of staff under 19 means the median person designing programs, reviewing projects, and setting the tone is a teenager. That’s the whole pitch, and honestly it’s the reason the programs are good. A 30 year old would not have designed most of what works here.

And then there’s the part that gets said less often. Program design is teen run. Legal, financial, and employment authority sits with a handful of adults. Those are two different claims about who owns the org, and both get made depending on who’s asking. When someone wants to celebrate teen leadership, program design is the evidence. When something goes wrong, the answer is that the adults make the real decisions. Both are true. Together they mean nobody is fully accountable for anything.

That’s the shape of the problem. Not that teens have power, but that power here is real, unelected, unlisted, and revocable only by people who are not required to explain themselves.

The staircase

Everyone talks about the pipeline as if it’s a pipe. It’s a staircase, and every step has a person standing on it deciding whether you go up. That’s the actual mechanism, so let me walk it.

Step one, member. Anyone can join the Slack. This is the only step with no gatekeeper and it’s genuinely open, which is why the community keeps getting new people who are surprised by everything above it.

Step two, shipper. You build something for a program. Now you’re interacting with review for the first time. A person reads your project and decides whether it counts and what it’s worth. If you’ve never done this before, the experience is strange, because you’re used to school where the criteria are written down and the marker doesn’t know your name. Here the criteria are unwritten and the marker is in your group chat.

Step three, helper. Someone notices you’re good, or you volunteer, or you’re friends with the right person. You start helping review, or answering questions, or running a channel. There is no posting for this role, no criteria, and no record. It’s an invitation. This is the first genuinely closed step, and it’s the one that most determines the rest, because everything above it requires having been at this one.

Step four, reviewer. Now you’re making decisions that affect other people’s money. Nobody trained you. There’s no rubric, or if there is one it varies by program. You have no term, no review of your reviews, and no stated duty to explain your reasoning. You’re fourteen and you have a queue.

Step five, organizer. You run a whole program. You have a budget, a sponsor, a target number, and a Slack channel full of people who want a piece of it. This is a huge amount of real responsibility and, from what I can see, extremely uneven support.

Step six, gap year. You’re hired. You can now do, officially and with pay, what you were doing unofficially for free before. You can also now be the person who picks the next organizer.

That staircase is not an exaggeration of the pipeline. It is the pipeline. And every riser except the first one is a person’s judgment rather than a published rule.

Here’s the part I actually want to argue about, because it’s structural rather than personal.

To run a program, you need to be a gap year. To be chosen as a gap year, you need to be well known, which in practice means you have already run programs. So the entry requirement is the thing you are trying to earn. Knowing the right people isn’t a shortcut around that loop. It’s the only working path through it.

This year the loop tightened. Gap years run training YSWS to learn how to run programs, and those training programs sit in the same sponsorship queue as everyone else’s. The people learning the job are occupying the slots that running a program is supposed to earn you. Nobody did that on purpose. It’s the natural result of solving a capacity problem by promoting insiders into the exact positions outsiders were already competing for.

The visible result is an inner circle. I want to be careful with that phrase, because it sounds like an accusation and it isn’t. The people inside it work extremely hard, several of them have done more for me than any adult outside my family, and I have no reason to think any of them are acting in bad faith. But a circle nobody drew is still a circle. From outside, you can feel the wall without being able to point at it, and a wall you can’t point at is worse than one you can, because there’s nothing to appeal to and nothing to fix.

I want to be fair to the people who climbed the staircase before me. They didn’t invent this. They climbed the only staircase that existed, and then some of them started standing on the steps. What I’m describing isn’t a group of people keeping others out on purpose. It’s a selection mechanism that only knows how to select for people it already knows, and the only way to be known is to have been selected.

The line between a peer and staff

Here’s the thing that bothers me most, and it took me a while to name it clearly.

There is supposed to be no real difference between a member and staff. That’s the ideology and it’s a good ideology. It’s also not true, and the blur runs in whichever direction is convenient at the time.

A teenager in a staff-like role is held to neither standard. When something goes wrong, they’re just a kid, and it would be unfair to hold them to the standards of an employee. When they want pay, hours, or recourse, they’re staff, and it would be unreasonable to give them the latitude of a volunteer. Nobody is doing this cynically. It’s just what an unstated role does: it accumulates all the authority of a job and none of the obligations, and everyone involved gets to reach for whichever half is useful in the moment.

The concrete ambiguities add up fast. If a teen staffer is in a channel as a moderator and something happens, who investigates? If they’re accused of something, what happens to them, and who decides? If they’re burnt out, does anything happen at all, or do they just quietly stop? If a member has a serious problem with a decision a teen staffer made about them, who do they talk to? If they need to make a weird request out of hours, is that appropriate? Is the teen staffer protected by any policy, or are they exposed? None of these have published answers, and the absence of published answers is itself an answer: it means every one of these situations gets resolved by whoever is present and whatever the vibe is.

There is also a version of this that I think is a genuine safety issue and not just a fairness issue.

People in this community have real power over each other. They can approve or deny money, remove you from a channel, decide whether your project counts, decide who gets picked next, decide whether your program exists. A lot of them are my age. Some of the people they have power over are 13. And much of it happens in DMs, where nobody sees it.

I am not accusing anyone of anything. I want to be extremely clear about that. But an unaccountable fourteen year old with discretionary authority over other kids, in a private channel, with no oversight process and no reporting path that doesn’t feel like snitching, is a design that has a bad failure mode. Not because teens are dangerous. Because any adult system with power over minors and no oversight produces abuse, sometimes, and the whole point of a process is that you don’t have to trust individuals to be exceptional. Hack Club’s safety work has clearly gotten more serious over the last year or two, and I don’t want to understate that. What I want is for the informal authority that sits below the safety policy to be covered by something too.

Power over other people is a strange way to give teenagers agency. There are better ones: pay them, teach them, let them own something real, give them a budget and a mentor and a title that says what it’s for. None of those require the ability to rule on someone else’s grant. I’m all for teens having authority over their own work. I’m against teens having undeclared authority over each other, because that’s the version that can be abused, and it’s the version nobody has to defend.

Why a teenager shouldn’t decide another teenager’s money

This is my main objection and I want to state it precisely, because the usual reply misses the point entirely.

The reply is “there’s a re-review, you can appeal.” That’s true. There is a second path, and I’ve seen people use it. My argument is not that the process is missing. It’s that a peer shouldn’t be the one making this decision at all.

Four reasons.

A peer has no standing over a peer. Take any other fourteen year old and give them the power to decide whether another fourteen year old receives several hundred dollars of hardware, and we would call that a badly designed system. Here it’s the default. Nobody argues for it. It arrived.

The reviewer and the reviewed are in the same social graph. They’re in the same channels, competing for the same roles, ranking on the same leaderboards. They may be friends, or rivals, or the person who got the gap year you wanted, or the person whose project got more attention than yours last cycle. You cannot ask someone to be impartial about a friend’s application while also ranking them against that friend in the same community. That’s not a training problem. It’s a structural one.

The reviewer bears no cost for being wrong. No liability, no consequence, nothing worse than a mildly awkward conversation with someone they’ll see tomorrow anyway. Authority with no consequence attached is the definition of power, and it’s precisely what makes abuse possible rather than merely unlikely. If I reject your grant and I’m wrong, I lose nothing. You lose a project. That asymmetry is the whole problem in one sentence.

And the person being reviewed can’t safely disagree. This is the part that makes the appeal useless. The re-review exists on paper. Almost nobody will use it. To appeal, you have to ask a group of your peers to overrule another peer, in public, in a community where reputation is the currency and reputation is exactly what gets you the next role. You are asking to be right at the expense of someone’s standing. So the escape hatch is real and unusable at the same time. An appeal that costs you social standing isn’t a remedy, it’s a loyalty test.

I’ve asked, in the Slack, why another teenager gets to decide whether my grant is approved. I have never gotten an answer that wasn’t some version of “that’s how it works.” And to be fair, nobody has ever been rude about it. But “that’s how it works” is the answer a system gives when it hasn’t been designed.

The fix isn’t more review, and it isn’t firing anyone. It’s separating two questions that are currently fused into one person’s judgment.

Is this work real and does it meet the bar? Peers are excellent at this. It’s technical, it’s checkable, it’s exactly what peer review is for, and it’s how open source has worked for thirty years. I don’t want an adult deciding whether my chip design is good. I want someone who knows what a chip design is.

How much money does it get? That should follow a published rule, not a person’s opinion. If payout is defined by hours, complexity, and a written schedule, the reviewer’s job becomes verification rather than gatekeeping. A peer checking a checklist against your repo is fine. A peer deciding your number is not.

That one change does more than any amount of reviewer training, because it turns a judgment call into a rule, and rules can be argued with. You can’t argue with someone’s taste. You can absolutely argue with a schedule.

YSWS as fiefdoms

Every YSWS is one person’s program, with its own rules, its own review bar, and its own payout scale. There’s no shared standard across them and no published definition of finished work.

The consequence is that the same quality of project pays differently depending on which program it ships into. Two people can build the same thing, spend the same number of hours, and one gets hardware while the other gets a polite rejection, purely because of which program they happened to pick and which reviewer happened to be on shift. That’s the actual unfairness, and it isn’t fixed by being nicer about it. It’s fixed by writing the bar down. If a reviewer can’t state the rubric in a sentence, then the rubric is their mood that week.

I don’t think most reviewers would disagree with this. Ask someone what the bar is and they’ll usually give you a thoughtful answer. The problem is that answer is in their head, which means it can’t be appealed against, it can’t be learned in advance, it changes when they’re tired, and it leaves with them when they stop doing the role.

The last one is the quiet cost of fiefdoms. Every time an organizer graduates or burns out, their rubric goes with them, and the next person either invents a new one or just doesn’t have one. Hack Club has been running programs long enough now that there should be something written down that outlives the people who wrote it. Instead there’s a Slack history.

Same goes for the rewards themselves. The grant, the hardware, the prizes, the leaderboard placement, the shells, however it works this cycle. Every one of these is a signal about what kind of work the org values. If the signal is inconsistent between programs, the community learns something other than what was intended: it learns that the meta matters more than the work.

Regulation, or help

There’s a position I’ve seen argued, more than once, in meta: that YSWS shouldn’t be regulated because regulation would kill teen initiative and turn everything into bureaucracy. I want to take that seriously, because it’s not a stupid argument.

My disagreement is this. When you have teenagers running programs with real budgets, real sponsors, and real people’s expectations attached, you’re choosing between regulated and unregulated, not between regulated and free. Unregulated doesn’t mean nobody is in charge. It means the person in charge is a teenager with a sponsor, a deadline, and no one checking what they promised.

Right now the failure mode is obvious and quiet: a program runs, the organizer is overwhelmed, promises slip, sponsors get nervous, projects go unreviewed, people stop hearing back, and eventually the program just stops being mentioned. Nobody decides to kill it. It dries up. The person who absorbs all of that is a teenager who wanted to do something good, and there is no process that catches it early.

A bit of weekly adult scrutiny would catch most of that. Not a committee. Not a sign off process that adds two weeks to anything. One named human, fifteen minutes a week, asking: what did you promise, what’s on fire, do you need something. That’s it. That protects the organizer far more than it constrains them, because right now if a program fails, the teenager who ran it absorbs it personally, and often quietly leaves afterwards having learned that running things is a way to get hurt.

Scrutiny is not distrust. It’s the thing that lets you hand someone real responsibility without betting the whole program on them being right. The strongest possible vote of confidence in a teen organizer is spending an adult’s hour a week making sure the thing they’re carrying doesn’t crush them.

There’s a related resource question I can only see from the outside. This year gap years run training YSWS to learn how to run programs. That’s a reasonable way to train someone. But those training programs need sponsors, and sponsors are finite. So the training pipeline and the community pipeline are competing for the same money, and the training pipeline has the advantage of being run by people with direct access to whoever allocates it.

I don’t know whether that competition is real, because nobody publishes how many community slots exist per cycle. That’s the single number that would tell me whether my frustration has a cause or a story I’ve made up. Publishing it costs nothing and settles the argument. If training programs don’t touch community slots, then I’m wrong and I’ll say so in public.

What happened with Hardwire

Last summer I organised Hardwire, a chip making YSWS.

The first commit is from 22 June 2026. We built it in public, and I want to describe what those weeks actually were, because “a chip program” undersells how much of the work had nothing to do with chips. We had to figure out what a beginner can realistically fabricate, because the honest answer is that a full custom ASIC is not a beginner project and pretending otherwise sets people up to fail. We had to figure out what a sponsor would actually have to cover: tapeout is not cheap, and the educational shuttle services that make this possible have minimums and calendars. We had to figure out how you review a chip design when you’re my age and the tools are enterprise software. We wrote and rewrote what the deliverable even is, because “design a chip” can mean a schematic, a layout, an FPGA prototype, a submitted die, or a promise, and those are wildly different amounts of work.

That’s the work. Ten weeks of it, in public, and nobody asked us to do it.

We went looking for sponsorship. We got no route in. Not a no, exactly. An absence of a route, which is worse, because you can’t appeal a route that doesn’t exist.

On 31 August a near identical chip program appeared, run by staff.

I don’t know how that decision was made and I am not accusing anyone of taking anything. What I can say is what the process did: there was no offer to merge, no path to hand our work over, no conversation about whether these should be one program. We were told we’d need to change our idea if we wanted to run at all.

Maybe a defensible case existed. Chip fabrication is expensive, supply chains are real, a first time organizer is a risk, and a staff-run program has more chance of actually delivering dies to teenagers. I would have accepted that argument in June. I would have accepted “we want to do this ourselves, come help” in June. I would have accepted almost anything that treated that work as an input rather than an obstacle, including being told no immediately and clearly.

But a defensible decision reached by quietly duplicating ten weeks of public work and telling the people who did it to come back with something else is still a process failure. The decision might have been right. The process was not. And the process failure is the part that generalises, because it will happen to the next person with the same idea and less patience, and next time they won’t write an essay, they’ll just leave.

I want to be fair to the people who made that call. I’ve watched staff do enormous amounts of unpaid work to keep programs alive. I don’t think anyone sat down and decided to waste my summer. I think there was no mechanism that would have let them include us, so the default was to start fresh with someone already inside. The default is the problem, and defaults are what you get when nobody writes the process down.

The thing I keep coming back to is that this is what the staircase feels like from underneath. I didn’t lack ability. I didn’t lack commitment, or a plan, or public work people could see. What I lacked was a step on the staircase, and there is no application for that step.

The strongest case against everything I’ve said

I’ve been arguing for one thing, which is process. Let me make the best argument I can against it, because it’s a better argument than most of the replies I’ve actually seen.

Informality is the product. Hack Club works because it doesn’t feel like an institution. The reason a thirteen year old in the middle of nowhere joins is that it feels like a group chat where someone will actually reply. Every process I’m asking for is a layer between people, and layers are what make institutions feel like institutions. There’s a real version of what I’m proposing where someone has to fill out a form to be helpful, and that version is worse than what exists now.

Formality has a cost that falls on the people with least slack. If reviewing requires a written rubric, a second reviewer, and logged decisions, the people doing it are unpaid teenagers. You’ve just made their unpaid work slower and heavier. A lot of them will stop, and the ones who don’t will burn out faster. You can’t demand more process from volunteers without funding it.

Teen agency requires real risk. If the org’s position is that teenagers should be trusted with real things, then they have to be trusted with things that can go wrong. A community where a teen can only make decisions that adults have pre-approved isn’t teen-led, it’s teen-themed. Some of the messiness is the price of the thing I claim to love.

HQ is not sitting on a surplus of adults. The reason informal authority exists is that there aren’t enough people to formalize it. Asking for weekly adult review of every program is asking for a resource that may not exist, from an org that runs on a nonprofit budget and a lot of goodwill.

And the loudest critics of this place are usually people it removed. That’s true, and I understand why it makes staff defensive about criticism generally. I’m still here. I like it here. That’s not a credential, but it’s why I’d like this read as maintenance rather than attack.

Here’s what I think survives all of that.

None of my asks require a form. A published rubric is a paragraph on a page. A payout schedule is a table. Naming an adult per program is a line in a spreadsheet. Term limits reduce work, because they rotate out people who are tired. Open calls for roles cost one Slack post and produce better candidates than invitations do.

The one genuinely expensive ask is adult time, and I’d rather argue for it honestly than pretend it’s free. If the answer is “we don’t have the hours,” that’s a real answer and I’d like it in writing, because it would mean the constraint is funding and not philosophy, and funding is a thing that can be raised. What’s not acceptable is informality being justified as a philosophy when it’s actually a staffing shortage, because then the mess gets defended on principle and never fixed.

And to the “teen agency requires risk” point, which is the strongest one: I agree with it. I just think the risk should be borne by the people who chose it. Right now the risk of an unaccountable reviewer is borne by whoever got reviewed, and the risk of an unsupported organizer is borne by the organizer. The people making the structural decisions take very little of the risk. That’s not teen agency. That’s teen agency for the people inside the circle and teen exposure for everyone else.

What it costs to publish this

I’ve been writing this for a while and I want to be honest about the part that isn’t about structure.

Everything in here is describable without naming a single person, and I’ve done that deliberately. But this community is small enough that people will know who I am and probably who I mean, and there is a real chance that publishing it costs me something. Not moderation, probably. Something softer than that: getting quietly deprioritized, being read as difficult, having my next application looked at by someone who remembers the essay.

That’s exactly the mechanism I’ve been describing, which is the annoying thing about it. The reason critique here is rare isn’t that people are happy. It’s that the cost of complaining is paid in the same currency as the thing you want, which is standing. If I’m wrong about the informal authority problem, then publishing this should be completely harmless, and I’ll look slightly ridiculous for worrying.

There’s a version of this that gets dismissed in one line, and I’d rather name it than pretend it isn’t coming. I’m fourteen. The easiest reply to everything above is that I don’t know how organizations work yet, that a fourteen year old can’t judge whether a call was reasonable, and that in a few years I’ll understand why things are the way they are.

Maybe in a few years I’ll agree with parts of it. But look at what that reply actually does. It doesn’t touch the rubric, the appeal, the slot count, or the duplicate program. It replaces an argument with a fact about my age, and then treats the age as the answer. If the only people allowed to ask how decisions get made are the ones old enough to already be making them, then nobody affected by a decision will ever be the one asking, and a community built on trusting teenagers will have quietly decided that teenagers can be trusted with work but not with questions.

That’s not a defence of Hack Club. That’s the mechanism this essay is about.

I’ve decided it’s worth it, obviously, since you’re reading it. But I want that on the record, because the fact that I had to think about it is data.

What I’m asking for

None of this is expensive and none of it needs new staff.

  1. Publish a minimum standard for YSWS review. One page, the same across programs. What counts as finished, what counts as above the bar, what evidence is required. If it’s one page it can be argued with, and if it can be argued with it can improve.

  2. Make payout follow a written schedule of hours and complexity. Not a formula that decides everything, just a published default with room for judgment on top. The point is that the starting point is a rule rather than a feeling.

  3. Separate technical review from the money decision. Peers verify the work, because peers are good at that. The amount follows the schedule. A peer checking a checklist against your repo is fine. A peer deciding your number is not.

  4. Give delegated roles a written scope and a term. If someone can approve or deny a grant, or moderate you, or remove you from a channel, that is authority, and it should have an end date and a description of what it covers. Rotation also solves burnout, which is a problem nobody is currently solving.

  5. Open calls instead of invitations for program roles. Post the role, say what it requires, take applications. Recruit at least partly from outside the existing programs. It costs one Slack message and it breaks the reproduction loop without requiring anyone to admit the loop exists.

  6. Publish how many community YSWS slots exist per cycle, and whether training programs count against them. This is the number that would settle most of this argument.

  7. Assign a named adult to each YSWS, with a weekly check in. Even fifteen minutes. Especially for first time organizers. This is the ask that protects organizers most and costs least.

  8. Publish one page on what happens when a member has a problem with a decision made by a teen staffer. Who they talk to, what the process is, what happens next. Right now the answer is “it depends who’s around.”

If I only got one, I’d take number 3, because it removes the thing that made me feel like a supplicant in the first place. If I got two, I’d add number 8, because it’s the one that turns undeclared authority into something a person can actually use.

The reason I wrote this

Hack Club is the only place I’ve been where being fourteen and building something weird was the normal thing to do rather than the exception. Two years in, I still think that’s worth protecting, and protecting it means the org has to be able to explain its own decisions. Right now it mostly can’t. Not because anyone is hiding something, but because nobody wrote it down, and the people who know how it works are busy.

I don’t want Hack Club to become slower, more careful, and less fun. I want it to be able to grow without the only path upward being who you know, and I want the people who take on real responsibility here to be protected while they do it. Those are small asks. They’re the kind of small asks that get waved through once someone puts them on a page with a number next to them.

I’d rather be building chips. Write it down and half of this essay becomes unnecessary, which is the outcome I’m actually hoping for.