What do you have against TODO-lists? IMHO the world needs more varieties of task management tools.
Actually, the example apps don't really do the platform justice. We (at deployd) use it in consulting projects for building big APIs with complex roles and business requirements. The design of deployd is driven more from lessons learned designing those APIs than from our experiments in TODO-lists.
(I work at deployd) Yes, it's perfect for prototyping. We use it extensively for prototyping on projects where the ultimate API has to be supported in another stack. Saves tons of time compared to developing the API as you go in Java or the like.
(I work at deployd) Yes, the cycle is funny. We don't usually focus on the GUI when talking about deployd; someone outside the company posted with this headline.
Open source was a no-brainer for us. There are some other key concepts that make it a compelling tool, particularly how easily extensible the platform is.
Jeff, has deployd considered adopting a JSON-based media type like Collection+JSON or HAL or JSON-LD (and there are others, or you could roll your own) so that the JSON APIs are properly RESTful?
(I work at Deployd) Our goal is first and foremost to generate useful APIs that you can use in your front-end, not necessarily to strictly adhere to the REST pattern. We do tend to use REST terminology when describing Deployd, and maybe that's a mistake that's causing more distraction than necessary.
This is one of my biggest issues with a lot of the projects being posted lately - they look great but I don't know the tech stack until I finally look at the code. Would be great if people at least mention if their project requires node.js, ruby or what not on their homepage.
(I work at Deployd) From our perspective, one of our ultimate goals is to create a platform where the tech stack doesn't matter to the user. We've partially solved this with the Mac/Windows installer - it installs Node.js and MongoDB dependencies itself. That way, you don't need to know the stack unless you're developing extensions (which are node modules).
However, I do agree that we need to document the stack better for those that want to install from source, or host it themselves.
When you guys have time do you think you could have install instructions for my own env. Or are the instructions for installing from source at the bottom all I need?
If you're on Mac or Windows, it's easiest to use the installer. Otherwise (or if you just want to do it yourself), the "install from source" instructions are enough; you'll need both node.js and MongoDB in your PATH.
Not an untypical predicament you're in. Best advice is to minimize features and release something to someone asap. That takes a lot of discipline to do, but starting simple and iterating has lots of benefits. Just a few:
1. Instant feedback, so you can validate your assumptions about the product. (see: Lean Startup, Eric Ries)
2. It's easier to keep releasing once you've already released.
3. With a simple, limited feature set, your product is easier to understand to your early adopters.
Actually, the example apps don't really do the platform justice. We (at deployd) use it in consulting projects for building big APIs with complex roles and business requirements. The design of deployd is driven more from lessons learned designing those APIs than from our experiments in TODO-lists.