# Prepare for SheBuilds — Before the Hackathon > [!question] Lingering Questions > - Is Apify's scraping of Discord/LinkedIn actually within ToS for hackathon-scale audience research, or does that need a documented exception? > [!tip] Article Ideas > - Template the "Women Who Build" Prague dinner model as a repeatable chapter playbook for other SheBuilds alumni cities. > - A Canva brand-kit template pre-populated with three-color + one-font slots, for hackathon onboarding. > [!link] Cross Reference > - [[3. Resources/Literature Notes/How to Use 48 Hours Before the Hackathon]] — same SheBuilds Season 3 prep series, complementary framework (Hong Darwin's 8-step judgment-first approach) > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] > [!quote] Vocabulary > - **Brevo** — free transactional-email service (formerly Sendinblue) that Lovable natively suggests for onboarding-email integration ## Author's thesis Hackathon product quality is set mostly by what happens before the clock starts: branding, audience research, a market-analysis dashboard, animation planning, and locked-in auth/integration decisions all belong in the preparation window, because spending sprint hours on them instead is the main way teams lose. ## Key arguments (≤3) 1. **Brand and integration decisions cost disproportionately more mid-sprint.** Twenty minutes lost live-improvising a gradient, or an unresolved auth flow discovered at 2 a.m., are recoverable costs that pre-commitment eliminates. 2. **Audience research should precede solution-building, not follow it.** Deafany's own product hit an unrecoverable wall (parental consent for a kids' product) that three real conversations could have surfaced earlier. 3. **Security intent belongs in the first prompt, not a cleanup pass.** Writing constraints like "other visitors shouldn't see this user's data" directly into the PRD prompt is cheaper than patching after the no-code platform flags an issue. ## Claim atoms ### Pre-sprint brand decisions prevent wasted hackathon hours > [!quote] ID:rw_shebuilds_001 > "I was working on the gradient for like literally 20 minutes to get it right. These things could have already been done definitely." Where/why: ~00:05:30, branding section. A specific, recoverable cost of not pre-committing brand assets — applies to any time-boxed build context, not just hackathons. ### Audience definition before solution prevents unrecoverable product pivots > [!quote] ID:rw_shebuilds_002 > "My product was for kids — teaching AI to kids — and later on I noticed how hard it is to sell something to kids or even get them to give consent." Where/why: ~00:09:00, audience-research section. A concrete failure case where audience-specific friction (parental consent) only became visible after the build — generalizes to any regulated or intermediated user group. ### Lovable can generate a market analysis dashboard from scraped community data in under an hour > [!quote] ID:rw_shebuilds_003 > "I didn't spend more than 45 minutes on this and it created me a feature by feature breakdown of what Lovable needs today." Where/why: ~00:13:30, dashboard section. Establishes a concrete time benchmark and output type for no-code PM research workflows. ## Permanent candidates - **Encode security intent in the initial prompt, not as a post-build patch** — supported by the branding-cost analogy (pre-commitment reduces remediation cost) and by Lovable's active security-flagging behavior; promoted below. ## Processing checklist - [x] Ported existing deep-read (Refactor Appendix) into Konik Literature Note format - [ ] Check Apify ToS for Discord/LinkedIn scraping in an educational hackathon context - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Metadata - Source: [[3. Resources/Readwise/Articles/Prepare for SheBuilds Before the Hackathon|Prepare for SheBuilds: before the hackathon]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — pre-sprint discipline and audience-before-solution sequencing are core product-instinct territory