267d5ded756c9291840b637a218c875b031c02c9
new file mode 100644
index 0000000..0cbb895
@@ -0,0 +1,87 @@
+---
+visibility: public-edit
+---
+
+# rookie mistakes & gotchas
+
+real mistakes and gotchas that young builders should watch out for. drawn from actual experience — hackathons, projects, events, college apps, and 30-hour debugging sessions. each one cost time, opportunities, or sanity.
+
+items marked *(common gotcha)* are widely-known traps added from collective wisdom. everything else is from firsthand experience.
+
+---
+
+## college & admin
+
+- [[college-board-student-search]] — opt-in that floods you with fake "you've been selected!" recruitment spam
+- [[naming-wrong-school-in-essay]] *(common gotcha)* — copy-paste "Why Us?" essays with the wrong school name = instant reject
+- [[missing-fafsa-deadlines]] *(common gotcha)* — separate from admission deadlines, often earlier, first-come-first-served
+- [[starting-applications-too-late]] *(common gotcha)* — 12 supplementals due in 3 weeks because you started in November
+- [[stay-on-admins-good-side]] — bank goodwill before you need favors
+
+## demo & presentation
+
+- [[test-demo-before-presenting]] — individual pieces work, full flow doesn't. test the whole thing.
+- [[restart-server-before-demo]] — showing stale code with old bugs on stage
+- [[practice-presentation-once]] — one dry run is the difference between amateur and competent
+- [[emphasize-live-demo]] — judges want to see it work, not hear you talk about it
+- [[memorize-one-liner]] — fumbling "what does it do?" every time someone asks
+- [[pitching-matters-as-much-as-product]] — bad pitch makes a great project forgettable
+- [[slides-as-documentation]] *(common gotcha)* — packing slides with code and diagrams that nobody can read
+- [[no-backup-plan-for-failed-demo]] *(common gotcha)* — live demo crashes, team freezes, judges move on
+- [[jumping-between-features-no-narrative]] *(common gotcha)* — feature tour without a story = forgettable
+
+## scope & execution
+
+- [[perfectionism-over-hackathon-fit]] — spending 2 extra hours polishing when rough would've been fine
+- [[match-the-theme-track]] — great project that doesn't fit the judging criteria
+- [[building-all-in-one-product]] *(common gotcha)* — auth + dashboards + analytics + social in 24 hours = nothing works
+- [[optimizing-for-scale-too-early]] *(common gotcha)* — kubernetes for a project with 3 users (the judges)
+
+## team dynamics
+
+- [[teams-without-shared-understanding]] — nobody knows the plan because there was no plan
+- [[figure-out-what-you-want-before-partners]] — different goals (win vs learn vs network) create friction
+- [[unclear-roles]] — three people on the backend, nobody on the pitch
+- [[solo-vs-bad-team]] — a focused solo builder beats a dysfunctional team every time
+- [[personality-mismatch-under-pressure]] *(common gotcha)* — great at a meetup, terrible at 4am when the API is down
+- [[all-coders-no-communicator]] *(common gotcha)* — incredible project, can't explain it to judges
+
+## networking & events
+
+- [[get-contacts-immediately]] — "i'll get it later" = you won't. they leave.
+- [[record-conversations]] — met 20 people, forgot half of what was said by next day
+- [[how-you-introduce-yourself]] — labels trigger assumptions. lead with what you do.
+- [[phone-on-vibrate]] — embarrassing and avoidable. vibrate is free.
+- [[showing-up-with-no-plan]] *(common gotcha)* — wandering a conference without target connections
+- [[not-following-up-within-48-hours]] *(common gotcha)* — warm connection goes cold in a week
+- [[networking-as-extraction]] *(common gotcha)* — "what can you do for me?" energy repels people
+
+## mindset
+
+- [[ai-rot]] — hours of prompting without independent thought. step away every 10 minutes.
+- [[fomo-trap]] — jealous of what it looks like, not what they're learning
+- [[over-indexing-on-opinions]] — their advice is for their game, not yours
+- [[ai-assisted-imposter-syndrome]] *(common gotcha)* — "did i build this or did the AI?" erodes confidence
+- [[comparison-as-motivation]] *(common gotcha)* — borrowed energy that inverts into despair
+
+## project planning
+
+- [[over-planning-trap]] — four name changes, full PRD, zero users
+- [[relay-build-fallacy]] — 16 friends, sequential handoffs, fell apart
+- [[building-before-validating]] *(common gotcha)* — 3 weeks of coding, zero evidence anyone wants it
+- [[just-one-more-feature-loop]] *(common gotcha)* — perfectionism disguised as product sense
+
+## submissions
+
+- [[check-what-you-submit]] — submitted the wrong video file for a final
+- [[frame-impact-explicitly]] — one missing sentence about impact cost the win
+- [[submitting-right-at-the-deadline]] *(common gotcha)* — upload stalls at 11:58pm, 500 others doing the same
+- [[not-reading-submission-requirements]] *(common gotcha)* — great project, garbage supplementary materials
+
+## technical
+
+- [[esp32-debugging-saga]] — one line fix after 30 hours. the wrong assumption kills you.
+- [[discord-bot-ban]] — automated friend requests = banned. read the ToS.
+- [[hardcoding-secrets-in-code]] *(common gotcha)* — bots scrape GitHub for exposed keys within minutes
+- [[not-using-version-control]] *(common gotcha)* — can't undo, can't find the last working version
+- [[it-works-on-my-machine]] *(common gotcha)* — runs on your laptop, crashes on the demo machine
\ No newline at end of file
new file mode 100644
index 0000000..45dc0df
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# AI-assisted imposter syndrome
+
+*(common gotcha)*
+
+## what happened
+
+you build something impressive with AI tools, and then the question hits: did i actually build this, or did the AI? the more you use AI coding tools, the harder it gets to separate your contribution from the tool's.
+
+## why it's a gotcha
+
+this is a new flavor of imposter syndrome specific to the AI era. you ship features faster than ever but feel less confident about your skills. when someone asks "how does this work?" you freeze because you're not sure you could rebuild it without the AI. over time, this erodes your sense of competence — and if you're prone to [[ai-rot|rotting in AI loops]], the gap between what you shipped and what you understand keeps widening.
+
+## the fix
+
+the tool is a tool. a carpenter isn't an imposter for using a power saw. but you do need to understand what you built. after an AI-assisted session, review the code. make sure you can explain every function. if you can't, that's not imposter syndrome — that's a real gap to fill. use AI to go fast, then slow down to understand. and if you catch yourself [[comparison-as-motivation|comparing your "real" skills to others]], remember: imposter syndrome is comparison turned inward.
\ No newline at end of file
new file mode 100644
index 0000000..d9b90ad
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# AI rot
+
+## what happened
+
+AI rotting is such a thing — watch out for it. so easy to get sucked in, need to have breaks at like 10-minute intervals.
+
+## why it's a gotcha
+
+when you're deep in an AI-assisted coding session and things are breaking, your instinct is to keep prompting. "fix this." "try again." "what about this approach." hours pass. you haven't thought independently in a long time. your brain goes into passive consumption mode — you're not problem-solving anymore, you're just reacting to outputs. and when things are working, you feel productive, but you might not actually understand what was built. that's where [[ai-assisted-imposter-syndrome]] creeps in — the confidence erosion that follows.
+
+## the fix
+
+set a timer. every 10-15 minutes, step away from the screen for even 60 seconds. ask yourself: do i understand what just happened? can i explain this code without looking at it? if not, you're rotting. especially when things are breaking — that's when you most need to step away and think, not keep prompting. and whatever you build in an AI session, [[test-demo-before-presenting|test it end-to-end]] before you trust it. wrong assumptions compound fast, whether they're yours or the AI's — just ask anyone who's lived through an [[esp32-debugging-saga|ESP32 debugging marathon]].
\ No newline at end of file
new file mode 100644
index 0000000..f0b247c
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# all coders, no communicator
+
+*(common gotcha)*
+
+## what happened
+
+team of four strong engineers. built an incredible project. lost to a team with a worse product but a designer and a presenter. nobody on the engineering team could explain what they built in a way that excited the judges.
+
+## why it's a gotcha
+
+a balanced team needs someone who can present, not just code. if everyone on your team wants to be in the IDE, nobody's working on the pitch, the slides, or the demo narrative. technical skill wins buildathons; communication wins hackathons. this is exactly why [[pitching-matters-as-much-as-product|pitching matters as much as the product itself]].
+
+## the fix
+
+actively recruit for complementary skills. one great presenter is worth more than a fourth backend developer. if your whole team is technical, assign one person to own the presentation and protect their time from getting pulled into code — make it an [[unclear-roles|explicit role assignment]]. even coders can present if they [[practice-presentation-once|run through it once]]. honestly, a [[solo-vs-bad-team|solo builder who can present]] beats four coders who can't.
\ No newline at end of file
new file mode 100644
index 0000000..924ad5f
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# building an all-in-one product
+
+*(common gotcha)*
+
+## what happened
+
+teams try to build a full platform with auth, dashboards, analytics, social features, notifications — in 24 hours. they end up with nothing working.
+
+## why it's a gotcha
+
+you're not here to build a billion-dollar startup in 48 hours. you're here to show your ability to identify a problem and solve it with a creative, functional prototype. scope kills more hackathon projects than bad code does. this is the feature-level version of [[optimizing-for-scale-too-early|optimizing for scale too early]] — same over-engineering energy, different axis.
+
+## the fix
+
+pick one core feature and make it work beautifully. everything else is a slide that says "future work." judges respect a focused, working prototype over an ambitious, broken one. watch out for the [[just-one-more-feature-loop|"just one more feature" loop]] that causes this scope explosion in the first place, and resist the [[over-planning-trap|urge to plan a platform]] when you should be building a prototype.
\ No newline at end of file
new file mode 100644
index 0000000..c8ba84f
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# building before validating the problem
+
+*(common gotcha)*
+
+## what happened
+
+you have an idea, you get excited, you start coding immediately. three weeks later you have a working product and zero evidence that anyone wants it. you show it to potential users and they say "oh, that's cool" (polite disinterest) or "i already use [existing thing] for that."
+
+## why it's a gotcha
+
+building is fun. talking to users is uncomfortable. so builders build first and validate later — which means they invest significant time before discovering nobody cares. the sunk cost makes it even harder to pivot or abandon. the [[just-one-more-feature-loop|"just one more feature" loop]] makes it worse — adding features to avoid facing the validation question.
+
+## the fix
+
+before writing code, have 5 conversations with potential users. not "would you use this?" (everyone says yes to be polite). instead: "how do you currently handle [problem]? what's frustrating about it? what have you tried?" if the problem is real, you'll hear it. if you can't find anyone who has the problem, you don't have a product — you have a hobby. and beware the opposite extreme: the [[over-planning-trap]] where you plan endlessly but never build or validate. don't [[optimizing-for-scale-too-early|build infrastructure]] for a problem nobody has.
\ No newline at end of file
new file mode 100644
index 0000000..efc56db
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# check what you submit
+
+## what happened
+
+submitted an unedited version of a final presentation video for calc. the wrong file. the one with mistakes still in it.
+
+## why it's a gotcha
+
+you have the right version and the wrong version on your computer. they have similar names. you're rushing. you grab the wrong one and hit submit. you don't realize until it's too late — or worse, until the grade comes back. this is the same carelessness that leads to [[naming-wrong-school-in-essay|naming the wrong school in your essay]] — different domain, same mistake.
+
+## the fix
+
+always preview/watch/re-read the exact file you're submitting before you hit send. open it. watch the first 30 seconds. read the first paragraph. confirm it's the right version. name your files clearly — "calc_video_FINAL.mp4" vs "calc_video_draft2.mp4." the 60 seconds of checking saves you from a mistake you literally can't undo. and make sure you've actually [[not-reading-submission-requirements|read the submission requirements]] too — check the requirements AND the file. this mistake happens most when you're [[submitting-right-at-the-deadline|rushing at the deadline]].
\ No newline at end of file
new file mode 100644
index 0000000..55fc655
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# college board student search service
+
+## what happened
+
+when you take the PSAT/SAT, College Board asks if you want to opt into their "Student Search Service." sounds helpful — colleges can find you! what actually happens: they sell your info to every college in the country, and you get flooded with misleading mailers that say things like "you've been selected!" or "exclusive invitation!"
+
+## why it's a gotcha
+
+those mailers look real. they feel like recognition. they're mass-marketed recruitment spam designed to boost application numbers (so the school can reject more people and look more selective). you might waste time and money applying to schools that were never a real fit, just because a fancy letter made you feel chosen. chasing these fake leads is especially dangerous if you're already [[starting-applications-too-late|starting applications late]].
+
+## the fix
+
+don't opt in. if you already did, know that those mailers mean nothing. a school sending you marketing material is not the same as a school wanting you specifically. ignore it all and do your own research on where to apply. this is just one of many college admin traps — along with [[missing-fafsa-deadlines|FAFSA deadlines]] and [[naming-wrong-school-in-essay|copy-paste essay mistakes]] — where not paying attention costs you.
\ No newline at end of file
new file mode 100644
index 0000000..da24529
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# comparison as motivation (until it isn't)
+
+*(common gotcha)*
+
+## what happened
+
+you use other people's success as fuel. it works for a while — seeing peers ship things makes you want to ship things. then one day it flips. you see someone your age raise a round or get into a top program, and instead of motivation, you feel despair. the same mechanism that drove you is now crushing you.
+
+## why it's a gotcha
+
+comparison-driven motivation is borrowed energy. it feels productive but it's fragile. it depends on your position relative to others, which you don't control. when someone leapfrogs you, the motivation doesn't just disappear — it inverts into anxiety or self-doubt. this is FOMO's more insidious sibling — the [[fomo-trap]] is about chasing opportunities; comparison-as-motivation is about the emotional machinery underneath.
+
+## the fix
+
+find intrinsic motivation: build because you're curious, because the problem is interesting, because you want to learn. extrinsic motivation (status, comparison, recognition) is fine as a supplement but terrible as a foundation. if your motivation disappears when you stop looking at what others are doing, it was never really yours. watch for [[over-indexing-on-opinions|over-indexing on respected people's opinions]] too — it's the same pattern of external signals replacing internal direction. and when comparison turns fully inward, that's [[ai-assisted-imposter-syndrome]].
\ No newline at end of file
new file mode 100644
index 0000000..b84d399
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# Discord bot -> account ban
+
+## what happened
+
+built discord-friender (automated friend requests) as part of discord-lattice (a Chrome extension that maps Discord friends into a network graph). the automation worked great — until Discord detected it and banned the account.
+
+## why it's a gotcha
+
+platform automation is seductive. you see an API (or a pattern you can automate), you build something cool, and it works. until the platform detects it and nukes your account. Discord, Instagram, LinkedIn — they all have detection systems for automated behavior, and the penalties are real. recovering a banned account is painful and not guaranteed. same energy as [[hardcoding-secrets-in-code|hardcoding secrets]] — moving fast without reading the rules.
+
+## the fix
+
+read the ToS, especially for platforms that actively detect automation. if the ToS says "no automated friend requests," they mean it, and they have systems to enforce it. if you want to build on a platform, use their official API within their rate limits. if the official API doesn't support what you want to do, that's a signal — not a challenge to work around. platform rules are admin rules, and [[stay-on-admins-good-side|staying on the admin's good side]] applies to digital platforms as much as school offices.
\ No newline at end of file
new file mode 100644
index 0000000..541265e
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# emphasize the live demo
+
+## what happened
+
+the presentation wasn't that great — should have emphasized live demo more. spent too much time on slides when judges wanted to see the thing actually work.
+
+## why it's a gotcha
+
+judges at hackathons care about working software. [[slides-as-documentation|packing slides with code snippets and architecture diagrams]] puts them to sleep. they want to see you click buttons and have things happen.
+
+## the fix
+
+structure your presentation as: 30 seconds of problem/context, then live demo for as long as you can. slides should support the demo, not replace it. of course, the demo has to [[test-demo-before-presenting|actually work first]], and you need a [[no-backup-plan-for-failed-demo|backup plan]] for when it doesn't. the demo itself needs a story — don't [[jumping-between-features-no-narrative|jump between features randomly]].
\ No newline at end of file
new file mode 100644
index 0000000..a80edbe
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# ESP32 30-hour debugging saga
+
+## what happened
+
+INMP441 I2S mic on ESP32. spent 30 hours debugging why audio data wasn't reaching the server. tried everything — rewiring, different libraries, different boards. the bug: `setFollowRedirects` was silently dropping the POST body on a Google redirect, returning 400. fixed ONE LINE after 30 hours.
+
+also: mug warmer circuit took 6 hours — dead transistor AND dead LED AND dead capacitor, all at once. three failed components masquerading as one bug.
+
+## why it's a gotcha
+
+when you're debugging hardware + software, the number of possible failure points is enormous. the real killer isn't the bug — it's the wrong assumption that keeps you looking in the wrong place. you assume it's the wiring, so you spend 10 hours on wiring. it's actually an HTTP library silently eating your data. [[ai-rot]] can make this worse — when you're deep in an AI loop, you keep prompting the same wrong assumption for hours instead of stepping back.
+
+## the fix
+
+lesson from an Orbit mentor: "if nothing is working, you have a wrong assumption. aggressively backtrack and sanity check." when you've been stuck for more than an hour, stop and list every assumption you're making. test each one independently. the bug is almost always hiding behind an assumption you haven't questioned — and that includes [[it-works-on-my-machine|environmental assumptions]]. also: when debugging hardware, test each component individually before assuming the circuit design is wrong.
\ No newline at end of file
new file mode 100644
index 0000000..07befde
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# figure out what you want before looking for partners
+
+## what happened
+
+lesson from finding partner in hackathon is that you gotta figure out what you want earlier and optimize for that. showed up looking for teammates without knowing what i actually wanted from the experience.
+
+## why it's a gotcha
+
+if you don't know whether you want to win, learn, network, or ship, you'll end up on a team optimized for a different goal. the person who wants to win will clash with the person who wants to learn. both are valid — but they don't mix well under time pressure. the downstream effect is [[teams-without-shared-understanding|a team without shared understanding]], and under pressure, the [[personality-mismatch-under-pressure|personality clashes]] get ugly fast.
+
+## the fix
+
+before the hackathon, ask yourself: am i here to win, learn something specific, meet people, or build something real? then find people aligned with that goal. [[unclear-roles|roles should follow from goals]] — and so should your choice of theme or track. make sure you [[match-the-theme-track|know what game you're playing]]. if you can't find aligned people, [[solo-vs-bad-team|going solo]] is better than joining the wrong team out of [[fomo-trap|FOMO]].
\ No newline at end of file
new file mode 100644
index 0000000..8478c97
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# FOMO trap
+
+## what happened
+
+i've always just been in the mindset of grab as many opportunities as possible. the anxiety when peers get opportunities you don't — internships, acceptances, features, followers.
+
+## why it's a gotcha
+
+FOMO is about position, not growth. you see someone get an internship and feel behind, but you don't actually know what they're learning or whether it's relevant to your path. the comparison is based on what it looks like, not what it is — which is why it pairs so tightly with [[comparison-as-motivation]]. and the anxiety it creates makes you chase opportunities that don't align with what you actually want, or [[over-indexing-on-opinions|over-index on what respected people say you should do]].
+
+## the fix
+
+when you feel FOMO, ask: am i jealous of what they're learning, or what it looks like? if it's the latter, it's not worth your attention. the most successful builders you'll meet have a strange ability to ignore what everyone else is doing and just keep building. that's not confidence — it's clarity about what matters to them. [[figure-out-what-you-want-before-partners|figuring out what you actually want]] is the antidote. FOMO can also trigger the [[over-planning-trap]] — anxious planning as a coping mechanism for the feeling of falling behind.
\ No newline at end of file
new file mode 100644
index 0000000..7d91889
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# frame impact explicitly
+
+## what happened
+
+Congressional App Challenge — didn't present well, impact wasn't framed clearly enough. "Pause could have been perfectly fine if i just say one extra thing that it does." the project was solid but the presentation undersold it.
+
+## why it's a gotcha
+
+judges won't infer impact. if you don't say "this helps X people do Y thing Z% faster," they won't figure it out themselves. you know how impactful your project is because you built it. they don't — they're seeing it for 5 minutes. the gap between what you know and what you communicate is where you lose — and this is the core of why [[pitching-matters-as-much-as-product|pitching matters as much as the product]].
+
+## the fix
+
+frame the impact explicitly. state it in plain language. "this app saves teachers 3 hours per week on grading" is better than a vague demo that shows grading features. write down 2-3 impact statements before your presentation. your [[memorize-one-liner|one-liner]] should include impact, and you should [[practice-presentation-once|practice saying it out loud]]. if a single extra sentence could have made the difference, that sentence should be in your opening, not left to chance. make sure you're [[match-the-theme-track|framing impact in terms of what judges care about]].
\ No newline at end of file
new file mode 100644
index 0000000..b413d77
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# get contacts immediately
+
+## what happened
+
+make sure to get the contacts of people who vibe with you quickly. saying "i'll get it later, don't have my phone" will not work — they leave, and they think it's a delaying tactic.
+
+## why it's a gotcha
+
+you meet someone great, have a real conversation, and then... nothing. you figure you'll find them later. you won't. events are chaotic, people leave early, and "later" never comes. worse, if you dodge the exchange, they assume you're not interested.
+
+## the fix
+
+get LinkedIn/number/email RIGHT THEN. pull out your phone immediately. if they're the one hesitating, offer yours first — lower the friction. the 10 seconds of awkwardness is worth the connection. and it's not just the contact — [[record-conversations|capture the conversation content]] too, so you can write a specific [[not-following-up-within-48-hours|follow-up within 48 hours]]. a good [[how-you-introduce-yourself|intro]] is what opens the door to the exchange, and if you [[showing-up-with-no-plan|planned who to meet]] beforehand, you'll prioritize getting the contact.
\ No newline at end of file
new file mode 100644
index 0000000..b66a260
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# hardcoding secrets in code
+
+*(common gotcha)*
+
+## what happened
+
+you push API keys, passwords, or tokens to a public GitHub repo. bots scrape GitHub for exposed secrets. within minutes, your AWS bill is $5,000, your API key is being used for crypto mining, or your database is wiped.
+
+## why it's a gotcha
+
+it happens to everyone at least once. you're moving fast, you hardcode a key "just for testing," you forget to remove it, you push. even if you delete the commit, the secret is in the git history and can still be found. bots are scanning GitHub continuously — this is not a theoretical risk. bad git habits from [[not-using-version-control|not using version control properly]] compound this.
+
+## the fix
+
+use environment variables or a `.env` file (and add `.env` to `.gitignore`). use a secrets manager for anything production. if you accidentally push a secret, revoke and rotate it immediately — don't just delete the commit. tools like `git-secrets` or GitHub's built-in secret scanning can catch this before it happens. and always [[check-what-you-submit|verify what you're pushing]] before you push it.
\ No newline at end of file
new file mode 100644
index 0000000..efea63f
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# how you introduce yourself
+
+## what happened
+
+if saying "I'm in high school" would cause people to pattern-match you into "typical HS kid" and that doesn't represent you accurately, you can just lead with what you do. "I'm a builder working on X" is more accurate than a label that triggers wrong assumptions.
+
+## why it's a gotcha
+
+labels are shortcuts for other people's brains. when you say "i'm a high school student," most adults at tech events immediately lower their expectations and shift into mentor mode. if that's not the dynamic you want, the label is working against you — not because it's false, but because it's misleading.
+
+## the fix
+
+not about hiding anything — it's about not misleading. lead with what you do, not what category you fit into. "i'm building an AI tool for X" starts a different conversation than "i'm in high school and interested in AI." same person, different frame. same concept applies to your product: [[memorize-one-liner|memorize a one-liner]]. the intro opens the door to [[get-contacts-immediately|getting the contact]], and framing yourself as a contributor rather than an asker is the antidote to [[networking-as-extraction]].
\ No newline at end of file
new file mode 100644
index 0000000..109fe1b
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# "it works on my machine"
+
+*(common gotcha)*
+
+## what happened
+
+your project runs perfectly on your laptop. you demo it on someone else's machine (or the judges' machine) and it crashes immediately. different OS, different Python version, missing dependency, hardcoded file path.
+
+## why it's a gotcha
+
+local development hides environmental dependencies. you installed that library 6 months ago and forgot. your code uses a Mac-specific path. your Python version has a feature that older versions don't. you don't notice any of this until you're on stage.
+
+## the fix
+
+test on a clean environment before demo day. docker is ideal but even just testing on a friend's laptop helps. document your setup steps. if your demo depends on your specific machine, you're one coffee spill away from disaster. this is why you [[test-demo-before-presenting|test on the actual demo machine]], not just your own. make sure to [[restart-server-before-demo|restart services]] so you're not running stale code, and have a [[no-backup-plan-for-failed-demo|backup plan]] for when the environment still surprises you. reproducible environments start with [[not-using-version-control|proper version control]].
\ No newline at end of file
new file mode 100644
index 0000000..b39b115
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# jumping between features with no narrative
+
+*(common gotcha)*
+
+## what happened
+
+teams demo by clicking around randomly — "and this does X, and over here is Y, and also we built Z." no story, no flow, no connection to the problem.
+
+## why it's a gotcha
+
+without a narrative, features feel disconnected and forgettable. judges can't follow why each feature matters. it feels like a feature tour, not a solution to a problem. this is what happens when you [[emphasize-live-demo|emphasize the demo]] but forget that the demo needs a story.
+
+## the fix
+
+demo as a user story. "imagine you're [persona] and you need to [goal]. you open the app, you do this, then this happens, and now your problem is solved." every feature click should advance that story. the narrative starts with your [[memorize-one-liner|one-liner]], and the story is what makes [[pitching-matters-as-much-as-product|the pitch actually work]].
\ No newline at end of file
new file mode 100644
index 0000000..3c8f0a9
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# the "just one more feature" loop
+
+*(common gotcha)*
+
+## what happened
+
+the product is 90% done but you keep adding features instead of launching. "we just need notifications." "we just need dark mode." "we just need better onboarding." weeks pass. still not launched.
+
+## why it's a gotcha
+
+this is perfectionism disguised as product sense. each "just one more feature" feels reasonable in isolation, but they compound into an infinite loop. the real reason you're not launching is fear — fear that it's not good enough, fear of negative feedback, fear of finding out nobody cares. features are a way to delay facing that. this is the execution-level version of the [[over-planning-trap]] — same avoidance, different flavor.
+
+## the fix
+
+set a launch date and stick to it. not a "we'll launch when it's ready" date — an actual calendar date. cut any feature that isn't done by then. launch with less than you're comfortable with. the feedback from real users is worth more than any feature you could add in isolation. and if the problem isn't even [[building-before-validating|validated yet]], features don't matter at all. at hackathon scale, this becomes [[building-all-in-one-product|building an all-in-one product]] — the same trap compressed into 24 hours.
\ No newline at end of file
new file mode 100644
index 0000000..f580c44
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# match the theme/track
+
+## what happened
+
+built something that was neither "agents" nor "multimodal" for a multimodal agents hackathon. the project was good, but it didn't fit what the judges were looking for.
+
+## why it's a gotcha
+
+hackathon judges have rubrics. if the rubric says "use of [sponsor API]" or "alignment with [theme]," those are real scoring categories. building something irrelevant to the track is like answering the wrong question on a test — doesn't matter how good your answer is.
+
+## the fix
+
+read the judging criteria before you start building. seriously, read them. then build something that explicitly hits each criterion. you can still build what you're passionate about — just frame it within the track. this is the same mistake as [[not-reading-submission-requirements|not reading submission requirements]] — not reading the rules before playing the game. [[frame-impact-explicitly|frame your impact]] in terms of what judges care about, and make sure you [[figure-out-what-you-want-before-partners|know what you're optimizing for]] before you start.
\ No newline at end of file
new file mode 100644
index 0000000..2dd73b0
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# memorize a one-liner for your product
+
+## what happened
+
+still the description isn't very clear — should have memorized the one liner. kept explaining the project differently every time someone asked, each version more confusing than the last.
+
+## why it's a gotcha
+
+you will be asked "what does it do?" dozens of times — by judges, mentors, other teams, sponsors. if you fumble it every time, people assume the project itself is unclear, not just your explanation.
+
+## the fix
+
+write one sentence that explains what your project does. memorize it. use it every time. format: "[product] is a [thing] that [does what] for [who]." practice saying it out loud until it sounds natural, not rehearsed. same concept applies to [[how-you-introduce-yourself|introducing yourself]]. the one-liner is the foundation of your [[pitching-matters-as-much-as-product|pitch]], and it should [[frame-impact-explicitly|communicate impact]], not just features. [[practice-presentation-once|practicing]] includes practicing the one-liner until it's automatic.
\ No newline at end of file
new file mode 100644
index 0000000..635460e
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# missing FAFSA and financial aid deadlines
+
+*(common gotcha)*
+
+## what happened
+
+students focus entirely on admission deadlines and forget that financial aid has its own separate deadlines — often earlier. by the time they realize, the money is gone.
+
+## why it's a gotcha
+
+you can get accepted and still not be able to afford it. financial aid is first-come-first-served at many schools. missing the FAFSA deadline by even a week can cost thousands. this is part of the same procrastination pattern as [[starting-applications-too-late|starting applications late]] — you don't think about it until it's urgent, and by then it's too late.
+
+## the fix
+
+treat the FAFSA deadline as your real first deadline. submit it as early as it opens (October 1st). don't wait for your parents to "get around to it." and make sure you [[not-reading-submission-requirements|actually read the requirements]] — there are deadlines you don't even know about until you look. this is another one of those [[college-board-student-search|college admin traps]] that catches you off guard.
\ No newline at end of file
new file mode 100644
index 0000000..4ccd230
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# naming the wrong school in your essay
+
+*(common gotcha)*
+
+## what happened
+
+students copy-paste their "Why Us?" essay for multiple schools and forget to change the school name. admissions officers see "I've always dreamed of attending Dartmouth" in a UPenn application.
+
+## why it's a gotcha
+
+it's an instant reject signal. it tells the reader you're mass-producing applications without genuine interest. and it happens way more often than you'd think because everyone's rushing near deadlines — the direct consequence of [[starting-applications-too-late|starting too late]].
+
+## the fix
+
+ctrl+F the school name in every essay before submitting. better yet, have someone else read it. fresh eyes catch what yours skip. same rule as [[check-what-you-submit|checking what you submit]] — verify before you send.
\ No newline at end of file
new file mode 100644
index 0000000..768fbae
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# networking as extraction
+
+*(common gotcha)*
+
+## what happened
+
+approaching every conversation thinking "what can this person do for me?" people can feel it, and they disengage.
+
+## why it's a gotcha
+
+transactional networking is obvious and repulsive. if every conversation you have is angled toward getting something — a referral, an intro, a job — people will avoid you. the irony is that generous networkers get more opportunities than extractive ones. this is the same "don't be transactional" lesson that applies to [[stay-on-admins-good-side|dealing with admin]] — and even to [[over-indexing-on-opinions|extracting advice]] from mentors.
+
+## the fix
+
+lead with curiosity, not credentials. ask what they're working on. offer something useful — a relevant article, a connection to someone they should meet, genuine feedback on their project. the best networking doesn't feel like networking. [[how-you-introduce-yourself|lead with what you do]], not what you want, and when you [[not-following-up-within-48-hours|follow up]], lead with value, not asks.
\ No newline at end of file
new file mode 100644
index 0000000..ee5f7d7
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# no backup plan for a failed demo
+
+*(common gotcha)*
+
+## what happened
+
+live demo crashes on stage. team freezes. awkward silence. judges move on.
+
+## why it's a gotcha
+
+live demos fail. wifi goes down, APIs time out, databases crash. if your entire presentation depends on everything working perfectly, you're gambling. and [[it-works-on-my-machine|environmental differences]] between your laptop and the demo setup make failure more likely than you think.
+
+## the fix
+
+record a screen capture of the full demo working beforehand. if the live demo crashes, switch to the video immediately — don't waste time debugging on stage. say "let me show you the recording" and keep moving. of course, the best approach is to [[test-demo-before-presenting|reduce the chance of failure in the first place]] — including [[restart-server-before-demo|restarting services]] right before presenting.
\ No newline at end of file
new file mode 100644
index 0000000..72184ba
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# not following up within 48 hours
+
+*(common gotcha)*
+
+## what happened
+
+met great people at the event, exchanged info, then never reached out. by the time you remember, it's been two weeks and the connection is cold.
+
+## why it's a gotcha
+
+the window for a warm follow-up is about 48 hours. after that, you're just another name in their contacts with no context. the energy from the event fades fast, and so does their memory of you.
+
+## the fix
+
+send a short message within 24-48 hours. reference something specific from your conversation. "hey, great meeting you at [event] — loved your point about [specific thing]." that's it. short, specific, timely. don't pitch them on anything in the first message — that's [[networking-as-extraction]]. you can't follow up without the contact, which is why you [[get-contacts-immediately|get it on the spot]]. and if you [[record-conversations|recorded the conversation]], you can reference specifics that make the follow-up feel personal.
\ No newline at end of file
new file mode 100644
index 0000000..b9d55fd
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# not reading submission requirements
+
+*(common gotcha)*
+
+## what happened
+
+you build a great project, then discover the submission requires a 2-minute video, a written description under 500 words, and screenshots in a specific format. it's 30 minutes before the deadline. you rush through all of it and submit garbage supplementary materials alongside a great project.
+
+## why it's a gotcha
+
+submission requirements are often posted weeks before the deadline but nobody reads them until the end. the video, the writeup, the screenshots — these are what judges actually see first. your code might be excellent, but if your submission materials are rushed, judges form a bad first impression before they ever look at the project. discovering them last-minute while [[submitting-right-at-the-deadline|submitting at the deadline]] is the worst combination.
+
+## the fix
+
+read the full submission requirements on day one. put the non-code deliverables on your task list alongside the coding work. allocate time for the video and writeup — they're not afterthoughts, they're the packaging. same lesson as [[match-the-theme-track|matching the theme]]: read the rules before you build. and [[check-what-you-submit|verify your submission]] matches what was asked for. the writeup is also where you [[frame-impact-explicitly|frame your impact]].
\ No newline at end of file
new file mode 100644
index 0000000..8f0bcc9
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# not using version control (or using it wrong)
+
+*(common gotcha)*
+
+## what happened
+
+you make a change that breaks everything. you can't undo it because you don't have version control, or you've been committing everything to main with messages like "fix" and "update" and "asdf." you can't find the last working version.
+
+## why it's a gotcha
+
+without version control, every change is permanent and irreversible. with bad version control, every change is technically reversible but practically impossible to find. both leave you stranded when something breaks, which it will.
+
+## the fix
+
+use git from the start of every project. commit often with descriptive messages. use branches for features. this isn't about best practices — it's about having a time machine for your code. the 30 seconds per commit saves you hours of "wait, what did i change?" be careful though: git history remembers everything, including [[hardcoding-secrets-in-code|secrets you accidentally committed]]. version control also lets you bisect bugs — something that would have saved hours during the [[esp32-debugging-saga]].
\ No newline at end of file
new file mode 100644
index 0000000..512041b
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# optimizing for scale before you have users
+
+*(common gotcha)*
+
+## what happened
+
+teams spend hours setting up kubernetes, microservices, CI/CD pipelines, and database sharding for a hackathon project that will have exactly 3 users: the judges.
+
+## why it's a gotcha
+
+over-engineering is a way to feel productive without making progress on what matters. nobody at a hackathon cares about your infrastructure. they care about whether it works and whether it solves the problem. at the feature level, this looks like [[building-all-in-one-product|building an all-in-one product]]; at the planning level, it looks like the [[over-planning-trap]].
+
+## the fix
+
+use the simplest possible stack. sqlite, a single server, hardcoded config. get the demo working first. you can architect properly later if the project survives past the weekend. don't build infrastructure for a problem you haven't even [[building-before-validating|validated]] yet.
\ No newline at end of file
new file mode 100644
index 0000000..82b314c
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# over-indexing on respected people's opinions
+
+## what happened
+
+when mentors or people you admire give feedback, it's easy to take it as gospel. someone with 20 years of experience says "you should do X" and you reorganize your whole plan around it.
+
+## why it's a gotcha
+
+their context is different from yours. a VC's advice is optimized for VC-scale outcomes. a professor's advice is shaped by academic incentives. a mentor's suggestion is filtered through their own experience, which may not map to your situation. they're not wrong — their advice is just for a different game than the one you're playing. this is the advice version of the [[fomo-trap]] — external signals overriding internal clarity.
+
+## the fix
+
+weigh advice, don't swallow it whole. when someone you respect gives feedback, ask yourself: what's their context? what game are they playing? does this advice apply to my specific situation, or to a situation that looks like mine from the outside? take what's useful, leave the rest. [[figure-out-what-you-want-before-partners|knowing your own goals]] is the anchor. extracting advice is still [[networking-as-extraction|extraction]], and borrowed direction leads to the same place as [[comparison-as-motivation|borrowed motivation]].
\ No newline at end of file
new file mode 100644
index 0000000..50b5e59
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# the over-planning trap
+
+## what happened
+
+full PRD, competitive analysis, design spec, technical doc, launch plan, pitch video... never shipped. four name changes. the project went through Nosce -> OnCue -> Axon -> Tellwell, each rename accompanied by another round of planning documents. all the planning in the world, zero users.
+
+## why it's a gotcha
+
+planning feels like progress. writing a PRD feels productive. doing competitive analysis feels like due diligence. but it's all pre-work for the real work, and the real work never starts because there's always one more thing to plan. each rename is a reset that restarts the planning cycle. you end up with a beautiful Google Drive folder and no product.
+
+## the fix
+
+ship something small first, then plan. build the core feature in a weekend. put it in front of one person. get a reaction. then decide if it's worth planning around. the plan should follow the prototype, not precede it. if you've renamed your project more than once before launching, that's a red flag. this is the planning-stage version of [[perfectionism-over-hackathon-fit|perfectionism]] and the mirror of [[building-before-validating|building before validating]] — planning without validation is just daydreaming. at execution level, it becomes the [[just-one-more-feature-loop]], and at team level, it becomes the [[relay-build-fallacy|relay-build fallacy]] — over-coordinating instead of building. don't [[optimizing-for-scale-too-early|build infrastructure]] before building product.
\ No newline at end of file
new file mode 100644
index 0000000..743f171
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# perfectionism over hackathon fit
+
+## what happened
+
+spent 1-2 extra hours polishing when a rougher version would have been fine. was more intent on perfection than i should have been. those hours could have gone toward the pitch or the demo.
+
+## why it's a gotcha
+
+in a hackathon, time is the only resource that matters. polishing a feature that already works is a luxury you can't afford when you haven't practiced your presentation or tested the full flow. shipped and rough beats polished and unfinished every time.
+
+## the fix
+
+set a "code freeze" time — usually 1-2 hours before presentations. after that, you're only fixing critical bugs and prepping the demo. no new features, no refactoring, no "just one more thing." the time you save is better spent on [[practice-presentation-once|practicing the presentation]] — because [[pitching-matters-as-much-as-product|the pitch matters as much as the product]]. make sure you're [[match-the-theme-track|polishing the right thing]], and watch out for the [[just-one-more-feature-loop|"just one more feature" loop]] — perfectionism's cousin at the feature level.
\ No newline at end of file
new file mode 100644
index 0000000..c9f3023
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# personality mismatch under pressure
+
+*(common gotcha)*
+
+## what happened
+
+teamed up with someone who seemed fine in casual conversation, but under sleep deprivation and deadline pressure, they became impossible to work with — argumentative, dismissive, or checked out entirely.
+
+## why it's a gotcha
+
+hackathons are stress tests for group dynamics. people behave differently when they're tired, frustrated, and running out of time. someone who's great at a meetup might be terrible at 4am when the API is down. misalignment on [[teams-without-shared-understanding|goals and expectations]] amplifies everything under pressure.
+
+## the fix
+
+if you can, team with people you've worked with under pressure before. if you're teaming with strangers, pay attention to how they handle the first setback. that's who they'll be for the rest of the event. and if the clash is bad enough, remember: [[solo-vs-bad-team|solo is better than a bad team]]. [[figure-out-what-you-want-before-partners|vetting for compatibility]], not just skills, prevents this.
\ No newline at end of file
new file mode 100644
index 0000000..90e3040
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# phone on vibrate
+
+## what happened
+
+phone rang during a birthday party. embarrassing and avoidable. a sharp ringtone cutting through a quiet moment makes everyone look at you.
+
+## why it's a gotcha
+
+you think you'll remember to silence your phone. you won't. and a loud ringtone at the wrong moment (during a presentation, a quiet conversation, a ceremony) is a small thing that leaves a bad impression. impressions are made of small details like this — the same reason [[how-you-introduce-yourself|how you introduce yourself]] matters.
+
+## the fix
+
+choose a ringtone that's quieter and less sharp, or just keep it on vibrate at events. better yet, make vibrate your default. you almost never need a loud ringtone.
\ No newline at end of file
new file mode 100644
index 0000000..8eefba6
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# pitching matters as much as product
+
+## what happened
+
+you can have shit product but pitch much above average and still win. watched teams with worse projects win because they presented better.
+
+## why it's a gotcha
+
+builders tend to think the work speaks for itself. it doesn't. judges have limited time and attention. a great pitch makes a mediocre project look good; a bad pitch makes a great project look forgettable.
+
+## the fix
+
+allocate real time to the pitch — not just the last 20 minutes. assign your best communicator to lead the presentation — if your team is [[all-coders-no-communicator|all coders with no communicator]], you have a problem. practice the narrative: problem -> solution -> demo -> impact. [[frame-impact-explicitly|frame impact explicitly]], [[memorize-one-liner|memorize your one-liner]], and [[emphasize-live-demo|make the demo the core of the pitch]]. even [[practice-presentation-once|one dry run]] makes a massive difference.
\ No newline at end of file
new file mode 100644
index 0000000..c79ab9e
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# practice the presentation once
+
+## what happened
+
+went in cold. stumbled over transitions, didn't know who was saying what, ran over time.
+
+## why it's a gotcha
+
+even one dry run makes a huge difference. most hackathon teams never practice and it shows — they trip over each other, forget to mention key features, and blow past the time limit. judges notice.
+
+## the fix
+
+do one full run-through. time it. figure out who says what. you don't need to rehearse 10 times — once is the difference between amateur and competent. [[test-demo-before-presenting|testing the demo]] is part of practicing — make sure the thing works before you practice presenting it. know your [[memorize-one-liner|opening line]] cold. the reason this matters: [[pitching-matters-as-much-as-product|pitching matters as much as the product]], and a team that's [[all-coders-no-communicator|all coders]] can still present well if they run through it once.
\ No newline at end of file
new file mode 100644
index 0000000..5e18606
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# record conversations
+
+## what happened
+
+again did not have the always-on recording — was gonna use Granola but didn't. didn't even have voice memo for a lot of it. met interesting people, had great conversations, forgot half of what was said by the next day.
+
+## why it's a gotcha
+
+your memory is worse than you think, especially at events where you're meeting 10-20 people in a few hours. names, ideas, advice, introductions — it all blurs together. without a record, the event's value decays within days.
+
+## the fix
+
+use voice recording at events for self-reflection and remembering who you met. even just opening Voice Memos on your phone during conversations (with consent where needed) gives you something to review later. take quick notes between conversations — even just a name and one thing they said. pair this with [[get-contacts-immediately|getting the contact on the spot]], and the recording will help you write a much better [[not-following-up-within-48-hours|follow-up]] that references specifics.
\ No newline at end of file
new file mode 100644
index 0000000..d8bd0ef
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# the relay-build fallacy
+
+## what happened
+
+got 16 friends to relay-build a project — one person works on it, passes it to the next. fell apart.
+
+## why it's a gotcha
+
+you can't assume buy-in. getting 16 people to agree to participate is not the same as getting 16 people to do the work. each handoff loses context, motivation, and quality. person 8 doesn't understand what person 3 built. person 12 doesn't care anymore because their part feels disconnected from the whole. coordination overhead kills the project long before the last person touches it. this is [[teams-without-shared-understanding|shared understanding]] breaking down at maximum scale.
+
+## the fix
+
+small committed team > large uncommitted one. 2-3 people who actually care will outship 16 people who said "sure, sounds cool." if you need many contributors, structure the project so each contribution is independently valuable (open source model), not sequentially dependent (relay model). [[solo-vs-bad-team|small and focused]] beats large and scattered. 16 people with [[unclear-roles]] is just chaos, and it's often the product of the [[over-planning-trap|over-planning trap]] — mistaking coordination for progress.
\ No newline at end of file
new file mode 100644
index 0000000..4884eaf
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# restart the server before demo
+
+## what happened
+
+was tweaking out and then realized i didn't restart the server. the demo was running stale code with old bugs.
+
+## why it's a gotcha
+
+you've been coding for 20 hours straight. you made fixes. you forgot to restart. now the demo shows the old broken version and you're standing there confused about why your fix isn't working. stale environments cause the same confusion as [[it-works-on-my-machine|"it works on my machine"]] bugs.
+
+## the fix
+
+add "restart all services" to a pre-demo checklist. do it 5 minutes before you present, not 30 seconds before. give yourself time to catch anything that doesn't come back up cleanly. this is part of the full [[test-demo-before-presenting|pre-demo verification flow]], and don't [[perfectionism-over-hackathon-fit|tweak the code right up to the deadline]] — that's how you end up needing a restart you don't have time for.
\ No newline at end of file
new file mode 100644
index 0000000..319ed92
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# showing up with no plan
+
+*(common gotcha)*
+
+## what happened
+
+you arrive at a conference or networking event, wander around, talk to whoever happens to be near you, and leave without making any meaningful connections.
+
+## why it's a gotcha
+
+events have dozens or hundreds of people, and your time is limited. without a plan, you'll default to talking to people who are easy to approach (other nervous newcomers) instead of the people who could actually help your work or career.
+
+## the fix
+
+before the event, look at the speaker list, attendee list, or sponsor list. identify 3-5 people you specifically want to meet. research their work so you can start a real conversation, not just "so what do you do?" set a micro-goal: 3 quality conversations beats 20 business card swaps. once you meet your targets, [[get-contacts-immediately|lock in the contact on the spot]]. plan [[how-you-introduce-yourself|your intro]] too. having a plan doesn't mean having an agenda — it's the opposite of [[networking-as-extraction]]. same [[figure-out-what-you-want-before-partners|"know what you want"]] energy, applied to events.
\ No newline at end of file
new file mode 100644
index 0000000..85ede5e
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# slides as documentation
+
+*(common gotcha)*
+
+## what happened
+
+teams pack slides with code snippets, architecture diagrams, and dense text to prove technical competence. judges glaze over.
+
+## why it's a gotcha
+
+your slides aren't documentation. nobody is going to read 8pt code on a projected screen. when visuals become dense, the main idea gets lost. judges check out and you lose them before the demo even starts.
+
+## the fix
+
+each slide should have one idea and minimal text. if you can't explain the slide in one sentence, it has too much on it. code goes in the demo, not the deck. [[emphasize-live-demo|emphasize the live demo]] instead — that's where technical work shines. slides should serve the [[pitching-matters-as-much-as-product|pitch]], and without a narrative thread you're just [[jumping-between-features-no-narrative|jumping between features]].
\ No newline at end of file
new file mode 100644
index 0000000..1f3de4d
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# solo > bad team
+
+## what happened
+
+solo tbh very strong. benefits: no comms issues, no dependency issues, no presentation disagreements, when you win you actually feel it.
+
+## why it's a gotcha
+
+there's pressure to team up at hackathons. "you need a team to win" is conventional wisdom. but a bad team is actively worse than solo — you spend more time coordinating than building, you make compromises that make the project worse, and if things go wrong, it feels worse because you gave up control.
+
+## the fix
+
+if you don't find a team you're genuinely excited about, go solo. a focused solo builder who ships a working demo beats a dysfunctional team every time. the best teams are small and aligned; the worst teams are big and confused. what makes a team bad? [[teams-without-shared-understanding|no shared understanding]], [[unclear-roles|role confusion]], [[personality-mismatch-under-pressure|personality clashes under pressure]], being [[all-coders-no-communicator|all coders with no communicator]]. the solution is to [[figure-out-what-you-want-before-partners|find the right team]] or go alone.
\ No newline at end of file
new file mode 100644
index 0000000..fa85372
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# starting applications too late
+
+*(common gotcha)*
+
+## what happened
+
+students think they have plenty of time, then realize in November that they have 12 supplemental essays due in 3 weeks. the essays come out rushed, generic, and full of errors.
+
+## why it's a gotcha
+
+college apps are a volume problem. the main essay is one thing, but supplements for 10+ schools can easily be 20-30 short essays. that's a lot of writing, and quality drops fast under time pressure. rushing is what leads directly to [[naming-wrong-school-in-essay|naming the wrong school in your essay]].
+
+## the fix
+
+start writing supplements the summer before senior year. most prompts are recycled from previous years, so you can draft early even before the official prompts drop. don't forget that [[missing-fafsa-deadlines|financial aid deadlines]] are often even earlier than admission deadlines. ironically, some students spend all their time in the [[over-planning-trap|over-planning trap]] on other projects while neglecting apps. and starting late is what puts you in the position of [[submitting-right-at-the-deadline|submitting right at the deadline]].
\ No newline at end of file
new file mode 100644
index 0000000..7d0eb96
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# stay on admin's good side
+
+## what happened
+
+when you're a builder, you're going to need things from bureaucracies — extensions, exceptions, access, signatures, approvals. schools, colleges, program administrators, government offices. the mistake is treating these interactions transactionally: only being nice when you need something, then disappearing.
+
+## why it's a gotcha
+
+admin and bureaucracy run on relationships, not rules. the rules are always bendable for people they like. if you only show up when you need something, you have no goodwill banked. it's the same lesson as [[networking-as-extraction|networking as extraction]] — people can feel the transaction.
+
+## the fix
+
+be as cooperative, pleasant, and kiss-up as possible in ALL your routine interactions with admin — not just when you're asking for a favor. answer their emails promptly. show up to mandatory things without complaining. say thank you. be the easy student. then when you actually need something, they remember the students who made their life easy. this applies to: school admin, college counselors, program coordinators, competition organizers, government offices, anyone who controls access to something you want. it also applies to digital platforms — the [[discord-bot-ban|Discord bot ban]] is what happens when you ignore platform admin rules.
\ No newline at end of file
new file mode 100644
index 0000000..12844bc
@@ -0,0 +1,19 @@
+---
+visibility: public-edit
+---
+
+# submitting right at the deadline
+
+*(common gotcha)*
+
+## what happened
+
+you wait until 11:58pm for an 11:59pm deadline. the upload stalls. the wifi drops. the submission portal crashes because 500 other people are also submitting at 11:58pm. you miss it.
+
+## why it's a gotcha
+
+deadlines are cliffs, not slopes. one second late is the same as one week late. and submission infrastructure is least reliable when it's most loaded — right before the deadline. you're betting your entire submission on everything working perfectly at the worst possible moment.
+
+## the fix
+
+submit a draft version early — even if it's incomplete. most platforms let you update your submission until the deadline. get something in 24 hours early, then update it as you improve it. your "insurance" submission doesn't have to be good; it just has to exist. and when you're rushing at the deadline, that's when you [[check-what-you-submit|submit the wrong file]]. this is the endgame of [[starting-applications-too-late|starting too late]], which is also how you end up [[not-reading-submission-requirements|discovering requirements last-minute]].
\ No newline at end of file
new file mode 100644
index 0000000..17377e7
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# teams without shared understanding
+
+## what happened
+
+having people on the team that don't know what's going on isn't a good feeling. don't trust each other, create issues, need to redo things. one person builds feature A while another person is also building feature A differently. nobody knows the plan because there was no plan.
+
+## why it's a gotcha
+
+you assume everyone's on the same page because you had a 5-minute conversation at the start. they're not. different mental models of the project lead to incompatible code, duplicated work, and arguments at 3am when you realize nothing fits together.
+
+## the fix
+
+before anyone writes a line of code, spend 15-30 minutes aligning on: what are we building, what's the MVP, who owns what, what's the tech stack. write it down — even a shared note works. revisit it when things change. [[unclear-roles|role clarity]] is the most concrete part of shared understanding, and alignment starts before the team forms — [[figure-out-what-you-want-before-partners|figure out what you want first]]. when misalignment is bad enough, [[solo-vs-bad-team|solo is better]]. and shared understanding breaks down even harder across handoffs, which is why the [[relay-build-fallacy]] fails so spectacularly.
\ No newline at end of file
new file mode 100644
index 0000000..11be5c5
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# test the full demo before presenting
+
+## what happened
+
+MAKE SURE THE THING WORKS BEFORE GOING INTO THE PRESENTATION. tested individual pieces, assumed they'd work together. they didn't.
+
+## why it's a gotcha
+
+integration bugs only show up when you run the full flow. you'll discover that step 3 breaks step 5 right in front of the judges. individual components working does not mean the system works. [[ai-rot|AI-generated code]] you didn't test is a common cause — and [[it-works-on-my-machine|environmental differences]] between your machine and the demo machine make it worse.
+
+## the fix
+
+run the complete user flow at least twice before presenting. start from a clean state each time — [[restart-server-before-demo|restart services]] to make sure you're not running stale code. if something breaks, you want to find it now, not on stage. and have a [[no-backup-plan-for-failed-demo|backup plan]] for when it breaks anyway. testing the demo is one thing; [[practice-presentation-once|testing the presentation itself]] is another.
\ No newline at end of file
new file mode 100644
index 0000000..3da3128
@@ -0,0 +1,17 @@
+---
+visibility: public-edit
+---
+
+# unclear roles
+
+## what happened
+
+discovered "are we all technical here?" as a simple first question that creates immediate clarity. without it, you end up with three people all trying to code the backend and nobody working on the frontend or the pitch.
+
+## why it's a gotcha
+
+in a group of strangers, nobody wants to be the one to say "so what do you actually do?" but without that conversation, work gets duplicated, gaps go unfilled, and the team runs inefficiently for the entire event. roles are part of [[teams-without-shared-understanding|shared understanding]], and the most common gap is [[all-coders-no-communicator|having no communicator on the team]].
+
+## the fix
+
+ask it directly in the first 5 minutes. "are we all technical?" "who's strongest at frontend?" "who wants to own the presentation?" assign lanes early. it feels awkward for 30 seconds and saves hours of confusion. [[figure-out-what-you-want-before-partners|know your own role first]], and when role confusion makes the team actively worse than working alone, remember that [[solo-vs-bad-team|solo is a valid option]].
\ No newline at end of file