Your app appears to be far more mature than your ability to explain the app. The hard part at this point is getting users to adopt your product, so focus on th

Your app appears to be far more mature than your ability to explain the app. The hard part at this point is getting users to adopt your product, so focus on that. The challenge of getting users to adopt a product like this isn't being cheap or buzzword compliant, it's demonstrating that if they invest enough time to learn your product, it will be able to do the specific things they need to do. The potential user's time investment is the biggest cost they are considering when deciding which low-code/no-code product to adopt. If they invest time in a product that can't do what they need, 100% of their time learning to use that system and trying to build their app is wasted Your non-GitHub website is mostly a content-free zone, full of generic discussion of the benefits of low-code/no-code. There aren't even any screenshots I could find. The GitHub readme has more details and screenshots, but again it's mostly generic virtues of good low-code/no-code with some intriguing screenshots buried deep in a very long page, with no answers to "how do I make an app that does X with this?" Walk visitors through how to create a basic multi-user todo list task tracking app, with a database, integrated into a multi-user sign in and auth setup, back up the database, and then perform a database migration to add a field or table to the database. That hello-world example will show visitors the details of how your app works, what it can and can't do, and whether it will work for their needs. Communicating what a new product does is as hard or harder than making the product in the first place. Writing more code doesn't solve the communicating/marketing/advertising problem. That human-facing piece needs real, focused work with as much attention to detail as the code receives. If devs choose to submit PRs to your product, they will do so after first trying to adopt your product as end users, so even if your goal is getting more devs involved, you still want to focus on communicating to end users the details they need to know to decide whether your specific product will solve their specific low-code/no-code needs.