8 ms·

Frankly, I always find these stories miraculous. Even though I'm a full-time web developer, I find it daunting merely to design a landing page with user sign-up

Frankly, I always find these stories miraculous. Even though I'm a full-time web developer, I find it daunting merely to design a landing page with user sign-up, let alone a feature worth paying for and an account subscription flow. There's just so much to do. It seems like years of work. I know there's things like SaaS pegasus, but that forces Django. SaaS Pegasus and Bullet Train are also very expensive with no real options for trial. I wish tools like that - automating the basics of an ecommerce business - were more developed and available, preferably open source in the long run. I feel like it's the future we're slowly moving towards but we aren't there yet. We have widely-used open source frameworks for technical foundations - rails, django, etc - but no higher-abstraction equivalent that handles "features" like subscriptions and accounts. It is infinitely easier to build and deploy things in 2020 than it was in 2010, and I'm hoping the time between now and 2030 represents a similar jump. edit: found this list though https://github.com/smirnov-am/awesome-saas-boilerplates https://github.com/smirnov-am/awesome-saas-boilerplates

rockbruno 5y ago
I think the key is having at least something done. Nowadays, most of my new projects are done by copy pasting things I've done in previous ones. This reduces the time spent setting things up considerably.
joemasilotti 5y ago
I didn't build this app on it, but if I did it again I would probably use Jumpstart. https://jumpstartrails.com https://jumpstartrails.com There's also an open source version that handles a good chunk of the stuff needed to get a Rails saas up and running.
- weaksauce 5y ago
  yeah I was going to plug that too... the open source one handles a basic devise, admin backend and some other things. the pay one adds stripe and payments and stuff like that. but the open source one is really nice for hitting the ground running
DanHulton 5y ago
I mean, it is years of work, speaking from experience. I make a similar tool (but for Node.js/Vue, if you're not a fan of Django), and it took around two years to get it to where it is, with user account creation/management, subscriptions, teams, admin dashboard, scripting, etc. I'm definitely not charging as much as Bullet Train, but also I feel fully justified in charging instead of open sourcing it. It's been my sole serious side-project for years now after all. The problem for trials of stuff like this, is that you have no real way of enforcing it. You just have to hope that trialers feel like doing the right thing and paying if they continue to use it, because trying to recover a few hundred dollars through legal means is just not worth the time and money you'd have to spend. In the end, I settled on a 60-day money-back guarantee, and I've already issued a few already, to folks who thought it had a feature it didn't yet, or ended up not pursuing their idea, etc, so it seems to work pretty well.
- eloff 5y ago
  You missed a great opportunity to plug your product on HN, give us a name and a link :)
  - ZhangSWEFAANG 5y ago
    nodewood.com
loh 5y ago
This is exactly why I built Molecule.dev. It's brand new, using all the latest and greatest battle-tested tools. I started it because I recognized that it took entirely too long to implement some of the most basic core functionality for cross-platform apps in a way that is up to my standards (i.e., minimal with no real vendor lock-in). It actually boggles my mind that nothing of the same quality as Molecule.dev exists yet. It's obviously a problem that developers everywhere run into when building custom apps. I've seen a few solutions, but (again) they're all either not up to my standards or they try to lock you in. I think most developers prefer to implement things themselves, as they have their own preferences and may (like me) not trust that the code quality is up to their standards, so the difficult part here may actually be to convince developers that the code is high quality and something they themselves would write.
- tomrod 5y ago
  Interesting. If I did my math right, you have 917,294,284,800 combinations of configuration available, not counting the "other" option in each category. That's a lot! Most are coming from things like the deployment OS (720 options since you aren't limited to only one choice).
  - loh 5y ago
    I've never considered all the different combinations, but it is definitely quite a lot of work, and I'm planning on adding more. My goal with this is to help developers and teams of any level, from beginners to experts, quickly get started building the highest quality product(s) they possibly can. I want to raise the bar and eventually set a new standard of DX and UX for both developers and end users.
- amackera 5y ago
  How can something be both state-of-the-art and battle tested? I thought battle tested meant something more like "tried and true" (AKA not new). Cool product though!
  - loh 5y ago
godot 5y ago
As someone who has built and shipped lots of projects, both for work/startups as well as personal/side ones, I would say that most of the time with building/shipping products quickly, tons of corners are cut. It may not be obvious at first sight but you could see if you look for it. That's typically how one person can build and ship something in very short time. As a simple example, in HN, tech circles and the software engineering industry we talk about node, react, microservices, architecture design, etc. but when you're one person trying to ship a product, there's a high chance you're writing some basic HTML, jquery and some php backend, rather than a react SPA with SSR/SSG. (Not saying this is how OP did it, just in my experience how I and a lot of others did it) You're also right that it's infinitely easier to build and deploy things in 2020 than it was in 2010!
nickjj 5y ago
It does take a lot of time and experience to create these types of solutions. For example I put together https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/. It's a video course and SAAS example app that ties together a bunch of features. I've easily put in over 1,000 hours to create and update it over time. It's also been extracted from building multiple SAAS apps for clients (I do contract work). The way I look at it, it's paying $59 once to get a well tested code base that's going to save you 100+ hours of research and development. I also give lifetime updates and support along with refunds for up to 1 year. For context since I created it in 2015 I've re-recorded the course twice and continuously add a bunch of incremental updates. Every few months I go in and update things to their latest versions. Answered a countless number of questions too.
stanmancan 5y ago
Laravel is great in this regard. They have a number of first party packages like Laravel Spark that handle the heavy lifting of subscriptions, Laravel Nova that lets you spin up admin panels real fast, Forge for hosting... Highly recommend checking it out if you don’t mind PHP.
- synergy20 5y ago
  how do it compare to django? my experience with php was limited to some wordpress hacking.
  - veb 5y ago
    Laravel is pretty good. Spark definitely reminds me a lot of Django. https://spark.laravel.com/ https://spark.laravel.com/ I think nowadays you can use whatever frontend you want with it, where prior versions you had to use Vue (I think)
    - stanmancan 5y ago
      I haven't used Django so I can't comment about that. However, the latest Laravel Spark is now a totally separate part of your app that you don't control. It's super easy to implement, include the package, configure your packages and be done with that part of it. Then within your application you have a bunch of methods available on your billable object. I'm really not doing it much justice, but the docs are pretty short and easy to read through: https://spark.laravel.com/docs/1.x/spark-stripe/plans.html https://spark.laravel.com/docs/1.x/spark-stripe/plans.html
AlchemistCamp 5y ago
> I find it daunting merely to design a landing page with user sign-up, let alone a feature worth paying for and an account subscription flow. There's just so much to do. It seems like years of work. All of those things are built into Jumpstart Rails, which the author now uses. To be 100% honest, just using a highly productive framework like Rails, Laravel or, my personal favorite, Phoenix, goes a long ways towards making it quick to build all of those features. If you're experienced with a Rails-inspired fullstack framework, I'd say the work involved is closer to a week or two at most. Jumpstart gives you a sane default for that week or two of work.
amacneil 5y ago
> It is infinitely easier to build and deploy things in 2020 than it was in 2010, and I'm hoping the time between now and 2030 represents a similar jump. I'm not convinced that is true. At least if you compare 2012 with 2022, it was very easy to get a Rails app working, with user authentication/signup/password reset/etc (Devise), integrate Stripe for payments, deploy the whole thing on Heroku. It wasn't an overnight project, but one person could get that done in a few weeks of full time work. There was a lot of energy and excitement around this stack and the community often created "one good way" of doing things. In 2022, all those technologies are still available, but they are uncool and most of the internet will dissuade you from using them. Instead, unopinionated micro-frameworks are in vogue, and you you're down a rabbit hole creating the same product by gluing together dozens of libraries, writing a jamstack SPA, deploying the whole thing on kubernetes. You could easily spend several weeks just building out user signup flows, password reset, email templates, etc. I'm not saying it's all bad today: you can do much more with a SPA than you ever could with server side HTML + jquery, and back in the day when you hit a wall with Rails it was often extremely difficult to work around, whereas today's libraries are much more flexible. But for the happy path of "scaffold a functioning SaaS app", I definitely feel like it's harder to get started today than 10 years ago.
- AlchemistCamp 5y ago
  > At least if you compare 2012 with 2022, it was very easy to get a Rails app working, with user authentication/signup/password reset/etc (Devise), integrate Stripe for payments, deploy the whole thing on Heroku. It wasn't an overnight project, but one person could get that done in a few weeks of full time work. If you use Phoenix in 2022, you can generate authentication/signup/pasword reset/etc with a single command and the generator was written by the same person who created Devise back in 2010. You also get LiveView (and generators for it) that let you make apps with all the interactivity of a SPA. Oh, and there's a single line mix command to deploy a release of your app to fly.io! In short, things have become far easier for small teams and solo devs as long as they chose appropriate tools. Obviously it's going to be painful if you try to go it alone with the exact same tools a team of 30 or more would use. The same was just as true a decade ago.
didip 5y ago
What's even harder is product-market fit. I can blitz through building a basic SaaS product, but will it be worthwhile to: 1. Make enough money to replace $dayjob. 2. Make enough money to even cover the headache of supporting customers. 3. Make enough money to even cover the hosting cost.
2457013579 5y ago
Rastonbury 5y ago
It isn't! I started without any development experience and built an MVP in 3 weeks with user sign up, pricing and subscription using some getting started guides and stakoverflow. Not best practise or anything, I'm sure you laugh if you saw some of the code. Taking card payments was something I was worried about but Stripe has pretty good documentation for a layperson.

rockbruno 5y ago

I think the key is having at least something done. Nowadays, most of my new projects are done by copy pasting things I've done in previous ones. This reduces the time spent setting things up considerably.

joemasilotti 5y ago

I didn't build this app on it, but if I did it again I would probably use Jumpstart. https://jumpstartrails.com https://jumpstartrails.com There's also an open source version that handles a good chunk of the stuff needed to get a Rails saas up and running.

weaksauce 5y ago
yeah I was going to plug that too... the open source one handles a basic devise, admin backend and some other things. the pay one adds stripe and payments and stuff like that. but the open source one is really nice for hitting the ground running

DanHulton 5y ago

I mean, it is years of work, speaking from experience. I make a similar tool (but for Node.js/Vue, if you're not a fan of Django), and it took around two years to get it to where it is, with user account creation/management, subscriptions, teams, admin dashboard, scripting, etc. I'm definitely not charging as much as Bullet Train, but also I feel fully justified in charging instead of open sourcing it. It's been my sole serious side-project for years now after all. The problem for trials of stuff like this, is that you have no real way of enforcing it. You just have to hope that trialers feel like doing the right thing and paying if they continue to use it, because trying to recover a few hundred dollars through legal means is just not worth the time and money you'd have to spend. In the end, I settled on a 60-day money-back guarantee, and I've already issued a few already, to folks who thought it had a feature it didn't yet, or ended up not pursuing their idea, etc, so it seems to work pretty well.

eloff 5y ago
You missed a great opportunity to plug your product on HN, give us a name and a link :)
- ZhangSWEFAANG 5y ago
  nodewood.com

loh 5y ago

This is exactly why I built Molecule.dev. It's brand new, using all the latest and greatest battle-tested tools. I started it because I recognized that it took entirely too long to implement some of the most basic core functionality for cross-platform apps in a way that is up to my standards (i.e., minimal with no real vendor lock-in). It actually boggles my mind that nothing of the same quality as Molecule.dev exists yet. It's obviously a problem that developers everywhere run into when building custom apps. I've seen a few solutions, but (again) they're all either not up to my standards or they try to lock you in. I think most developers prefer to implement things themselves, as they have their own preferences and may (like me) not trust that the code quality is up to their standards, so the difficult part here may actually be to convince developers that the code is high quality and something they themselves would write.

tomrod 5y ago
Interesting. If I did my math right, you have 917,294,284,800 combinations of configuration available, not counting the "other" option in each category. That's a lot! Most are coming from things like the deployment OS (720 options since you aren't limited to only one choice).
- loh 5y ago
  I've never considered all the different combinations, but it is definitely quite a lot of work, and I'm planning on adding more. My goal with this is to help developers and teams of any level, from beginners to experts, quickly get started building the highest quality product(s) they possibly can. I want to raise the bar and eventually set a new standard of DX and UX for both developers and end users.
amackera 5y ago
How can something be both state-of-the-art and battle tested? I thought battle tested meant something more like "tried and true" (AKA not new). Cool product though!
- loh 5y ago

godot 5y ago

As someone who has built and shipped lots of projects, both for work/startups as well as personal/side ones, I would say that most of the time with building/shipping products quickly, tons of corners are cut. It may not be obvious at first sight but you could see if you look for it. That's typically how one person can build and ship something in very short time. As a simple example, in HN, tech circles and the software engineering industry we talk about node, react, microservices, architecture design, etc. but when you're one person trying to ship a product, there's a high chance you're writing some basic HTML, jquery and some php backend, rather than a react SPA with SSR/SSG. (Not saying this is how OP did it, just in my experience how I and a lot of others did it) You're also right that it's infinitely easier to build and deploy things in 2020 than it was in 2010!

nickjj 5y ago

It does take a lot of time and experience to create these types of solutions. For example I put together https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/. It's a video course and SAAS example app that ties together a bunch of features. I've easily put in over 1,000 hours to create and update it over time. It's also been extracted from building multiple SAAS apps for clients (I do contract work). The way I look at it, it's paying $59 once to get a well tested code base that's going to save you 100+ hours of research and development. I also give lifetime updates and support along with refunds for up to 1 year. For context since I created it in 2015 I've re-recorded the course twice and continuously add a bunch of incremental updates. Every few months I go in and update things to their latest versions. Answered a countless number of questions too.

stanmancan 5y ago

Laravel is great in this regard. They have a number of first party packages like Laravel Spark that handle the heavy lifting of subscriptions, Laravel Nova that lets you spin up admin panels real fast, Forge for hosting... Highly recommend checking it out if you don’t mind PHP.

synergy20 5y ago
how do it compare to django? my experience with php was limited to some wordpress hacking.
- veb 5y ago
  Laravel is pretty good. Spark definitely reminds me a lot of Django. https://spark.laravel.com/ https://spark.laravel.com/ I think nowadays you can use whatever frontend you want with it, where prior versions you had to use Vue (I think)
  - stanmancan 5y ago
    I haven't used Django so I can't comment about that. However, the latest Laravel Spark is now a totally separate part of your app that you don't control. It's super easy to implement, include the package, configure your packages and be done with that part of it. Then within your application you have a bunch of methods available on your billable object. I'm really not doing it much justice, but the docs are pretty short and easy to read through: https://spark.laravel.com/docs/1.x/spark-stripe/plans.html https://spark.laravel.com/docs/1.x/spark-stripe/plans.html

AlchemistCamp 5y ago

> I find it daunting merely to design a landing page with user sign-up, let alone a feature worth paying for and an account subscription flow. There's just so much to do. It seems like years of work. All of those things are built into Jumpstart Rails, which the author now uses. To be 100% honest, just using a highly productive framework like Rails, Laravel or, my personal favorite, Phoenix, goes a long ways towards making it quick to build all of those features. If you're experienced with a Rails-inspired fullstack framework, I'd say the work involved is closer to a week or two at most. Jumpstart gives you a sane default for that week or two of work.

amacneil 5y ago

> It is infinitely easier to build and deploy things in 2020 than it was in 2010, and I'm hoping the time between now and 2030 represents a similar jump. I'm not convinced that is true. At least if you compare 2012 with 2022, it was very easy to get a Rails app working, with user authentication/signup/password reset/etc (Devise), integrate Stripe for payments, deploy the whole thing on Heroku. It wasn't an overnight project, but one person could get that done in a few weeks of full time work. There was a lot of energy and excitement around this stack and the community often created "one good way" of doing things. In 2022, all those technologies are still available, but they are uncool and most of the internet will dissuade you from using them. Instead, unopinionated micro-frameworks are in vogue, and you you're down a rabbit hole creating the same product by gluing together dozens of libraries, writing a jamstack SPA, deploying the whole thing on kubernetes. You could easily spend several weeks just building out user signup flows, password reset, email templates, etc. I'm not saying it's all bad today: you can do much more with a SPA than you ever could with server side HTML + jquery, and back in the day when you hit a wall with Rails it was often extremely difficult to work around, whereas today's libraries are much more flexible. But for the happy path of "scaffold a functioning SaaS app", I definitely feel like it's harder to get started today than 10 years ago.

AlchemistCamp 5y ago
> At least if you compare 2012 with 2022, it was very easy to get a Rails app working, with user authentication/signup/password reset/etc (Devise), integrate Stripe for payments, deploy the whole thing on Heroku. It wasn't an overnight project, but one person could get that done in a few weeks of full time work. If you use Phoenix in 2022, you can generate authentication/signup/pasword reset/etc with a single command and the generator was written by the same person who created Devise back in 2010. You also get LiveView (and generators for it) that let you make apps with all the interactivity of a SPA. Oh, and there's a single line mix command to deploy a release of your app to fly.io! In short, things have become far easier for small teams and solo devs as long as they chose appropriate tools. Obviously it's going to be painful if you try to go it alone with the exact same tools a team of 30 or more would use. The same was just as true a decade ago.

didip 5y ago

What's even harder is product-market fit. I can blitz through building a basic SaaS product, but will it be worthwhile to: 1. Make enough money to replace $dayjob. 2. Make enough money to even cover the headache of supporting customers. 3. Make enough money to even cover the hosting cost.

2457013579 5y ago

Rastonbury 5y ago

It isn't! I started without any development experience and built an MVP in 3 weeks with user sign up, pricing and subscription using some getting started guides and stakoverflow. Not best practise or anything, I'm sure you laugh if you saw some of the code. Taking card payments was something I was worried about but Stripe has pretty good documentation for a layperson.