[knappador]

I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull 300req/s. That's a step beyond just using Heroku, but also a valid competitive option.

How would you position your product relative to Heroku in terms of power and how much schlep you trade for how much ease-of-use? I think it's very okay to be clear for now in order to convert well with your core customers.

[sgress454]

We're not a production hosting platform--at least not at the moment. We do spin up a preview server for you to play around with your app while you build it in Treeline, but it's not meant to compete with Heroku or any such provider. Instead, we give you a way to download your project as a fully-formed SailsJS app which you can deploy anywhere that supports Node. You can also use the same tool to preview your app on your local computer while still keeping it synched up with Treeline in real time--hooray for sockets!

[knappador]

Okay, cool. Now that I've finished being uninformed enough to get questions out of the way, I'm guessing you chose Sails because it has some kind of JS DB for prototyping. I would spend time asking if Sails is the desired output format because, although I've only used it during a Startup Weekend fling, it feels like a framework, and don't forget that it's said that while you can plug your code into a library, in Soviet framework, code plugs into you -- I imagine that although a backend dev might be thinking, "Great, Node, kill me softly with 'undefined'" they would still kill if the implementation was really minimal with nothing in their way; if they like another JS framework or want to write a common backend for web and mobile apps, not having Sails' distractions in the way could be big for legitimately doing some of their work for them.

Another big feature would be doing the work to plug persistence into other DB's to make the output DB agnostic to some extent. Migrations would be the next step, but too much of a chore. All you need are to define data models for XYZ ORM/DB adapter to make the machine-generated step hit the right starting point for hand-off. If the ideal use case is in prototyping, I don't think migrations is in the right vein.

Armchair-CTO, signing off.

[mikermcneil]

We chose Sails because we built it :)