Home
Starting Up
Case Studies DB
Products
Ideas DB
Vibe Coding Tools
Subscribe to IH+
Starting Up
Case Studies
Ideas DB
Products DB
Join
8
Likes
9
Comments
The Huge List Of Code You Need To Write To Start A SaaS
by
Dan Hulton
https://nodewood.com/blog/the-huge-list-of-code-you-need-to-write-to-start-a-saas/
Hey Dan, it seems very pertinent to your own specific experiences with SaaS, which I'm assuming is based on JS frameworks and libraries.
It's a very wide subject so to offer real benefit the article must touch on more strategies, as others have said serverless architectures and other monolithic architectures, such as Java, Spring, Grails even. And perhaps discuss how SaaS architectures are supported in AWS, in GCP etc. Less focus on JS, webpack, ESLint.. that's just one option.
Multitenancy is an important element in SaaS and again there are many options to cover you'd need to discuss.
Re the other services you'd need, for billing, subscriptions etc, you should be listed various options and giving strengths of each one, stripe, braintree, chargebee, etc. etc.
Then support, again listing various options and strengths.. Zendesk, Freshdesk etc. etc.
I think if you cover more options and provide comparisons then it would make for a very good useful article and save people the nightmare task of research when facing such decisions.
Thanks for the ideas! Definitely should add a section for multitenancy, since that impacts the code you write and how to write it significantly. I think addressing support services is a bit beyond the scope of the article, since you don't really need to write code for those, they're more services you set up and drop a widget in or do some styling for.
Serverless vs servers, though, I think that's a whole 'nother article. I don't know that I could do it justice in just once section, and it goes beyond the "code you'll need to write" and more into "architecture you'll need to consider". You'll still need to write form validation, user handling, transaction email handling, etc. regardless of how you choose to deploy your servers.
I feel like a lot of the problems you've outlined only really exist for large, expansive applications. For a lot of small single-use-case SaaS platforms like most people on IH are building there are plenty of things you can do to cut this down.
For example all of your front end stuff can be substituted for something like create-react-app, or even Gatsby with a suitable template. There are thousands of starter repos on GitHub that give you all of those tools already in place.
All your backend can be replaced with one of the BaaS solutions like Firebase, most of which will give you the admin console and DB backups and stuff as part of the service. Things like Serverless Framework can give you a great development build system with very little setting up (i use serverless-offline)
That being said Nodewood does look cool so best of luck to it.
Hey @DanHulton, I read your article! Thanks for the useful information and ideas to get started. I really had no idea about all the other processes. 😃 It was really helpful for me. Thanks a lot! 😃😊
As I'm working on building a SaaS starter kit, I decided to try to enumerate all the code you need to write when writing your own SaaS app. This certainly isn't a complete list, so I'm happy to make amendments and additions!
Hi Dan - I think some kind of SaaS starter kit might be really useful but the architectural pattern you're describing is a little bit "outdated" - at least in my opinion.
Going serverless solves a lot of issues that you are offering help for. You don't have to deal with servers or virtualization, your dev-ecosystem is included (source code, build, deploy, multiple stages) and hosting too (file-hosting, scalable APIs, DNS).
If you need Usermanagement, you just orchestrate an Usermanagement service. And of course there are so many other services that you can use with low- or no-code.
Serverless doesn't solve everything but it makes things much easier and much cheaper.
Maybe you should compare your starter kit to the serverless approach - or maybe provide a starter kit for serverless applications.
Curious, how do you feel about vendor lock-in with all of this stuff? Also with cloud stuff things can get expensive. Have you found costs to be similar or cheaper?
I've taken a 50/50 approach up to now (some self-hosted, some cloud services where scale was needed).
That's the way I tend to go as well. Block storage is definitely in the cloud - you can't beat S3 for the price or reliability. Once you get to a certain point, it makes sense to move your asset hosting to a CDN as well. And I'll definitely set up an RDS instance and move the DB over long before I start thinking about hiring a DBA. But VMs running web/API servers still work exceptionally well, and can be auto-scaled up and down as needed.
Honestly, there's no reason you can't deploy this as serverless. The UI is an SPA that you can host on a CDN, the API can be moved to Lambda (for example), and the database can just be RDS.
That said, I think this is putting the cart before the horse, and I don't know if it's strictly cheaper. Serverless is great for scaling and is certainly one way to solve deploy issues, but it's definitely not cheaper. The cheapest RDS instance you can get is $12/month, and then you have to put your Lambda, API Gateway, S3, etc. costs on top of that. Yes, you're likely to fall within the free tier for a lot of that or have a bunch of AWS credits, but those credits apply just as well to a single VM that can run your whole site.
Nodewood will initially come with a production deploy system to just throw the whole thing on a server, so you don't have to deal with figuring that out, and if there's enough interest in serverless, I can definitely offer an alternative configuration for people who need to scale.
This comment was deleted 4 years ago