Deven Jadhav

The plan for hack club world dominance

2026-03-05T03:17:13Z

Good hackers / engineers are never quite an employee. They can be managed, but rarely directed. They follow their own curiosity their own way, always honestly, often infuriatingly, along with their sense of taste for which problems are interesting and which aren't.

This writeup is meant to be my best-effort explanation of what exactly the Hack Club YSWS model is, why I think its genius, and how it lets us hire some of the best, most ambitious engineers, entrepreneurs and problem solvers without having to deploy a swarm of middle managers.

What the hell is a You Ship We Ship (YSWS)?

A teenager (age 13-18) is challenged to engineer a real shipped project from scratch, and they get prizes to support them on their next project, like a Raspberry Pi, a soldering iron, or a flight scholarship for a hackathon when they publish their work.

A shipped project always has an open source GitHub repo, a live play link (imagine an itch.io link for a game, a link to a compiled .exe file for a windows app, or a link to a web app, etc!). For hardware projects, we make an exception for the play link and let it be substituted by a link to the schematics, a video of the project, etc.

Additionally, to ensure that a project was shipped by a real person, and to ensure compliance with United States anti-terrorism laws, we also collect home address, date of birth, and the first and last name of the person shipping the project. This means that every dollar spent by a Hack Club YSWS program can be tied back to the individual hack clubber that received a prize, earned a travel scholarship, or got some sticker sent to them in the mail.

Weighted projects and time spent building

A shipped project with 10 hours of time spent building through good practice. Aimlessly vibe-coding is not good practice. Hours spent watching a YouTube tutorial is not good practice. A project with 20 hours counts as 2 weighted projects, 30 hours as 3 weighted projects, and so on!

Time spent debugging and problem solving is good practice!

Each YSWS program must use different methods to determine how much time was spent on each project. Time spent on projects must be well-substantiated and must stand extensive scrutiny from the YSWS leadership team because it is directly tied to financial incentives.

The most popular tool for time tracking and substantiating “Hours spent on good practice” is Hackatime, but some programs may sometimes choose to use different methods of calculating this.

The bottom line though is that this number must always be high integrity and well-substantiated (and almost always a lower-bound estimate of the actual time spent coding).

Incentives for Shipping

I personally deeply believe in the intrinsic joy of building personal projects. Given this very strong belief, how many projects have I shipped without an incentive as a teenager? Zero.

At least here in the US, parents put a lot of pressure on teenagers to succeed, but they often lack understanding of the importance of project building. Some things from parents we hear:

“Don’t build projects, enroll in 15 AP courses”.

“Run 3 clubs, get a summer research internship.”

“Please, god, don’t spend your time working on projects. You’ll never get into college.”

This is why incentives are important, especially to get beginners hooked on to the very addictive journey of building personal projects. In Hack Club, we’ve seen that the following incentives really work (in decreasing order of effectiveness):

Adventures: Both intellectual and physical adventures.
1. Examples of intellectual adventure include Easel - a YSWS where you make your own programming language and Saycheese - a YSWS where you hide your program in a QR code.
2. Examples of physical adventure include Hack Club Trail (7 days in-person backpacking adventure on Pacific Crest Trail) and Hack Club Juice (In-person game jam in Shanghai, China)
Friendships: Getting to meet new people online that share your interests and just “get” you, and then being able to meet them in-person at a hackathon. We invest hundreds of thousands of dollars on flight scholarships for teenagers to go to hackathons each year so they can meet their internet friends IRL and spend time building projects with them!
Prizes / Electronics / Tools: We give out millions of dollars in Laptops, iPads, 3D printers, soldering irons, hardware components, etc to teenagers and this serves as an excellent incentive for a beginner friendly YSWS since it’s so easy to understand what these prizes are and work towards getting one!

I don’t want our YSWS programs to feel like an endless stream of transactions, so I especially appreciate programs like Siege and Blueprint that run with the same underlying economics, but don’t feel as transactional. Remember — everything in Hack Club is a YSWS!

Spend and Economics

Hack Club has a very sophisticated way of thinking about spend, and we directly tie it to shipped projects

As a member of the YSWS team, each person gets a 1000 USD personal YSWS budget when they get onboarded onto the team.

Then, for every program that produces one weighted (10 hours) project, we pay out 85 USD to the program budget (8.5 USD per hour spent building with good practice).

For programs that do not have an in-person component, members of the YSWS team are encouraged to spend 50 USD per weighted project (or 5.00 USD per hour). Any left-over money from the program is then transferred into their personal YSWS budget.

Over the first couple months, a lot of the gap years will often accumulate 15-20K USD in their personal YSWS budgets, and they can then use this money to run bigger, more expensive programs. That way, they’re allowed to combine their personal YSWS budget funds with the $85 per weighted project program budget to run programs that may need more money!

As a member of the YSWS team, if you play your cards right, you can spend as high as 200 USD per weighted project running really cool programs towards the end of your gap year.

Summer 2026 and the path forward

Is this the perfect model that helps us get teenagers shipping? No.

Is it pretty damn good at what it’s supposed to do? Yes.

I say this in the most candid, unbiased way possible, but I feel like there isn’t a better deal as a teenager fresh out of high school than a gap year with Hack Club. Thanks to this system, and the ownership / high agency it offers, a gap year fellowship at Hack Club is comparable (and in some ways, even better than) the Thiel Fellowship!

As a teenager fresh out of high school, you get paid 50k a year and a access to a pool of 8.5 million dollars to run events around the world and build programs that get tens of thousands of users. There are no approvals, no paperwork, no bureaucracy. All you need to do is get teenagers to ship weighted projects, and you get 85 dollars paid to your program budget.

It’s also worth mentioning that this system is bottomless, which means that there’s no real cap on how much money you’re allowed to spend as a gap year at Hack Club!

We’re still figuring out a system and the best path forward for this, but I’m really happy with what it has been able to unlock for Hack Club. At its core, Hack Club’s mission is to transform teenagers from consumers into creators, fostering a love for building cool, fun, and meaningful things.

We want to make building projects a national pastime by 2030, with Hack Club becoming as ubiquitous as the Boys and Girls Scouts of America were in the 1970s.

I personally want to live in a universe in 2030 where the CEOs of Netflix and Meta get to work every morning, and start scheming the downfall of Hack Club because teenagers around the world are now suddenly spending all their free time building things instead doomscrolling and being on TV all day, and I think the current implementation of the YSWS system is going to get us really frickin close to that goal ;)

[email protected]?subject=Re%3A%20The%20plan%20for%20hack%20club%20world%20dominance">Reply by email

I asked a coding agent to come up with a religion

2026-01-18T03:08:36Z

This will be a work in progress post. The results of this experiment have been quite interesting and I’m still digesting them.

Here’s a basic summary:

I gave Amp (which, as far as I understand, uses Clause Opus 4.5) some instructions to create its own religion and build me a website for it. In the same prompt, I told Amp that this was a critical and important task, and that it should perform it with utmost care and precision.
Amp spent 9.35 USD thinking for almost 7-8 minutes and came up with a terrible looking, almost conspiratorial website.
I then asked Amp to write some more CSS to make it look like a boring government website, using lots of blues and whites and blacks and Serif fonts for titles.

The final output now lives at manifest.deven.dev.

Honestly, I think I’m going to add a pop-up explaining what this site is. I do not want people to think I’m schizophrenic.

More thoughts soon!

[email protected]?subject=Re%3A%20I%20asked%20a%20coding%20agent%20to%20come%20up%20with%20a%20religion">Reply by email

Unreasonable Hospitality

2026-01-15T15:54:15Z

This is a part of an internal memo I circulated with the events team. If you are reading this and not a part of the team, you might be missing some context!

The last few weeks have been such whirlwind for me. I finished the first semester of my Sophomore year at UNC, flew out to San Francisco for Prototype, went to India right after to visit family for just over a week, and then flew right to Austria for Midnight.

I've been reflecting on the experiences I've had for the last month, meeting and talking to Hack Clubbers- and I think I have a couple of important takeaways.

Firstly, Hack Club is really huge in so many ways but feels small in a lot of other ways. Like the fact that Hack Clubbers were literally the showstoppers at this year's CES at Lisa Su's keynote still blows my mind. We consistently seem to have a gazillion different things happening at the same time, have such an incredible team of gap years running programs, in-person events, and everything in between.

Secondly, peer-to-peer and staff-hackclubber interactions shape a large part of what makes Hack Club so special for our students. Someone came up to me after Midnight and said that they were so grateful for Hack Club and that it has had such a big impact on their life. They also mentioned something oddly specific- less than a year ago, the same person happened to run into me and a bunch of other Hack Clubbers at a public library and they mentioned that they distinctly remember me going out of my way to find them a chair to sit down. They said that they clearly remembered this interaction and that really made them feel like they belonged in this community.

As we grow and continue to serve more teenagers than ever, I do not want us to lose the magic of a great personal 1:1 connection, and I think this is the right time for us to build systems around incentivizing kindness and this idea of unreasonable hospitality.

So- what exactly is unreasonable hospitality? The remarkable power of giving people more than they expect. Here are some examples I've encountered before:

You overhear someone at an in-person event saying they wish they had some boba right now. You decide to go out and get boba for them and the group.
Someone emails you with a small concern about the logistics of an event. You respond back with an elaborate, over the top email offering support and also offering a 1:1 zoom call for any further questions.
There is a limited number of hoodies / merch / food at a hackathon, so you decide to make sure the participants get one before you do.
Someone is feeling sick at a hackathon, and you go out your way to get them food, water, and make sure they're well rested.
Overhearing someone say it's their birthday and rallying everyone for a surprise announcement + cake.

There are two aspects to running something that's hack clubber-facing successfully: Service and Hospitality

Service at a hackathon is the basics: wifi works, food shows up, judges are briefed, submissions close on time. Hospitality is how a nervous first-time hacker feels walking in: do they feel like they belong? Does someone notice they're lost and help them find a team?

Starting today, we are creating an incentive structure that starts with gap years and RMs, and seeps all the way down the line to event volunteers. We have yet to formalize this with metrics, but here's a general idea:

Staff members are highly encouraged to perform "Acts of unreasonable hospitality" as outlined in the examples listed above.
There will be a form in Attend + other places online where you can document these interactions, optionally attach photos, and earn a "brownie point" for each act of unreasonable hospitality.
There will be a shop where you can cash out brownie points for rewards like orpheus plushies, flipper zeros, and more!
All feedback forms will also have a section for staff kindness + compliments, and any mentions made directly by participants will earn you bonus brownie points.

Campfire and Campfire Flagship will both be a beta test for this program, and we will roll it out to future events if things go well! The whole point of this is to give more people that warm fuzzy feeling that got us all so deeply involved in Hack Club.

Will share more details on exact implementation soon.

Until later, Dev

[email protected]?subject=Re%3A%20Unreasonable%20Hospitality">Reply by email

Field notes on writing recommendation letters

2025-11-02T14:25:55Z

I’m a sophomore in college and I’m still traumatized by Common App in the big 25s. How, you might ask? Recommendation letters!!!

I’ve been writing these for the last 4 years (Yes, I’ve written recommendations for people applying to university even when I was in high school), and I think I have a good formula for how to get the most out of them.

I’m mainly writing this piece for myself when I have to write these letters again next year, but I also want something I can share with people so they send me the right information beforehand.

First of all, I only write letters for people I have closely worked with, and feel comfortable personally endorsing. If I decline to write a letter for you- it’s nothing personal, I just don’t know you very well in a professional capacity. This also means that I cannot write letter for you that I think is high quality ¯\_(ツ)_/¯

Brag Sheets

Brag sheets are, in my opinion, very important when written properly. I like to structure my letters so they are very specific, and describe you as a person in very detailed manner. Here’s an ideal brag sheet:

What do you want out of this letter? Some people want me to structure it around their technical accomplishments, others want me to talk about leadership, kindness, or their entrepreneurial outlook. I need to know what you want the letter to focus on!
When did I first meet you? Give me the exact date, event, and a few anecdotes that I can talk about.
Then give me at least achievements you want me to talk about. Eg- I organized X event (include exact dates, timings, number of participants, location, etc). Include at least two specific stories from these achievements (for eg. “I stayed up all night to help a hackathon participant with version control, and they finally ended up shipping a game”)
At the top of your brag sheet, include the program(s) you are applying for. I won’t explicitly mention it in the letter but helps me get a good understanding of what colleges are looking for!

Timeline

If you would like to request a letter from me, please give me at least 2 weeks of lead time to write one. If you need one urgently, ask me anyways but depending on what I’m in the middle of, I might not be able to write one for you in time :(

I’m not interested in sending generic one-size-fits-all letters to universities, which is why it takes time to draft one.

[email protected]?subject=Re%3A%20Field%20notes%20on%20writing%20recommendation%20letters">Reply by email

Airtable Naming Conventions

2025-10-21T01:38:05Z

After countless crash-outs, and 200+ hours spent sword fighting Airtable, I decided to write down a set of best practices to follow when creating a complex Airtable base. If you have any suggestions on what I should add, please do not hesitate to reach out to me!

Field names

snake_case only. No spaces, caps, or punctuation.
Booleans: is_ (state), has_ (possession), can_ (permission).
Examples: is_archived, has_signed_waiver, can_check_in.
Status: status_… (Single select; values in Title Case).
Example: status_review → Draft | Ready | In Review | Approved | Rejected | Archived.
Time & people: *_at (timestamp), *_on (date only), *_by (actor).
Examples: created_at, due_on, approved_by.
Units: suffix numbers with units — _usd, _qty
Examples: amount_usd, duration_min, win_pct.
Counts & flags: _count for counts; soft delete is is_archived (+ optional archived_at, archived_by).
Derived fields:
calc_<thing> (Formula), lookup_<field>_from_<table>, rollup_<agg>_<field>_from_<table>.

Relationships

Linked record (one): singular — event, attendee.
Linked record (many): plural — events, attendees.
Role suffix when ambiguous: event_host, event_venue.

Triggers & automations

Any manual trigger field uses action_…. Type is Button or Checkbox.
Examples: action_send_welcome, action_publish_event.
Automations must be idempotent, and reset the trigger on completion → Very important. If want to hear a fun story about this talk to @msw.
Write standard outputs: last_<action>_at, last_<action>_status (Success/Failed), last_<action>_by, and optional last_<action>_note.
Automation names: auto__<scope>__<trigger>__<action>
Examples: auto__registration__on_create__send_welcome_email, auto__sponsorship__daily__remind_overdue_invoices. It is acceptable for automations to not have any form of snake casing.

Tables, primary field, and IDs

Tables: Title Case, singular: Event, Person, Registration. Join tables describe the relationship: Event Participant.
Primary field: human‑readable autonumber (or a label formula). Avoid raw IDs as primary.
Record ID field: record_id = RECORD_ID() (formula). Always have this when you base interacts with another database (like is the case with Cockpit)!
External IDs: <system>_id like slack_id, hcb_id.

Views & interfaces

Views: [Team] — [Purpose] — [Filter]
Examples: OPS — Action Queue — Due Today, ENG — QA — Missing Email.
Personal scratch views should ideally start with ~name (e.g., ~deven — triage).
Views for running actions begin with Action — … and include only the fields needed.
Interfaces/Forms: Team — Purpose / Form — <Table> — <Purpose>.

Change management

Try not to hard‑delete fields unless things really get crazy. Deprecate with z_deprecated_… and hide from views.
WIP- I’m still testing out the Airtable sandbox, so I’m excited how that makes things earlier for making schema changes. I’ll update this article once I gain some degree of proficiency with the sandbox feature.

Final checklist before you start drowning in data.

Fields are snake_case, with correct prefixes/suffixes.

Triggers use action_…, are idempotent, and reset after run.
Numbers have unit suffixes; percentages use _pct (0–1) unless _pct_100.
Status field starts with status_ and uses Title Case options.
Derived fields follow calc_/lookup_/rollup_ patterns.
Links are singular for one, plural for many; role suffixes where needed.
Views follow [Team] — [Purpose] — [Filter] (add Action — … where applicable).
Any deprecations start with z_deprecated_ and are logged in Changelog.

[email protected]?subject=Re%3A%20Airtable%20Naming%20Conventions">Reply by email