How to Use 48 Hours Before the Hackathon - CourtneyR.dev's 2nd Brain

How to Use 48 Hours Before the Hackathon ![rw-book-cover](https://img.youtube.com/vi/21F_l4DUqR8/maxresdefault.jpg) 🔗 **Source:** [How to Use 48 Hours Before the Hackathon](https://www.youtube.com/watch?v=21F_l4DUqR8#transcript) > [!note]+ Document Notes > tags: [hackathon-preparation, ai-development, product-thinking, startup-strategy, social-impact] > author: Hong Darwin > source: YouTube > reference: https://www.youtube.com/watch?v=21F_l4DUqR8 > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: How to Use the 48 Hours Before the Hackathon >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--how-to-use-the-48-hours-before-the-hackathon) --- ## 📝 Summary - **What happened:** Hong Darwin, a Season 2 alumni of the CBU (Creator Build-Up) program, delivered a pre-hackathon prep webinar for Season 3 participants, sharing a structured 8-step framework for using the 48 hours *before* the 48-hour buildathon begins. - **Why it matters:** Most hackathon participants assume success is a function of coding hours. Hong reframes the real bottleneck as decision-making quality — problem definition, feature prioritization, user empathy, and pitch design — areas where AI cannot substitute for human judgment. - **Key stakeholders:** Prospective hackathon participants (especially non-technical/beginner builders), Lovable (the no-code/AI coding platform central to the build), CBU program organizers, and Hong's own venture Upcop Global (AI-powered financial health for migrant workers). - **Risks and tradeoffs:** Over-building is the primary failure mode. Feature temptation (social feeds, dark mode, gamification) dilutes focus and introduces bugs that kill demos. Under-sleeping is a second major risk — fatigue degrades decision quality precisely when it matters most. - **Bottom line:** The 48 hours before a hackathon are best spent on thinking, not building. A clear problem statement, three real user conversations, ruthless feature cuts, a one-page PRD, and pre-written prompts provide more competitive advantage than any additional coding hour. --- ## 📖 Main Content ### 🧩 The Core Reframe: AI Changed the Bottleneck Hong's central argument is a structural one: AI tools like Lovable can generate code faster than any human, so coding speed is no longer the constraint. The real bottleneck is **judgment** — what to build, for whom, and why. This reframe has practical consequences: preparation time should flow toward problem definition, user research, prompt engineering, and pitch design rather than syntax or stack selection. This mirrors broader product thinking in lean startup methodology (Ries, 2011) and Marty Cagan's emphasis on product discovery preceding delivery. Hong arrives at the same conclusion empirically, from a beginner's lived experience rather than formal product training. ### 🗺️ The 8-Step Pre-Buildathon Framework **Step 1 — Fall in Love With the Problem, Not the Solution** Before selecting any technology, answer four diagnostic questions: - Who *actually* has this problem? - How painful is it? - How often does it occur? - What is the cost if it remains unsolved? The goal is a single, clear problem statement that anchors all subsequent decisions. Hong's example: *"Migrant workers make major financial decisions spanning two countries with informal financial practices and uncertain futures, with no trusted guidance bridging the two systems."* **Step 2 — Talk to At Least Three Real Users** Hong flags the most dangerous founder sentence: *"I already know what users need."* Her own assumption — that migrant workers wanted budgeting tools — was wrong. Real conversations revealed that users already had precise monthly salary plans; the actual pain was in high-stakes life decisions (stay or go home? renovate or pay debt? save or invest?). One honest user conversation can prevent 100 hours of building the wrong thing. **Step 3 — Ruthless Feature Prioritization** Ask: *If a judge sees only one screen or one workflow, what absolutely must work?* Everything else is deferred. Every removed feature is one fewer potential bug, one fewer fragile demo path. Hong's frame: *"Find your one thing and make it flawless."* **Step 4 — Write a One-Page PRD (Product Requirements Document)** Five sections only: 1. **Problem** — one sentence 2. **User** — exactly who you are building for 3. **Workflow** — the single path through the product 4. **Features** — only those serving that workflow 5. **Success** — how you define a successful demo The hidden benefit is downstream: clear thinking produces clear prompts, and clear prompts produce better AI output. *"If your thinking is foggy, your prompts will be foggy, and your output will be too."* **Step 5 — Build a Reusable Prompt Library** Prepare prompt templates across six categories before the clock starts: - **Project setup** — scaffold the stack, routing, and schema in one go - **UI/design strings** — screenshots and component specifications - **Database** — schema tables and policies - **Debug** — isolated error-fixing templates - **Refactor** — component cleanup before demo - **Handover** — state-summary prompts so you can resume after sleep The rationale is cognitive: at 2:00 a.m. under pressure, you want battle-tested templates to iterate from, not blank-page prompting. **Step 6 — Recruit Testers Before the Build Starts** Line up 3–5 testers who match your target user (not polite friends). Prepare a standardized feedback form so patterns are comparable. Book testing slots *before* chaos starts. Hong admits she failed at this step — she couldn't secure migrant worker testers who were available during the build because they were working. The lesson: *validation beats one more feature, every time.* **Step 7 — Design the Pitch Before You Build the Product** Map the story arc first: **Problem → Solution → Demo → Impact**. Then build only what that story requires. The alternative — build everything and retrofit a story — produces scattered demos and rushed pitches. Hong's framing: *"The build supports the pitch, not the other way around."* **Step 8 — Protect Your Energy** Sleep is a competitive advantage. Lovable now supports multiple prompts queued in sequence, meaning the tool can continue generating while you sleep. In an AI-augmented hackathon, the bottleneck is decision quality, and decision quality degrades with fatigue. Hong's contrasting archetypes: Founder A grinds 18 hours and makes poor choices during the pitch; Founder B sleeps 8 hours and catches what matters. ### 🔑 What AI Cannot Do (and Why That Matters) Hong provides a pointed list of capabilities that remain exclusively human: - Choose the right customers - Validate assumptions against reality - Understand the emotional lives of users - Build trust with real people - Prioritize when everything feels equally important - Make strategic product decisions AI is a *force multiplier* on execution; the founder remains the decision-maker. Outsourcing judgment to the machine is the failure mode. ### 🌍 Upcop Global as a Case Study Hong's project — Upcop Global, an AI-powered financial health platform for migrant workers — emerged from CBU Season 2. She entered with no coding background, discovered Lovable shortly before applying, shipped a working prototype in 48 hours, and has continued building full-time, supported by a university scholarship. The project illustrates the talk's thesis: the buildathon was a starting line, not a finish line. The demo became a venture. --- ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=0) Introduction — Emily Beal and Hong Darwin - Emily (Season 1 alumni) introduces Hong (Season 2 alumni) as a beginner-turned-builder. - Hong is the founder of Upcop Global, based in Sweden. - Framing: no coding background, discovered Lovable just before applying. #### ⏱️ [00:03:30](https://www.youtube.com/watch?v=21F_l4DUqR8?t=210) Hong's Origin Story and the Central Claim - Biggest challenge in the buildathon was never the code — it was *making good decisions under time pressure.* - Three core questions: what to build, who to build it for, what to leave out. #### ⏱️ [00:05:30](https://www.youtube.com/watch?v=21F_l4DUqR8?t=330) Learning Resources for AI Coding Beginners - Lovable's own YouTube channel (especially Isaac's content) recommended as starting point. - Second creator: "Tina" — covers AI coding and technology, data scientist/entrepreneur background. - Lovable's Development 101 section and tutorials emphasized; search for docs on functionalities similar to what you plan to build. - Bookmark bar discipline: build it now so you're never Googling at midnight. #### ⏱️ [00:09:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=540) The Myth: 90% Coding - Reality check: AI writes code faster than humans; the bottleneck is thinking and planning. - Key activities: problem definition, feature prioritization, prompting, testing, pitching, storytelling, demo preparation. #### ⏱️ [00:10:30](https://www.youtube.com/watch?v=21F_l4DUqR8?t=630) Step 1 — Define the Problem - Four diagnostic questions: who, how painful, how often, cost if unsolved. - Upcop example: migrant workers, cross-border financial decisions, no trusted guidance bridging systems. - Deliverable: one clear problem sentence as a north star throughout the build. #### ⏱️ [00:13:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=780) Step 2 — Talk to Real Users - Most dangerous founder sentence: *"I already know what users need."* - Hong's assumption (budgeting tools) was wrong; actual pain was big life decisions. - One honest conversation can save 100 hours of building the wrong thing. #### ⏱️ [00:17:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1020) Step 3 — Feature Prioritization - One screen, one workflow: what must work for the judge to understand the value? - Every removed feature = one fewer bug, one fewer fragile demo path. - Tempting-but-cut features named: social feed, dark mode, gamified badges, admin panels. #### ⏱️ [00:19:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1140) Step 4 — Write a One-Page PRD - Five sections: problem, user, workflow, features, success. - Upcop's PRD shown: clear problem, migrant workers in Sweden as pilot user, onboarding → learning path → life decision Q → personalized answer workflow. - Clear PRD → clearer prompts → better AI output. #### ⏱️ [00:22:30](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1350) Step 5 — Prompt Library - Six prompt categories: project setup, UI/strings, database schema, debug, refactor, handover/state-summary. - Build templates now while thinking is clear; iterate from templates during the build. - Knowledge base setup in Lovable recommended; avoids rewriting context from scratch. - Offer: DM Hong on LinkedIn for her own prompt setup and knowledge base structure. #### ⏱️ [00:26:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1560) Step 6 — Recruit Testers - 3–5 testers matching target users; real users, not polite friends. - Standardized feedback form; pre-booked testing slots. - Hong's failure: couldn't secure migrant worker testers who were available during the build window. - Validation > one more feature, always. #### ⏱️ [00:28:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1680) What AI Cannot Do - Cannot: choose customers, validate assumptions, understand user emotion, build trust, prioritize effectively, make strategic decisions. - AI is a force multiplier, not a replacement for founder judgment. - *"You are the decision maker on every feature you are going to build."* #### ⏱️ [00:30:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1800) Step 7 — Design the Pitch First - Story arc: Problem → Solution → Demo → Impact. - Build only what the story needs. The build supports the pitch. - Risk of build-first: demo feels scattered; you try to show everything instead of telling one clear story. #### ⏱️ [00:32:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=1920) Step 8 — Protect Your Energy - Sleep is a competitive advantage; decision quality degrades with fatigue. - Lovable queued prompts: let the tool build while you sleep. - Bottleneck in AI hackathon = quality of decisions, not hours coded. #### ⏱️ [00:34:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=2040) Features Hong Chose Not to Build - Full social network, live FX rate comparison, upskilling marketplace, live chat, gamified labels, bank integrations — all cut. - *"Saying no is a skill and might be the most important one you develop as a founder."* #### ⏱️ [00:36:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=2160) What Happened After the Build - Prototype became Upcop Global; continued building full-time. - University scholarship funding secured to work on it this summer. - The buildathon was the starting line, not the finish line. #### ⏱️ [00:38:00](https://www.youtube.com/watch?v=21F_l4DUqR8?t=2280) Summary and Closing - Full 8-step checklist recap. - Closing mantra: *"Less, learn faster, ship earlier."* - PDF checklist available via LinkedIn DM. - Q&A: project began as an idea ~5 years prior; restarted 6 months before Season 2; still building post-hackathon. --- ## 📚 References - [Lovable YouTube Channel](https://www.youtube.com/@lovable-dev) — Recommended learning resource, especially Isaac's content - [Lovable Development 101](https://docs.lovable.dev) — Beginner-friendly guide to development process and best practices - [Upcop Global](https://www.linkedin.com/in/hongdarwin) — Hong Darwin's venture; AI-powered financial health for migrant workers - [CBU (Creator Build-Up) Program](https://www.youtube.com/watch?v=21F_l4DUqR8) — Hackathon/buildathon program hosting this webinar - Tina — AI coding and data science creator on YouTube (full channel URL not provided in transcript) --- ## 🗣️ Paraphrase - Hong Darwin, a first-generation no-code builder, argues that the 48 hours *before* a hackathon are the highest-leverage window available to participants — not because of what you can build in that time, but because of what you can *decide*. Since AI now handles code generation faster than any human, the real differentiator is the quality of your problem framing, your understanding of users, and your ability to say no to features that feel important but aren't. - Her eight-step framework — define the problem, talk to users, cut features, write a PRD, build a prompt library, recruit testers, design the pitch, and sleep — is both a tactical checklist and a philosophy: build what the story needs, not everything the tool can generate. The demo is not the finish line; it is the proof of concept for the venture you are actually starting. --- ## 📰 Newsletter **🛠️ Before You Build: The 48-Hour Advantage You're Probably Skipping** Most hackathon horror stories have the same plot: a sleepless founder, a feature list that ate itself, and a demo that tried to show everything and landed nothing. Hong Darwin, founder of Upcop Global and CBU Season 2 alumni, has a different story — and a practical reason why. In a pre-buildathon webinar, Hong laid out an 8-step framework for using the 48 hours *before* the hackathon starts. Her core argument: AI tools like [Lovable](https://lovable.dev) have eliminated coding speed as the bottleneck. The new bottleneck is judgment — and judgment is 100% human. Her checklist: **define the problem in one sentence → talk to three real users → cut everything but one core workflow → write a one-page PRD → build a reusable prompt library → recruit testers in advance → design your pitch story first → sleep like your demo depends on it (because it does).** The insight that hits hardest? She assumed migrant workers needed budgeting tools. One real conversation revealed they needed help with high-stakes life decisions — stay or go home, pay debt or invest. One conversation. Hundred hours saved. Bonus: Lovable now supports queued prompts, meaning your AI co-builder keeps working while you sleep. That's not a feature. That's a strategy. 📎 Hong is offering a PDF checklist and her full prompt library setup via [LinkedIn DM](https://www.linkedin.com/in/hongdarwin). --- ## ✅ Action Items #### DevRel - Develop a pre-hackathon preparation workshop module based on Hong's 8-step framework for use at future buildathon onboarding events. - Create a "prompt library starter kit" guide for AI-assisted hackathons, surfacing Lovable's queued prompt feature prominently. - Commission or curate a "what AI cannot do" explainer for developer audiences entering AI-augmented product competitions. #### OSPO - No direct OSPO actions identified from this content. #### Community - **Contributors:** Share Hong's PDF checklist and prompt library template in the CBU Discord ahead of the Season 3 buildathon. - **Maintainers:** Create a structured feedback form template for hackathon tester recruitment that participants can fork and customize. - **Sponsors:** Highlight post-hackathon venture trajectories (like Upcop Global) in impact reporting to demonstrate return on participant investment. #### WordPress - **Training:** Adapt Hong's PRD-writing framework (5-section, one-page format) into a lesson plan for contributor onboarding — the same clarity-before-code discipline applies to plugin and theme development. - **Community:** Use Hong's tester-recruitment model (real users, standardized form, pre-booked slots) as a template for structured user feedback sessions at WordCamps. - **Playground:** Prototype a hackathon-ready Playground environment with pre-loaded prompt templates for common WordPress build scenarios. #### The WPCC - **Programs:** Explore a pre-sprint preparation cohort modeled on Hong's framework for WordPress contributor sprints — structured thinking time before the build window opens. - **Projects:** Document Hong's "what to leave out" methodology as a governance artifact for scoping contributor project proposals. ### FAIR - **Technical independence:** Hong's prompt library principle (local, reusable, version-controlled templates) is a model for reducing dependency on real-time AI availability during builds — applicable to any open-source tooling context. - **Policies and covenants:** The "AI cannot make strategic decisions" framing supports policy language distinguishing AI-assisted execution from human-accountable governance decisions. --- ## 🧪 Hypotheses 1. **H1 — PRD quality predicts demo quality:** Participants who complete a one-page PRD before the build clock starts will produce demos rated higher on clarity and coherence by judges than those who do not. 2. **H2 — User conversations reduce feature scope:** Builders who conduct at least three pre-build user interviews will ship fewer features and receive higher validation scores than those who rely on assumed user needs. 3. **H3 — Sleep improves decision quality under time pressure:** Hackathon participants who sleep at least 6 hours mid-build will make fewer scope-expanding decisions in the final 12 hours than those who grind continuously. 4. **H4 — Prompt libraries reduce error recovery time:** Builders with pre-prepared debug and refactor prompt templates will spend less time on error recovery and more time on polish during the final build hours. 5. **H5 — Pitch-first design improves demo narrative coherence:** Participants who design their pitch arc before building will receive higher storytelling scores than those who construct pitch narrative post-build. 6. **H6 — Hackathon projects with post-event continuation signal stronger problem-fit:** Projects that continue as active ventures 6 months post-buildathon correlate with pre-build user interviews having been conducted. ### 📊 Methodology - **H1:** Randomized cohort study across one hackathon cohort; PRD completion tracked via submission form; demo quality rated by blind judges on a rubric covering clarity, focus, and coherence. - **H2:** Pre/post survey on features planned vs. features shipped; judges rate demo on "does this solve a real problem" scale; interview completion self-reported and spot-verified. - **H3:** Wearable sleep tracking or self-report; scope decisions coded from build logs or commit history; decision quality rated by participant retrospective survey. - **H4:** Lovable session logs (if available) measuring time spent in debug vs. feature-building states; compared across participants with/without pre-built prompt libraries. - **H5:** Pitch scoring rubric with storytelling dimension administered by judges blind to preparation method; preparation method captured in post-event survey. - **H6:** 6-month follow-up survey of all participants; "active venture" defined as continued public development activity or funding received. ### ❓ Questions - How transferable is Hong's framework to team builds vs. solo builds? Does the PRD step require facilitation in a multi-person context? - What is the minimum viable user interview for a 48-hour hackathon — how long, what questions, what counts as "real" user vs. proxy? - Does Lovable's queued prompt feature actually sustain meaningful build progress during sleep, or does it require human review at each step? - How does the "pitch first, build second" principle interact with discovery during the build — what happens when building reveals a better problem framing? - Is the social impact category structurally harder to scope because of the emotional complexity of underserved user groups? ### 🔮 Future Research - Longitudinal study of hackathon participants tracking which preparation behaviors (user interviews, PRD, prompt libraries) predict post-hackathon venture continuation. - Comparative analysis of AI-augmented hackathons vs. traditional hackathons on feature creep rates and demo quality scores. - User research methodology adapted for time-constrained build contexts — a validated "minimum viable interview" protocol for hackathons. - Investigation of cognitive load and decision fatigue in 48-hour build events, with intervention design around sleep and structured breaks. - Analysis of Lovable prompt patterns: which prompt templates most reliably produce clean, demo-ready output from beginner users? ### 💡 Implications - **Practice:** Hackathon organizers should incorporate structured pre-build preparation windows (24–48 hours of guided frameworks) as a formal program element, not optional enrichment. - **Education:** The "AI changes the bottleneck from coding to judgment" argument has curriculum implications — product thinking, user empathy, and storytelling should precede or accompany AI coding tool instruction. - **Policy:** If AI-assisted development is now accessible to non-technical founders, startup accelerator evaluation criteria should weight problem clarity and user validation over technical sophistication. - **Security:** Hong's prompt library concept raises supply-chain-adjacent questions: pre-built prompt templates shared across a cohort could propagate bad patterns at scale if not reviewed. - **Funding models:** Hong's trajectory (hackathon → university scholarship → full-time build) suggests micro-grant and fellowship structures aligned to hackathon cohorts could accelerate social impact ventures with no prior runway. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level approximately 7–9. Conversational, low-jargon, narrative-driven. Accessible to general audiences. Occasional sentence fragments and non-native English patterns present but do not impede comprehension. #### 👀 Visual learners - **Present:** Slide deck referenced throughout; PRD example shown on screen; bookmark bar screenshot mentioned. - **Improve:** Publish the slide deck publicly with annotated architecture diagrams of the 8-step framework; add a visual flowchart of the PRD → Prompt → Build → Pitch pipeline; before/after feature list comparison graphic. #### 🔊 Aural learners - **Present:** Full video with clear narration; conversational delivery with real-world examples. - **Improve:** Standalone 3-minute audio summary of the 8-step checklist; podcast-format episode with Hong expanding on the user interview step. #### 🗣️ Verbal learners - **Present:** Rich analogies (Founder A vs. Founder B; "fall in love with the problem"); plain-language definitions of PRD, feature prioritization, prompt library. - **Improve:** Glossary of terms (PRD, prompt library, handover prompt, knowledge base, force multiplier) for participants unfamiliar with product management vocabulary. #### 🧩 Kinesthetic learners - **Present:** Concrete checklist; step-by-step framework; PDF offered for download. - **Improve:** Interactive worksheet for each of the 8 steps; a fillable PRD template; a "practice user interview" exercise with sample questions. #### 🧠 Logical learners - **Present:** Causal chain (clear problem → clear PRD → clear prompts → better AI output); bottleneck analysis (coding no longer the constraint). - **Improve:** Decision tree for feature prioritization ("does this serve the one core workflow? yes/no"); comparison table of time allocation before/after AI augmentation. #### 🧑‍🤝‍🧑 Social learners - **Present:** Discord channel recommended; peer connection encouraged; QR code for LinkedIn. - **Improve:** Peer PRD review protocol; cohort buddy system for pre-build user interviews; structured discussion prompt for Discord: "What is your one-sentence problem statement?" #### 🧘‍♀️ Solitary learners - **Present:** PDF checklist offered; self-paced preparation implied. - **Improve:** Self-assessment rubric ("how clear is my problem statement?"); reflection journal prompts for each of the 8 steps; solo practice prompt library exercise. #### 🌿 Naturalistic learners - **Present:** Social impact framing (migrant workers, financial inclusion) provides real-world ecosystem context. - **Improve:** Draw explicit connections between the "build only what the story needs" principle and sustainable product development; lifecycle thinking for post-hackathon venture growth. ### 📊 Accessibility Assessment #### Screen reader semantics - **Present:** Video has spoken audio; content is primarily verbal. - **Improve:** Publish slide deck with proper heading hierarchy and alt text on all diagrams; ensure PDF checklist is tagged for screen reader navigation. #### Keyboard navigation - **Present:** Not directly applicable to video format. - **Improve:** Ensure any published web resource (checklist, PRD template) is fully keyboard navigable. #### Contrast and readability - **Present:** Not assessable from transcript alone. - **Improve:** Verify slide deck and PDF meet 4.5:1 contrast minimum; use high-contrast template for shared resources. #### Text resizing and reflow - **Present:** Not directly assessable. - **Improve:** Ensure PDF checklist is responsive or available in HTML format that reflows at 200% zoom. #### Media and captions - **Present:** Video is on YouTube; auto-captions likely available. - **Improve:** Add accurate human-reviewed captions (auto-captions may struggle with non-native English patterns and proper nouns like "Upcop," "Lovable," "CBU"); publish a downloadable transcript. #### Forms and interactions - **Present:** Feedback form mentioned but not published in this session. - **Improve:** Ensure any feedback form linked from the session meets WCAG label and error handling requirements. #### Standards reference - Caption accuracy gaps → WCAG 1.2.2 (Captions, Level A) - Missing transcript → WCAG 1.2.3 (Audio Description or Media Alternative, Level A) - PDF accessibility → WCAG 1.3.1 (Info and Relationships, Level A) ### 🌍 DEIB Assessment #### Cultural breadth - **Present:** Migrant worker focus provides genuine global and cross-cultural grounding; Sweden/Southeast Asia corridor specifically named. - **Improve:** Acknowledge that "talk to three users" advice has different friction levels for builders from communities with less social capital or less access to potential users in their network. #### Inclusive language - **Present:** Gender-neutral language used throughout; "founder" used without gender assumption; Hong models female technical founder identity. - **Improve:** Avoid "guys" as a gender-neutral address (used once in introduction); add plain-language summary for participants whose first language is not English. #### Neurodiversity support - **Present:** Chunked 8-step structure; numbered framework aids predictability; checklist format reduces cognitive load. - **Improve:** Increase heading frequency in any published materials; provide icon+text labels on checklist items; offer audio-only version for participants who process better aurally. #### Representation - **Present:** Speaker is a woman of color, immigrant, non-technical founder — visibly underrepresented in tech entrepreneurship. This is itself a significant representation contribution. - **Improve:** Future sessions could explicitly name the access and representation dimensions of AI-lowered coding barriers for underrepresented founders. #### Psychological safety - **Present:** Hong openly names her failures (wrong user assumption, no testers secured); this normalizes imperfection and reduces shame for beginner participants. - **Improve:** Add an explicit framing that "no coding background" is not a disqualifier; Discord community guidelines should be surfaced for newcomers. ### ✅ Logical Validity #### Strong reasoning - **Causal chain — PRD clarity to AI output quality:** Hong's claim that clear thinking produces clear prompts which produce better AI output is well-reasoned and practically testable. It is consistent with prompt engineering research showing that specificity and context in prompts significantly improve LLM output quality. - **Bottleneck reframing — AI shifts constraint from coding to judgment:** This is a strong inductive argument grounded in lived experience and consistent with broader observations about AI's effect on knowledge work. The logic holds: if AI can generate code faster than humans, the human constraint moves upstream to problem definition. - **Analogical — Founder A vs. Founder B:** Effective rhetorical device making the sleep argument concrete. Not a logical proof but a well-constructed illustration. #### Fallacies - **Hasty generalization (minor):** *"We all know that AI nowadays and tools like Lovable already can help us do the coding faster than any of us."* This overstates AI coding capability; it holds for common patterns but not for complex systems engineering. For the hackathon context this is approximately true, but the qualifier matters for general application. - **Appeal to personal experience (minor):** Much of the framework is derived from a single buildathon experience. While compelling and internally consistent, a single case is not sufficient to establish the framework as universally optimal. The advice to talk to three users is ironic given that the framework itself is based on n=1. #### Tone of voice - **Warm, self-disclosing, peer-to-peer:** Hong consistently positions herself as a fellow learner rather than an authority. *"I learned of course in the hard way."* *"I failed to do this."* This tone is pedagogically effective for a beginner audience and reduces defensive resistance to the framework. - **Urgently practical:** Short sentences, numbered steps, direct imperatives. *"Find your one thing and make it flawless."* *"Saying no is a skill."* This matches the time-constrained context of hackathon prep. ### 🛡️ DARVO Analysis - **Deny:** Not applicable. This is an educational webinar; no accusation is being defended against. - **Attack:** Not applicable. - **Reverse victim/offender:** Not applicable. - **Note:** The closest rhetorical move to DARVO dynamics is Hong's preemptive reframe of the "I know what users need" assumption as the most dangerous founder sentence — this positions the audience's likely default assumption as the adversary, not a person. This is a legitimate pedagogical device, not a DARVO pattern. --- ## 🎯 Conclusion Hong Darwin's core argument is simple and empirically grounded: in an AI-augmented hackathon, the human is the bottleneck, not the code. The 48 hours before the build are the highest-leverage window because they are the only window where you can think without the pressure of a running clock distorting your judgment. Her 8-step framework is actionable, sequenced, and derived from honest reflection on both what worked and what failed. The most durable takeaways are structural: define before you build, talk to real users before you assume, cut features before you fall in love with them, design the story before you build the demo, and sleep before you pitch. **Practical next steps for readers:** 1. Write your one-sentence problem statement today. 2. Schedule three user conversations before the buildathon opens. 3. Build your bookmark bar and prompt library template this week. 4. Draft your five-section PRD before the build clock starts. 5. Design your pitch arc (Problem → Solution → Demo → Impact) before writing a single prompt. 6. Book 8 hours of sleep into your buildathon schedule as a non-negotiable. 7. DM Hong Darwin on LinkedIn for her prompt library setup and PDF checklist. --- ## 🔄 Refactor Appendix — How to Use the 48 Hours Before the Hackathon ### 📚 Literature Atoms #### [H1] AI shifts the hackathon bottleneck from coding to judgment > [!quote] ID:rw_001 > "The biggest challenge was never the code during this buildathon. It was more about making good decisions under time pressure." **Context & use:** - Delivered approximately 4 minutes into the talk; central thesis of the entire presentation. - This reframes preparation strategy for any AI-augmented build context — not just hackathons. Applies wherever AI automates execution and elevates human decision-making as the scarce resource. **Tags:** #xref #aphorisms **Highlight:** [view highlight](readwise://highlights/001)  --- #### [H2] Clear PRD thinking directly improves AI-generated output quality > [!quote] ID:rw_002 > "If your thinking is foggy, your prompts will be foggy as well, and your output will be unclear as well." **Context & use:** - Stated during Step 4 (PRD section); approximately 20 minutes in. - Directly relevant to anyone using LLMs for code generation, content, or product work. The PRD is not bureaucratic overhead — it is prompt pre-computation. **Tags:** #xref #articleseed **Highlight:** [view highlight](readwise://highlights/002)  --- #### [H3] One real user conversation prevents 100 hours of wrong-direction building > [!quote] ID:rw_003 > "One honest conversation with a real user can save you a hundred hours of building the wrong thing later on." **Context & use:** - Stated during Step 2 (user interviews); approximately 15 minutes in. Supported by Hong's own example: assumed budgeting tools needed; reality was high-stakes life decisions. - Applies to any product or project context. The ratio (1 conversation : 100 hours) is rhetorical but the directional claim is well-evidenced by lean startup practice. **Tags:** #xref #aphorisms **Highlight:** [view highlight](readwise://highlights/003)  ### 🧠 Permanent Candidates #### [P1] Decision quality is the primary competitive variable in AI-augmented builds **Claim** (one sentence, in my voice): When AI handles code generation, the quality of a builder's decisions about problem, user, and scope determines outcomes more than time spent building. **Evidence pointer:** [[#H1]] > [!quote] > "The biggest challenge was never the code during this buildathon. It was more about making good decisions under time pressure." **Scope & conditions:** - Holds when: AI tooling is sufficiently capable to handle the execution layer (code generation, UI scaffolding, debugging) without requiring deep domain expertise from the builder. - Breaks when: The technical problem is sufficiently novel or complex that AI cannot generate working code without expert human guidance — i.e., frontier research, highly specialized systems engineering. **Links:** - [[AI as force multiplier]] — because extends - [[Prompt engineering]] — because applies-in execution contexts - [[Lean startup — build-measure-learn]] — because contrasts on locus of iteration (build vs. decide)  ### ✏️ Fleeting Queue - [F1] Hong's prompt library structure (6 categories: setup, UI, database, debug, refactor, handover) — request full template via LinkedIn DM — #fleeting #inbox - [F2] "Lovable now supports multiple prompts in queue" — verify current feature status and document as a build strategy for AI-assisted projects — #fleeting #inbox - [F3] Tina's YouTube channel on AI coding — find full channel URL and add to learning resources list — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] DM Hong Darwin on LinkedIn to request prompt library setup and PDF checklist — reference CBU webinar — #things - [ ] Draft a one-page PRD template based on Hong's 5-section structure (problem, user, workflow, features, success) for reuse in future build projects — #things --- ``` Processed: How to Use the 48 Hours Before the Hackathon - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 3 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref, #aphorisms, #articleseed] - Triage callouts populated: [Cross Reference, Article Ideas] - Quality gates: ✓ Verbatim quote check: all H3 atoms contain direct transcript quotes ✓ Atomicity check: all permanent candidates end with atomicity marker ✓ Link annotation check: all wikilinks include — because <relationship> ✓ YAML hygiene: no [MISSING] strings present ✓ Konik triage check: all tagged highlights routed to callouts ✗ Version History Diff readiness: [view highlight] links are placeholder URLs; real Readwise IDs not available from video transcript - Override conditions triggered: none ``` --- ## Full Transcript [00:19] Hey everyone, thank you so much for [00:22] joining. I'm so excited you guys are [00:24] here. For those of you who don't know, [00:28] my name is Emily Beal and I actually was [00:31] in your shoes not too long ago. I was a [00:34] season 1 participant. [00:36] um and was definitely excited, feeling [00:39] anxious and nervous preparing for a [00:42] hackathon and to build for 48 hours. But [00:45] I'm so excited that we have Hong here [00:47] today, uh one of our season 2 alumni who [00:50] is going to be talking about how you can [00:53] um prepare for the 48 hour buildathon [00:57] and and get started. So, H, I'm gonna [01:01] let you um take it away. And yes, Jav, [01:05] if you can put where you're from in the [01:07] chat, we would love to hear where you're [01:08] tuning in from all over. [01:11] Thank you so much, Emily, for the [01:13] introduction. Uh, first, let me start to [01:16] share my screen because I Yeah, I'm very [01:19] bad at talking on my own, so I always [01:21] need to have a slide whenever I talk. [01:23] So, bear with me with the slide here. [01:25] And uh, I will share it now. [01:43] Okay, let me know if you should see what [01:46] you should see. [laughter] [01:48] >> We can see it perfectly. Thank you, [01:49] Hana. [01:50] >> Okay, thank you so much. And uh since [01:52] I'm talking here, I might not be able to [01:55] see uh what happening on the chat. So [01:57] Emily, please help me to jump in if [02:00] there's any question that I need to [02:02] answer immediately. Otherwise, I'm happy [02:05] to share more on Q&A at the end of uh [02:09] the talk. Does it work? [02:11] >> Yes, we'll do Q. If you have um [02:13] questions or comments as we go, feel [02:15] free to throw them in the chat. Jav and [02:16] I will help bring them all to light at [02:18] the end. So, go ahead, Han. [02:20] >> Okay, thank you. So, now, hi everyone. [02:23] Uh and welcome. My name is Hong Dawin [02:27] and uh I'm the founder of Upcop Global [02:29] and I'm based in Sweden. Um I join CU [02:34] season 2 as a participant in the social [02:37] impact category and uh I work in the C [02:42] bills like when I apply for it I I had [02:45] almost no coding background at all and I [02:49] also even didn't know what V coding was [02:51] yet at that moment. Um, and I just [02:54] figure out I just found out loveable not [02:58] uh long before I uh sent in my [03:00] application for CBU season 2 and I was [03:03] lucky to be chosen as one of those [03:05] participant during that season. Um, and [03:09] uh I just want to be clear up front [03:12] before we start that uh of course I'm [03:15] not here to teach you how to cook [03:16] because I'm not in any position to do [03:19] so. And uh we all know that AI nowadays [03:24] and tools like loveable book already can [03:26] help us to do the coding faster than any [03:30] of us here. Um and what I want to share [03:33] with you today is more about how to use [03:35] the 48 hours before the build button [03:39] wisely. Um yeah, it just a way to um to [03:43] play with the workings here like you [03:45] going to have 48 hour to build. So how [03:47] to use 48 hour before that in a good way [03:51] and uh during this chat or talk um I [03:55] will weave in my own experiences along [03:58] the way so you can see what work and [04:01] what I learned of course in the hard way [04:04] during that time. So uh let's start. Um [04:09] so as I share before I started with no [04:12] coding background at all and um and then [04:16] I discover loveable tune um that um it [04:20] it it helped me build working prototype [04:22] in 48 hours and uh and ever since I kept [04:27] building a cop uh afterwards [04:30] when uh I signed up for CBU season 2 I [04:33] couldn't write a single line of [04:35] production code and it's still like that [04:37] until Now um and tune liable it helped [04:41] me a lot and then suddenly I could ship [04:44] a working prototype in minutes those [04:46] that I could have any like idea on how [04:50] it would perform but I have no idea how [04:52] to make it a real like real working [04:55] prototype to show to other people to see [04:57] it and I joined the social impact track [05:01] had 48 hours and I was a total beginner [05:04] at a time um but I came out the other [05:07] side with a working demo and uh after [05:10] that I keep building. So the project [05:13] became up global and something I'm still [05:16] building today and I'm still working on [05:19] it um full-time during this summer as [05:22] well. Um and here's the thing I want to [05:25] uh you to take away from uh from our [05:31] sharing today. um that uh the biggest [05:34] challenge was never the code during this [05:37] buildaton. Um it was more about making [05:40] good decisions under time pressures. [05:44] Remember you only have 48 hours to build [05:46] what you want to build to showcase for [05:48] the demo. So what to build, who to build [05:52] it for and uh so they uh maybe the most [05:56] important thing and what to leave out. [05:58] So that what this whole chat today is [06:01] about and um so um now as promised let's [06:07] start with practical stuff um as I put [06:10] on the description of the session today [06:13] um before the baton I spend time [06:17] figuring out on like what YouTube [06:20] channel should I watch to understand [06:22] more about the whole thing about app [06:25] stack development and how to use fable [06:28] in a good way. What tutorial should I [06:30] read? What link should I bookmark so I [06:34] can keep coming back during the bill? So [06:36] here's what help me learn v coding as a [06:39] complete beginner. I of course I started [06:42] with YouTube. Um and uh just so you know [06:46] I have no connection with those that I'm [06:48] going to share now with those creator [06:51] they so they are just they are simply [06:54] the channels and video I found useful [06:57] when I was searching for something that [07:00] um so I can learn about laughable and AI [07:04] coding too. So those are basically those [07:08] all of those video that I watched during [07:10] that time and um and these are my [07:13] bookmark look like at the time as well [07:16] and even on the day of the buildon. It [07:19] was full of links I could refer back to [07:21] weekly videos on building phone stack up [07:24] with loveable from engineering guide [07:26] superbase integration documents and [07:29] viruses. uh and also of course lovable [07:31] prompting bible UI component and library [07:35] for UI UX. I really encourage you to [07:38] start building your own bookmark bars [07:40] from now because you when you are in the [07:43] middle of a view and something breaks at [07:45] midnight, you don't want to keep Google [07:47] link from scratch. You want your best [07:50] resources one click away. [07:54] And um after watching what I felt like [07:57] hundred of video um which honestly took [08:01] me almost a full week before the butadon [08:04] a few stood out as absolute favorite to [08:06] me and hopefully sharing themsel you [08:10] lost of uh time to prepare. First um I [08:15] would of course recommend watching [08:17] everything on loveable YouTube channel. [08:20] I especially like Isac so much his [08:22] content because he is very don and uh [08:26] explain everything in a very simple and [08:29] practical way for beginner like me. If [08:32] you are just getting started with [08:34] loveable is one of the best places to [08:36] begin. Another creator I kept coming [08:39] back to is her name is Tina and I [08:43] originally found her through a few [08:46] lovable videos but then I stay for the [08:48] rest of her content because her channel [08:51] is cover AI coding and technology more [08:54] broadly which help me build some kind of [08:57] strong foundation in order to understand [09:00] a bit more on the code that lovable help [09:03] me to create and honestly what not to [09:05] like her she is a data science [09:07] scientists and entrepreneurs and a woman [09:09] as well who understand exactly that kind [09:12] of challenge many of us face. What I [09:15] appreciate most is how she break down [09:17] complex things into explanation in a [09:20] simple practical way [09:23] and remember don't skip lovable own [09:26] resources seriously their guides and [09:29] tutorials are worth going through in [09:32] details. You should check out their [09:34] development 101 section. It's a beginner [09:37] friendly guide to the development [09:40] process, best practices and key inside [09:43] and also spend time on their tutorials. [09:46] Uh sorry. Yeah. Um it give you practical [09:50] step-by-step guide on lovable tunes and [09:53] features and a good tip try to search [09:56] for their document on functionalities [09:59] similar to what you are planning to [10:01] build because chances are they are [10:04] already tutorial or example that get you [10:07] halfway there. So you don't need to [10:09] start thinking from scratch on what you [10:12] want to build. [10:15] So now you still have plenty of time to [10:18] learn the tune and techniques because [10:20] today is only Monday and you still [10:23] obviously have more than 48 hour when uh [10:26] the build is actually start on the 21st [10:29] June if I'm not wrong. So today I want [10:32] to go to bay on the tunes and talk more [10:35] about something even more important [10:38] about what you should actually do [10:41] during the 48 hours before it and your [10:45] kind of checklist. Here's the biggest [10:48] myth. Most people thinks of [10:52] is about um um 90% coding and 10% of [10:58] everything else. But in reality, AI can [11:01] write code faster than any of us. So the [11:04] bottleneck is no longer coding. It's [11:07] about thinking and planning. The [11:09] activities that actually determine [11:11] whether you succeed are problem [11:14] definition, feature prioritization, [11:16] prompting, testing, pitching, [11:18] storytelling, and demo preparation. AI [11:22] can help you build but it cannot decide [11:25] what problem to show, which feature [11:28] matter most or how to tell a story that [11:31] moves people to explain why you are [11:33] building what you are building. So [11:35] that's where your preparation time [11:37] should go. [11:40] So um here's the like what I call it a [11:44] spider the structure of the kind of [11:47] checklist that I wish to build 48 hour [11:50] before I go into the bill itself. Um so [11:54] they are basically a step framework I [11:58] use myself during that time before the [12:00] bill begins. So firstly start with [12:04] define the problem. Two talk to the [12:07] user. Three cues features. Four rise the [12:10] PR product requirement document. Five [12:13] prepare prompts. Six recruit tester. [12:17] Seven design the pitch. And eight [12:19] protect your energy. I will walk you [12:21] through one by one. Now um so let's talk [12:27] about step one. So step one I call it [12:31] phone fall fall in love with the problem [12:34] not the solution before you choose any [12:37] technology get crystal clear on four [12:40] things who actually has this problem how [12:43] painful is it for them how often does it [12:46] happen and what's the cost if it still [12:49] stays unsolved without your solution [12:52] that you are going to build um and let [12:55] me give you uh my of example as an [12:58] example [12:59] So the problem that I we fell in love [13:03] with was about migrant workers who make [13:06] major financial decisions that spend [13:09] across two countries with informal [13:11] financial practices and certain f and [13:15] uncertain futures usually with no [13:18] trusted guidance. They deal with [13:20] informal financial practices that formal [13:23] system often choose not to understand. [13:26] They face an uncertain timeline. They [13:29] don't know how long they going to stay [13:30] in the host country and there's no guy [13:34] that can help them bridge the gap [13:36] between the financial system where they [13:38] work and the one where their families [13:40] are the one that they are already [13:42] familiar with, what they know and good [13:44] at and what they should build up on. And [13:47] that clarity on the problem matters far [13:50] more which text we going to pick. So [13:54] before you touch any code or start to [13:56] build anything, make sure you can [13:59] describe the problem in one clear [14:01] sentence and it's going to be the [14:03] statement for you throughout the bill. [14:08] And uh step two, this one is a big one [14:12] because the most dangerous sentence a [14:15] founder can say is I already know what [14:17] users need. Um let's talk at least to [14:22] three potential users before the build. [14:25] Um for us when for me when I uh build up [14:29] CO during um CU season 2 I like at that [14:34] time usually we assume people don't the [14:38] the group of users I targeted at that [14:40] time the migrant um workers we assume [14:44] that they wanted budgeting tools you [14:47] know have managing their monthly salary [14:51] that seems neat obvious ready and it was [14:54] comp But it was completely wrong. When [14:58] um I actually talked to migrant workers, [15:00] they told me something different. Yes, [15:04] they already have detail plan for their [15:06] monthly salaries. Of course they do. [15:10] When like imagine that with you if you [15:13] are in their situation when you have [15:16] left your family to take on manual works [15:18] overseas for better pay sometime after [15:21] borrowing money just to get the job or [15:23] just to get an airplane ticket to leave. [15:26] You know exactly where every dollar [15:29] should go every month. [15:32] So what they actually struggle with are [15:34] the big life decisions. Should I stay in [15:37] this country? Should I go home? Should I [15:39] renovate my family's house at home first [15:42] or pay off the debt first? Should I save [15:45] or invest? And for every one of those [15:47] question, a deep why and how underlying [15:51] with it. So, one honest conversation [15:54] with a real user can save you a 100 [15:57] hours of building the wrong thing later [15:59] on. [16:02] Um, moving on to step three is about [16:05] less features, more impact. This is [16:08] about ruthless prioritization. [16:11] And honestly, it's what wins the build [16:14] aton. Ask yourself this question. If the [16:17] just only see one screen or go through [16:20] only one workflow, what absolutely must [16:23] work for them to see what you absolutely [16:27] must show them. then everything else can [16:30] wait. Every feature you remove is a bug [16:34] you don't have to fix during the view. [16:36] It's a demo pad that can break is time [16:40] return to polish the thing that actually [16:43] matters. [16:45] So those like social feed dark mode [16:48] gamify batches admin panels they are all [16:51] tempting but none of them matter if your [16:54] code workflow doesn't land. So find your [16:57] wanting and make it flawless. [17:01] And moving on to step four about write a [17:05] one page B product requirement document. [17:09] Um so this is your secret weapon and I [17:12] mean that a brces you to think before [17:16] you view and here's the hidden benefit. [17:19] It dramatically improve what AI generate [17:22] for you because the AI inherit your [17:25] clarity. If you are thinking if your [17:28] thinking is FG your ROMs will be FG as [17:31] well and your output will be like [17:34] unclear and as well. So keep it to five [17:38] sections. problem. The cop and in one [17:41] sentence user who exactly you are [17:44] building for workflow the single pad [17:47] through the product features only the [17:50] field that serve that workflow and [17:52] success. How would you define the [17:55] success of the demo you are going to [17:57] build? On the right you can see a [17:59] simplified version of the view of the P [18:03] that I build at that time. So our [18:05] problem was very clear about migrants [18:08] lack cross trust guidance for money [18:10] decision. Our user migrant workers in [18:13] Sweden and their families as our pilot [18:16] and uh to make it work before adding [18:19] more corridors. Um our workflow on [18:22] boarding then personalized financial [18:25] learning path then ask a life decision [18:28] question and then get a clear [18:30] personalized answer feature going to be [18:34] a learning path an AI but a goal tracker [18:37] nothing else yet just placeholders for [18:40] the rest and success. how how could I [18:44] know a smooth flow where a migrant [18:46] worker can see what they would actually [18:49] get from the product from the solution [18:51] I'm offering them. So a clear PD equals [18:55] with clearer promps equals better AI [18:59] output. And yeah, so that's just that [19:02] simple. [19:04] Um, and so what's next? Um, walk into [19:10] the build with a ROM library or your [19:15] pre-prepared library. This is a real [19:18] competitive advantage for you and it can [19:21] save you hours during the 48 hours deal [19:24] itself. Um you can repair reusable [19:28] prompts for in those six categories for [19:32] project setup. So you can scaffold the [19:35] stack routing and team in one go. Also [19:38] plan on what to put on your project [19:41] knowledge base from the start. It will [19:43] save you a lot of time. keep writing the [19:45] same prom over and over during the view [19:48] UI and strings. Um, so to collect [19:52] screenshots example of how each function [19:55] page should look like to generate the [19:58] core strings that match with your P [20:01] database for your schema tables and [20:04] policy. Debug a repeat table structure [20:07] to isolate and fix error fast. refactor [20:11] to clean up and split components before [20:13] the demo and hand over coming back [20:16] prompts to sum to summarize the current [20:19] state so you can pick up you and your [20:23] loveable uh partner can pick up exactly [20:26] where you left off. Why? Of course, you [20:29] will need a few breaks during the 48 [20:31] hour views including obviously a long [20:34] sleep at some point of time to recharge [20:37] your energy. So the point is you don't [20:40] want to be winging each broom at [20:42] midnight or at 2:00 a.m. in the morning. [20:45] You want to base battle tested template [20:48] and iter from there. Repair them now [20:52] while you have the time to think clearly [20:54] during 48 hours before going into the [20:57] real view. Yes. Uh yeah I would of [21:01] course love to share what I set up what [21:03] setup I use on setting knowledge base [21:06] for my project first prom and the [21:08] subsequent promps I use between fs etc. [21:11] I don't know how to include them during [21:14] this webinar. So just DM me on um [21:18] LinkedIn later if yeah and I will be [21:21] happy to share with you [21:24] and um so what's next? So I would say [21:28] that don't wait until launch day to find [21:32] out if your idea actually lands. Um, you [21:36] should line up three to five testers [21:39] before the build starts so that when you [21:41] build, you can have some tester already [21:44] ready there to help you test when you [21:47] build. So, um, make sure they match with [21:50] your target users, real users who will [21:54] give you honest feedback, not friends [21:56] being polite with you. prepare a simple [21:59] feedback form with the same questions [22:01] for everyone so you can spot clear [22:04] patterns to fix and book the testing [22:08] time slot now before the chaos during [22:11] the button hits. Um so for me when I [22:16] build up cop I I I failed to do this [22:19] because basically I couldn't secure any [22:22] real tester who are migrant users who [22:25] can help me to test during the bill [22:27] because basically they need to work [22:29] during that time like during my time um [22:33] in Sweden. So I didn't have any real [22:37] migrant migrant workers who could help [22:39] me to test during the bill. So this was [22:43] one that uh I wish I could have more [22:46] time to look for the right tester with [22:49] to be with me during that uh during the [22:52] build and remember validation [22:55] one more features every single time. [22:59] Um and uh so this might be the most [23:04] important slide in the whole [23:06] presentation here about how you uh [23:09] should plan on your checklist during 48 [23:13] hours before the view. AI is yeah it's [23:17] powerful. It generate code. It help you [23:20] grace interfaces, write contents, [23:22] debugs, and as accelerate your execution [23:25] speed in a ways that that would have [23:28] been unimaginable a few years ago. But [23:31] here's what AI cannot do. It cannot [23:34] choose the right customers for you. It [23:37] cannot validate your assumption. It [23:39] cannot understand the emotion of the [23:41] people you are building for. It cannot [23:43] build trust either by talking to you to [23:46] real people. It cannot prioritize [23:49] effectively when everything seem [23:52] important equally and it cannot make [23:55] strategic decisions about what your [23:57] product should be. So AI and loveable is [24:01] as a tune here is should be a force [24:04] multiplier. It make you do yeah it make [24:09] you faster and more productive but is it [24:12] not a replacement for your judgment as a [24:15] founder. So your judgment, your empathy, [24:18] your understanding of the people you [24:20] serve, that's the real age. Don't [24:23] outsource that to the machine. You know [24:25] exactly what you need to build. Trust [24:27] yourself and use AI lovables at your [24:31] thought, your thinking partners. But [24:33] always remember you are a decision maker [24:36] on every features you are going to [24:39] build. [24:42] Um and uh this might be the one not yeah [24:47] the second last step I break it into [24:49] step eight 8 A and 8 B and this one is [24:53] counter into is still like design your [24:56] piece before you build the product map [24:59] out the story first problem solution [25:02] demo impact as five step in that order [25:06] then build only what the story needs so [25:09] you can show the demo in a good way. So [25:14] the build supports the beach. What you [25:16] are going to build is to support this [25:19] not the other way around. If you build [25:21] first and try to figure out your story [25:24] why to explain why in your piece what [25:27] you want to show at the very end you [25:31] might run out of time and your demos [25:33] feel like sc because you then try to [25:36] show everything you build instead of [25:38] telling you remember I I share before [25:41] that we should have one workflow that [25:45] absolutely flawless that is the one [25:48] clear story and flow that you should [25:50] show start with the story then build a [25:54] demo that brings the story to life. [25:59] Um and uh yeah I I I like this uh slide [26:05] because the yeah this is also important. [26:09] So uh you need to protect your energy. [26:12] Sleep is a competitive advantage. [26:16] Picture two founders. Father A like have [26:20] grind for 18 hours straight by by the [26:25] time like that he or she need to prepare [26:28] the the pitch the demo he or she already [26:32] exhausted and she's making poor rous [26:34] decisions and father B sleeps a solid [26:38] eight hours she shaped her decision are [26:42] calm and clear and she catches what [26:44] matters and remember lovable now support [26:47] multiple prompts in queue. So yeah [26:51] during my time I think it was not there [26:53] at that time. So you can make use of [26:56] that functions to plan on your prom and [26:59] uh make lovable your lovable partner [27:02] continue to build feature while you can [27:04] take a long eight hours sleep [27:07] in. So in an AI button the botock is not [27:12] how many hours you code it's the quality [27:15] of your decision and decision quality [27:18] comes from rest. So please eat well [27:20] sleep enough take breath before the bill [27:24] and also during the bill as well. Your [27:26] brain is the most important tool and [27:29] treat it like the most powerful one. [27:32] Um [27:34] uh let me show you what it look like in [27:38] uh practice. Um these are real of [27:41] building features. Um I yeah I literally [27:46] choose not to build when I build my [27:49] prototype for a cop at a time. So a full [27:52] social network live fxra comparison [27:55] upskilling opportunities for migrant [27:58] workers users as an inapp marketplace [28:01] live chat among user gamify lable and [28:05] bank integrations. I say bye-bye rest in [28:09] peace for all of those features. Every [28:11] single one of them was tempting for me [28:14] but every single one would have diluted [28:17] the focus my focus at that time. So [28:20] saying no is a skill and honestly it [28:23] might be the most important one you [28:25] develop not only during the build but [28:27] also as a founder when you build your [28:30] venture along the way. So focus grace [28:35] momentum every no you say protects the [28:38] one yes that actually matters during [28:41] this the bill. [28:44] Um so uh that so what happened to me [28:48] after the build like uh so what happened [28:52] after the 48 hour buildaton so the [28:55] prototype became up global on AI power [28:58] financial health for migrant workers I [29:01] kept building and uh we focus on [29:04] financial inclusion we will have [29:06] structure test for our on our of our [29:09] platform with migrant communities this [29:12] summer we build with AI assisted um [29:16] development and we are moving from an [29:18] idea to real world validation. Um so the [29:21] point is I I want I the point I want you [29:25] to leave you with is the bill is the [29:29] starting light really. So um yeah it's [29:32] the starting of your real venture. You [29:35] should treat it that way and it's not [29:37] the finish line when the bill is over. [29:39] It's it's not over. It's just the start [29:41] of your real venture later on. So what [29:44] you build this time is the beginning of [29:46] something much bigger. Think it that way [29:50] and I know it was true for at least for [29:53] me and for many of CU's alumni that I [29:56] that I know of. [29:59] Um so this is the practical takeaway or [30:02] checklist to plan during 48 hours before [30:06] the 48 hour view. Everything we cover [30:09] here on one spring. So one define the [30:13] problem to talk to at least three real [30:15] users, three Q features and protect the [30:18] one feature that must work. Four, write [30:22] a onepage PR. Five, prepare a resumeable [30:26] from library. Six, recruit some tester [30:30] with a feedback form. Seven, design a p [30:33] problem solution demo in five hours. And [30:36] eight, remember to sleep. protect your [30:39] energy because sleep is a competitive [30:43] advantage. If you do these eight thing [30:46] before the clock starts, you will walk [30:49] away. You you will walk into the build [30:51] button much came clearer and so much [30:55] more likely to build something that will [30:57] land [30:59] for you and yeah something might be much [31:03] bigger awaiting after the bill for you. [31:06] So if you find this useful, screenshot [31:08] it or just DM me later on LinkedIn and u [31:11] I do have a PDF checklist for this for [31:14] for easy printing. [31:17] So that's it. Thank you so much for [31:20] spending time with me today and uh I [31:23] will leave you with the three words [31:26] less, learn faster and ship earlier to [31:29] validate what you are going to build. If [31:32] any of those resonated with you, if you [31:34] are working on something in financial [31:37] inclusion, labor migration, AI model [31:39] development for social impact of fintech [31:42] for underserved communities, I would [31:44] like to connect um yeah, OK Globo is [31:48] still early and I'm always looking for [31:50] people who yeah who we can talk more [31:53] about uh the project. So anyway, just [31:56] scan the QR code for my LinkedIn and uh [31:59] just say you know me from this webinar [32:02] and I'm happy to connect and discuss [32:04] more. Thanks so much Hong. That was so [32:07] valuable. Um one of my biggest takeaways [32:10] for sure was that sleep is a competitive [32:12] advantage because I definitely did not [32:14] sleep when I was in season one and I [32:17] wish I would have. Um who knows what I [32:20] could have built better then. But we [32:22] have we're a little over time. if you're [32:24] still here hanging out with us, we [32:26] appreciate it. So, we're just going to [32:27] have to um one one or two quick [32:30] questions. If you have any more, feel [32:32] free to connect with Hong um or throw it [32:34] in the disc Discord channel and I'm sure [32:36] we can talk there. But, um one of them [32:40] was um how long have you been working on [32:43] your project, Tom Hong? [32:45] >> Uh do you mean before or after the bill? [32:50] I [32:52] >> I I actually I started working on it um [32:56] that project I think five years before I [32:59] work into that civil uh build to but but [33:03] of course like there was like three [33:05] years that I didn't really do work [33:07] anything on that project and then uh I [33:10] started um I restarted the project uh I [33:15] believe uh 6 months before December when [33:19] season 2 started. So, it was a while [33:23] that the idea kept haunting me because I [33:26] really don't know how to build it. Like, [33:28] I have the idea, but I don't know how to [33:30] build it. And then after the build in [33:33] December, so season 2 was during [33:35] December last year. After it, I I I'm [33:39] still working on it until now. And uh [33:41] the project it um uh we got some small [33:45] scholarship funding uh from university [33:49] and uh and and that's how I can manage [33:52] to work on it full-time during this [33:54] summer. [33:55] >> That's amazing. Huh. Congratulations for [33:58] that and I'm so excited to see what you [34:00] get to do with that opportunity. So it [34:02] sounds like she builds not only gave you [34:03] the opportunity to build but to continue [34:05] and expand outside your build. So, if [34:08] you're out there not sure if you can do [34:10] it or not sure if the 48 hours is [34:13] enough, it it definitely is because you [34:16] can see what Hong is doing is pretty [34:18] amazing. Um, well, we're over on time. [34:21] I'm sorry we didn't get to all the [34:22] questions, but like I said, feel free to [34:24] connect with Hong and connect in our [34:27] Discord. Let's start talking about [34:28] ideas, ask questions in there, start [34:30] making some friends. So then that way [34:32] when we start building um during the [34:35] hackathon or the buildathon we can all [34:37] start coming together to support each [34:38] other. So hung thank you again so much [34:42] and we have our next session here within [34:44] the next half hour 20 minutes. So I hope [34:48] to see all of you in there. [34:50] >> Thank you so much Emily and thank you [34:52] everyone. [34:53] >> Thank you.  📄 **Full text:** ![[Full Document Contents/Articles/How to Use 48 Hours Before the Hackathon.md|How to Use 48 Hours Before the Hackathon by YouTube]] ## Highlights - so. And uh we all know that AI nowadays and tools like loveable book already can help us to do the coding faster than any of us here. Um and what I want to share with you today is more about how to use the 48 hours before the build button wisely. Um yeah, it just a way to um to play with the workings here like you going to have 48 hour to build. So how ([View Highlight](https://read.readwise.io/read/01kv8bfae8pp6t57x8e34s4np5)) - Tags: 👻 ai highlighted - building today and I'm still working on it um full-time during this summer as well. Um and here's the thing I want to uh you to take away from uh from our sharing today. um that uh the biggest challenge was never the code during this buildaton. Um it was more about making good decisions under time pressures. Remember you only have 48 hours to build ([View Highlight](https://read.readwise.io/read/01kv8ab3htwqkrvd81whtdz7ny)) - Tags: atom/literature/h1, hackathon, decision-making - the big life decisions. Should I stay in this country? Should I go home? Should I renovate my family's house at home first or pay off the debt first? Should I save or invest? And for every one of those question, a deep why and how underlying with it. So, one honest conversation with a real user can save you a 100 hours of building the wrong thing later ([View Highlight](https://read.readwise.io/read/01kv8abj57ve08pzkzz803bk98)) - Note: "One honest conversation with a real user can save you 100 hours of building the wrong thing later." Talking to a real person about their actual decisions beats more building time. - Tags: atom/literature/h1, user-research, hackathon - one page B product requirement document. Um so this is your secret weapon and I mean that a brces you to think before you view and here's the hidden benefit. It dramatically improve what AI generate for you because the AI inherit your clarity. If you are thinking if your thinking is FG your ROMs will be FG as well and your output will be like unclear and as well. So keep it to five ([View Highlight](https://read.readwise.io/read/01kv8abbc7mebm27dgvp6eph5w)) - Note: A one-page PRD is the secret weapon: it forces you to think first, and "the AI inherits your clarity." Fuzzy thinking → fuzzy prompts → fuzzy output. Clear upfront spec directly improves AI-generated results. - Tags: atom/literature/h1, ai-output, hackathon ## Links - [[3. Resources/Permanent Notes/Data-Model-First Releases Reduce Decision Coupling]] — extends: a short PRD and one real-user conversation move consequential decisions ahead of rapid implementation. - [[3. Resources/Permanent Notes/The Bottleneck Moved From Code Generation to Review and Judgment]] — evidence-for: once code is fast, deciding what deserves to be built becomes the scarce work.