Contributing to No-Code Architects Toolkit

Thanks for your interest in contributing! ❤️

This project exists to help non-technical creators build smarter systems — so every contribution should align with these core principles:

✅ Simple ✅ Useful ✅ Low-maintenance

This repository is focused on new contributions and feature development. Please ensure all pull requests contain complete, debugged code that is ready for review. We do not accept submissions that require significant cleanup, completion work, or debugging by maintainers.

If you like the project but don't know how to code, you can still support us in other ways:

• ⭐ Star the project
• 📣 Share it on social media
• 🌲 Refer it to a friend or your community
• 💸 Sponsor the project

If you need help or have questions, check out the GitHub discussions or join the community.

---

Table of Contents

• What We Accept
• What We Reject
• Feature Evaluation Framework
• Technical Guidelines
• Contribution Types
• Branch Naming Conventions
• Final Thoughts

---

What We Accept ✅

• Solves common no-code challenges
• Reduces cost or replaces paid APIs/tools
• Requires minimal input (has defaults)
• Is understandable by non-technical users
• Works out-of-the-box, no setup required
• One-time integrations — no constant maintenance needed
• Uses existing input/output naming conventions
• Follows our directory and structure conventions

---

What We Reject ❌

• Features built for one person or edge-case
• Inconsistent input/output field names
• Requires polling, retries, or callback logic
• Needs babysitting or breaks frequently
• Lacks error handling or code comments
• Includes unused code, requirements, or bloat
• Adds huge packages that inflate Docker image size
• Leaves us with more work to do

---

Feature Evaluation Framework

Category	Ask This...	✅ Accept if...	❌ Reject if...
Mission Fit	Does this reduce cost or unify tools?	Replaces APIs, reduces costs or complexity	Adds noise or solves narrow edge cases
Input Familiarity	Are inputs familiar (file_url, text, etc)?	Uses standard names/types already in use	Introduces new terms for same ideas
Input Clarity	Would a non-tech user know what to enter?	Inputs like "Enter URL", "Choose format"	Needs tech explanation or experimentation
Output Usefulness	Can this plug straight into Make/Zapier?	Returns clean files, text, URLs	Returns raw data or deep nested structures
Reliability	Will it just work?	API is stable, no retries, consistent behavior	Depends on flaky APIs or fragile setup
Maintenance Cost	Will we have to maintain this?	One-and-done, doesn't change often	Vendor changes often, breaks silently
Value vs. Effort	Is it worth it?	High impact, frequently requested	Niche, low ROI

---

Technical Guidelines

These guidelines help maintain a clean and production-ready project.

🧠 Code Style

• Use clear, descriptive names (e.g., convertImageToText, not imgTxt)
• Comment your logic if it's not obvious
• Handle errors — don't let code crash silently
• Follow consistent formatting

🧼 Clean Contributions

• Don't change files unrelated to your feature
• Don't leave behind unused requirements or code
• Don't introduce huge dependencies (we check image size)
• Use git status to review your working tree before you commit

---

Branch Naming Conventions

All contributions should follow this process:

1. Fork the main repository
2. Clone your fork:

   git clone https://github.com/YOUR_USERNAME/no-code-architects-toolkit.git
   cd no-code-architects-toolkit

3. Add the upstream repository:

   git remote add upstream https://github.com/stephengpope/no-code-architects-toolkit.git

4. Fetch and checkout the upstream build branch:

   git fetch upstream
   git checkout -b your-feature-branch upstream/build

5. Name your feature branch following these patterns:
   • For bug fixes: fix/descriptive-bug-name
   • For new features: feature/descriptive-feature-name
   • For documentation: docs/descriptive-change

Example:

# For a new feature
git fetch upstream
git checkout -b feature/pdf-to-text-converter upstream/build

# For a bug fix
git fetch upstream
git checkout -b fix/webp-upload-crash upstream/build

6. After making your changes, push to your fork and create a pull request:

   git push origin your-feature-branch

   Then visit your fork on GitHub and create a pull request targeting the build branch of the main repository.

---

Contribution Types

Type	Good Example
🐞 Bug Fix	"Fixes crash when uploading WebP files"
⚡ Feature	"Adds endpoint to replace an expensive api"
📚 Docs	"Improves deployment documentation (e.g., how to host on Netlify, AWS, Vercel, etc.)"

---

Final Thoughts 🧘‍♂️

• If it's not ready, don't submit it.
• Contributions should be helpful, obvious, and low-maintenance.
• The goal: make complex tasks simple for no-code users.

We're excited to see your contributions! 🎉

Let's build something useful, together.