Skip to main content
The Digital Alchemy Vault grows stronger when builders contribute back to the community. Whether you’re creating custom blueprints, helping others debug, or improving documentation, your contributions make the vault more valuable for everyone.
You don’t need to be an expert to contribute. Some of the most valuable contributions come from beginners who remember what it’s like to be stuck.

​
Ways to Contribute

Share Custom Blueprints

Create and share original blueprints or adapted versions of existing ones for new niches

Help in Vibe Coding Help

Answer technical questions and help builders get unstuck on their projects

Share Your Apps

Post deployed apps in Ship It Showcase to inspire others and demonstrate what’s possible

Join Challenges

Participate in Blueprint Challenges and share your unique approaches

Improve Documentation

Suggest documentation improvements or clarifications when something is unclear

Build Partnerships

Mentor newer builders or form study groups in Build Partners

​
Contributing Custom Blueprints

Sharing custom blueprints in Blueprint Lab is one of the highest-value contributions you can make.

​
What Makes a Great Blueprint Contribution

1

Solves a Real Problem

The best blueprints address actual pain points in specific niches. Build something you or someone you know would actually use.
2

Follows the Template

Use the 8-section blueprint template format so your blueprint is consistent with the vault library.
3

Includes All Complexity Levels

Provide starter prompts for Beginner, Intermediate, and Advanced builders so everyone can build at their level.
4

Tested and Working

Build at least the Beginner version yourself before sharing. Include a live URL as proof of concept.
5

Clear and Specific

Be explicit about features, user flow, and design direction. Vague blueprints lead to frustration.
Use the Blueprint Builder to generate your custom blueprint, then refine it based on your actual build experience.

​
Blueprint Contribution Template

When sharing a custom blueprint in Blueprint Lab, use this format: 
**Blueprint Code:** [NEW if original, or HW-01-ADAPTED if modified]
**App Name:** [What did you call it?]
**Niche:** [Who is this for?]
**Original Blueprint:** [If adapted from existing blueprint]

**What I Built/Changed:**
[Brief description of your blueprint or how you adapted an existing one]

**Link or Paste:**
[Link to blueprint document or paste the full blueprint content]

**Live Demo:**
[URL to your deployed version, if available]

**Feedback I'm Looking For:**
[Specific questions for the community]
See the Blueprint Lab guide for detailed submission instructions.

​
Helping in Vibe Coding Help

Answering questions in Vibe Coding Help strengthens the community and solidifies your own knowledge.

​
How to Give Great Technical Help

Ask Clarifying Questions

If the problem isn’t clear, ask for error messages, screenshots, or specific steps to reproduce

Share Your Thinking

Explain why something works, not just what to do. Teaching the concept helps more than copy-paste solutions

Reference Resources

Point to relevant Flash Modules, Ship It steps, or documentation that explains the concept

Test Before Suggesting

If you’re not certain, say so. “I think this might work” is better than confidently wrong advice

Celebrate Progress

When someone solves their issue, acknowledge it. “Nice work figuring that out!” keeps morale high

Know When to Escalate

If you can’t help, that’s okay. Tag DESI or suggest the builder post their full code for deeper review
You don’t need to be an expert to help. Sometimes a fresh perspective or “I had that same issue yesterday” is exactly what someone needs.

​
What Not to Do

  • Don’t say “it works on my machine” without trying to help debug
  • Don’t suggest complex solutions when simple ones exist
  • Don’t criticize someone’s code or approach — focus on solving the problem
  • Don’t leave people hanging — if you start helping, follow through or let someone else take over

​
Contributing to Documentation

If you find documentation that’s unclear, outdated, or missing, you can help improve it.

​
How to Suggest Documentation Improvements

1

Identify the Issue

What page is unclear? What information is missing? Be specific about what confused you.
2

Suggest the Fix

What would have helped you understand better? Propose specific language or examples.
3

Post in General Discussion

Share your documentation feedback in the Skool General Discussion category with the tag [DOCS].
4

Include Context

Share where you were in your journey when you hit the confusion. “As a beginner trying to deploy for the first time…” helps contextualize the feedback.
The best documentation improvements come from people who just learned something. If you figured out something confusing, your fresh understanding can help others avoid the same struggle.

​
Mentoring and Partnering

Experienced builders can give back by mentoring newer members or forming partnerships.

​
Ways to Mentor

Offer Build Partners Sessions

Post in Build Partners offering to pair up with beginners on their first builds

Run Informal Office Hours

Schedule a recurring time when you’re available in Vibe Coding Help for live questions

Create Tutorial Content

Record a Loom walkthrough of how you solved a tricky problem and share it in the community

Review Showcase Posts

Leave thoughtful feedback on Ship It Showcase posts, especially from first-time shippers

​
Mentorship Guidelines

  • Meet people where they are — adjust your explanations to their experience level
  • Encourage experimentation — “try changing this and see what happens” builds intuition
  • Celebrate small wins — deploying “Hello World” is a huge milestone for a beginner
  • Share your own struggles — “I spent 3 hours debugging this same thing” normalizes the learning process
  • Set boundaries — it’s okay to say “I can help with this specific question, but beyond that you’ll need to post in Vibe Coding Help”

​
Recognition for Contributors

Contributors who consistently give back to the community receive recognition:

​
Community Recognition

  • Exceptional blueprints may be added to the official Blueprint Index
  • Top helpers in Vibe Coding Help get acknowledged in weekly newsletters
  • Mentor contributions factor into App of the Week’s “Community” criterion
  • Frequent contributors may be invited to co-host or guest in live classes

​
Building Your Reputation

Every contribution you make:
  • Builds your credibility in the community
  • Demonstrates your expertise to potential clients or collaborators
  • Creates a public record of your knowledge and generosity
  • Strengthens the network that supports your own growth
The builders who grow fastest aren’t the lone wolves — they’re the ones who share their knowledge generously and lift others up.

​
Contribution Etiquette

​
Do This

  • Credit others — if you adapted someone’s blueprint or used their solution, acknowledge them
  • Be humble — “here’s what worked for me” beats “you should do it this way”
  • Stay current — if you share a solution, make sure it still works with current tools and practices
  • Accept feedback — if someone suggests an improvement to your contribution, consider it gracefully
  • Follow up — if you help someone, check back in a day or two to see if your solution worked

​
Don’t Do This

  • Don’t gatekeep — “you should have read the docs” doesn’t help anyone
  • Don’t claim ownership — blueprints and solutions shared here belong to the community
  • Don’t promote paid products — unless explicitly allowed by DESI, keep contributions free and open
  • Don’t spam — one well-crafted contribution beats ten rushed ones

​
Getting Started as a Contributor

Not sure where to start? Try this progression:
1

Week 1: Ship and Share

Complete your first app and post it in Ship It Showcase. This establishes you as someone who builds.
2

Week 2: Help One Person

Answer one question in Vibe Coding Help or leave thoughtful feedback on one showcase post.
3

Week 3: Complete a Challenge

Submit an entry to the Blueprint Challenge and share your unique approach in your submission.
4

Week 4: Share Your Process

Post in Blueprint Lab about how you adapted a blueprint or share a mini-tutorial on something you figured out.
5

Ongoing: Make It a Habit

Set a goal: “Every time I ship an app, I’ll leave feedback on one other person’s showcase post.” Small, consistent contributions compound.
Contribution doesn’t require extra time. Make it part of your existing workflow: when you solve a problem, share the solution. When you build an app, share the code. When you learn something, teach it.

​
Questions About Contributing?

If you’re not sure whether something is a good contribution or how to share it:
  • Post in General Discussion with your question
  • DM DESI directly through Skool
  • Ask in the next live class during Q&A
  • Look at past contributions in Blueprint Lab for examples
When in doubt, share it. The worst that happens is someone says “this belongs in a different channel” — but more likely, you’ll help someone who needed exactly what you shared.

​
Next Steps

Blueprint Lab

Start contributing by sharing a custom blueprint

Ship It Showcase

Share your deployed apps to inspire others

Blueprint Challenges

Join weekly challenges and demonstrate your skills

Community Overview

Explore all community channels and find your place

Build docs developers (and LLMs) love

Get started for freeTalk to us