4 ms·

Ask HN: Looking for feedback on SaaS boilerplate

12 points by tima101 8y ago

I've recently built and published open source SaaS boilerplate with React/Next/Express/TypeScript. Currently, over 2000 people tried the demo and about the same number of people cloned repo. But so far, I did not receive much feedback. If you are in the early stage of building your SaaS web application or looking for stack/boilerplate - what would you add or subtract from our SaaS boilerplate. Github repo: https://github.com/async-labs/saas Any feedback on the README file?

tsongas 8y ago
Cool idea and an awesome effort! I've been a mentor for Thinkful (an online code school) for five years and have helped students build many, many MVPs so lots of experience in the trenches helping beginners build new projects. I mostly like your choices. Using full-stack JavaScript is excellent, only one language across client and server. I also like the use of Next and MobX to simplify things like routing and state management. Node and Express are also solid choices, however the use of Mongo is a recipe for disaster. Mongo has a very narrow use case, and it does not include storing relational data for a SaaS business. Compounding that problem is a poorly designed schema that at first glance stuffs everything into one massive user document. While this back-end implementation obviously works, it will lead to problems down the road that could just as easily be avoided by using Postgres and Knex for your database and migrations, and Objection for your models...a very straightforward setup. The one other piece of feedback I have is that while I haven't used TypeScript, I'd say it adds a layer of complexity that isn't needed in an MVP. I'd be happy to discuss further and am eager to learn more about why you built this and how you're using it! Also curious if you're based in Seattle? I was born there and love that city....
ryanmccullagh 8y ago
Mobile friendly https://github.com/async-labs/saas https://github.com/async-labs/saas
tixocloud 8y ago
Hey there, do you know anything about those users who have tried the demo? We have a SaaS but when thinking about whether we would use your boilerplate, the honest answer is I wouldn’t because I’d have to learn the tech stack that you’ve decided for me. That’s a big learning curve than rolling out with something I’m familiar with. If you have a boilerplate that limits tech to a few and simplifies the learning curve, there might be a bigger interest. Or you can go down the route of creating a UI version where non-developers can configure their own SaaS app for building an MVP, which would be useful just to validate ideas, raise funding and hire someone to fix it.
- tima101 8y ago
  Thanks for the comment. Valid point. It encourages me to write tutorials to shorten the learning curve. Building a tool for non-developers is too much effort for me. I should mention that some parts of the stack, say MobX, has a shorter learning curve, in my opinion, than an alternative, Redux. I tried a bunch of tool from JS world, this stack, once learned, is easily manageable by really small technical teams (1-3 people). Overall, I am from the camp "whatever works, customers don't care about stack". Just posted to HN to see if something is not clear in the README or some features can be added/removed from boilerplate. EDIT: I did not answer your question. Majority of signups at the demo app is web development agencies and freelancers.
  - tixocloud 8y ago
    Think this would be good to include in your README - about why you chose the tools. Also reach out to those signups and ask them what would it take to get them to really use it for their own projects. What’s holding them back, etc.

12 points by tima101 8y ago

tsongas 8y ago

Cool idea and an awesome effort! I've been a mentor for Thinkful (an online code school) for five years and have helped students build many, many MVPs so lots of experience in the trenches helping beginners build new projects. I mostly like your choices. Using full-stack JavaScript is excellent, only one language across client and server. I also like the use of Next and MobX to simplify things like routing and state management. Node and Express are also solid choices, however the use of Mongo is a recipe for disaster. Mongo has a very narrow use case, and it does not include storing relational data for a SaaS business. Compounding that problem is a poorly designed schema that at first glance stuffs everything into one massive user document. While this back-end implementation obviously works, it will lead to problems down the road that could just as easily be avoided by using Postgres and Knex for your database and migrations, and Objection for your models...a very straightforward setup. The one other piece of feedback I have is that while I haven't used TypeScript, I'd say it adds a layer of complexity that isn't needed in an MVP. I'd be happy to discuss further and am eager to learn more about why you built this and how you're using it! Also curious if you're based in Seattle? I was born there and love that city....

ryanmccullagh 8y ago

Mobile friendly https://github.com/async-labs/saas https://github.com/async-labs/saas

tixocloud 8y ago

Hey there, do you know anything about those users who have tried the demo? We have a SaaS but when thinking about whether we would use your boilerplate, the honest answer is I wouldn’t because I’d have to learn the tech stack that you’ve decided for me. That’s a big learning curve than rolling out with something I’m familiar with. If you have a boilerplate that limits tech to a few and simplifies the learning curve, there might be a bigger interest. Or you can go down the route of creating a UI version where non-developers can configure their own SaaS app for building an MVP, which would be useful just to validate ideas, raise funding and hire someone to fix it.

tima101 8y ago
Thanks for the comment. Valid point. It encourages me to write tutorials to shorten the learning curve. Building a tool for non-developers is too much effort for me. I should mention that some parts of the stack, say MobX, has a shorter learning curve, in my opinion, than an alternative, Redux. I tried a bunch of tool from JS world, this stack, once learned, is easily manageable by really small technical teams (1-3 people). Overall, I am from the camp "whatever works, customers don't care about stack". Just posted to HN to see if something is not clear in the README or some features can be added/removed from boilerplate. EDIT: I did not answer your question. Majority of signups at the demo app is web development agencies and freelancers.
- tixocloud 8y ago
  Think this would be good to include in your README - about why you chose the tools. Also reach out to those signups and ask them what would it take to get them to really use it for their own projects. What’s holding them back, etc.