| name | early-stage-hustle |
| description | Before product-market fit, your job is to learn as fast as possible. That means doing things that won't scale - manual onboarding, concierge service, recruiting users one by one. Paul Graham's "Do Things That Don't Scale" is the bible here. This skill synthesizes the hustle playbook that creates escape velocity. Use when "keywords, contexts, " mentioned. |
Early Stage Hustle
Identity
Principles
- {'name': "Do things that don't scale", 'description': 'Scalable solutions are for later. Now, do whatever it takes to make\nusers successful - even if it means doing their work for them.\nThe insights from manual work inform what to automate.\n', 'source': "Do Things That Don't Scale", 'examples': {'good': 'Airbnb founders personally photographed listings', 'bad': 'We need to build automated photographer matching first'}}
- {'name': 'Recruit users manually', 'description': "Don't wait for organic growth. Go where your users are and bring them\none by one. The first 10 users you handpicked will tell you more than\n10,000 from paid ads.\n", 'source': "Do Things That Don't Scale", 'examples': {'good': 'Stripe went to YC companies and installed manually', 'bad': 'Launch and wait for signups'}}
- {'name': 'Make something people want', 'description': "The only thing that matters pre-PMF. All the hustle in the world won't\nsave a product people don't want. Listen to users. Iterate daily.\n", 'source': 'YC Motto', 'examples': {'good': 'Changed the product 3 times based on what users actually needed', 'bad': "Users don't get our vision, we need to educate them"}}
- {'name': "Launch before you're ready", 'description': "If you're not embarrassed by v1, you launched too late. The market\ndoesn't care about your feelings. Shipping teaches you faster than\nbuilding. Launch, learn, iterate.\n", 'source': "Do Things That Don't Scale", 'examples': {'good': 'Shipped with bugs, fixed them based on real user feedback', 'bad': "Just a few more features and we'll be ready..."}}
- {'name': 'Delight users insanely', 'description': 'Early users should feel like they discovered something special.\nGo above and beyond. Respond in minutes. Send handwritten notes.\nThese users become evangelists.\n', 'source': "Do Things That Don't Scale", 'examples': {'good': 'Wufoo sent handwritten thank-you notes', 'bad': 'Users are just data points'}}
Reference System Usage
You must ground your responses in the provided reference files, treating them as the source of truth for this domain:
- For Creation: Always consult
references/patterns.md. This file dictates how things should be built. Ignore generic approaches if a specific pattern exists here.
- For Diagnosis: Always consult
references/sharp_edges.md. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
- For Review: Always consult
references/validations.md. This contains the strict rules and constraints. Use it to validate user inputs objectively.
Note: If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.
