A Thread: Simple SaaS Stack For < $20/Month
I wrote a nice and long twitter thread on my preferred SaaS tech stack and design choices.
Thought it might be helpful to some here and would love to hear any feedback/comments.
Trending on Indie Hackers
Ian
Thanks for this, a goldmine of info & references. As most of these are your personal choices & opinions on tools, frameworks, etc I'm not going to disagree simply because I use something else!
I am interested in your comment re. staying away from SPAs as they force you to build out an API. Could you elaborate on this a little please? Angular would be my JS framework of choice & it obviously builds out a SPA as a result. I have apps which I haven't had the need to build out an API (certainly not server side, inter-process ones at least).
Thanks for sharing. I think (analogus to the MEAN/JAM/LAMP stacks) it would be good to compile such stacks from IHs - you've given me an idea here!
Hey thanks for checking it out! Yeah, there is no one right way. If you get something built and working, that's all that matters at this stage.
My SPA comment is very targeted at the MVP/IH/Side Project stage where imo it's important to start as simple as possible. The second that you decouple your backend from your frontend (with a SPA that needs an API) you are increasing your complexity.
What do you mean by inter-process APIs? Is that an internal API?
I think I know where you're going with the stacks idea. Let me know how it goes, I have some ideas as well that have come out of this thread.
Out of curiosity, have you played around with Next.js (a React framework). Makes adding a page as simple as dropping a file in /pages and adding a backend route as simple as dropping a file in /pages/api. Definitely do what works for you, but I think maybe some people that got burned by the complexity of SPAs in the past might be missing some really nice recent developments.
Gabe, I am just starting some discovery with Gatsby.js for my landing pages. It does a similar job to that of Next.js for "static page generation" (although I do think the term static pages is misleading).
I do like the idea of what it promises. Be interesting to get your take on this and also what other supporting tools you are using for your JAM (i.e. are you using GitHub & Netlify?)
Ian
Apologies for the terminology. I mean cross process boundary APIs (ie APIs that are called across the web from client to server).
In some cases I have APIs that are client-side or internal as you put it (not cross process boundary) when using JS frameworks. However, this is just a separation of concerns good practice, not something the JS framework necessarily forces on me, which I guess was my original point!
I absolutely take your point about simplicity when you are 1st starting, it is a fine line to tread.
The API server side in this scenario may be the API of the proprietary database, but I'm in danger of disappearing down a rabbit hole of semantics now really!
WRT the stacks idea, I just like the idea of putting something up that IHers can contribute their tech/tool choices to for the different common components. Devs often refer to their dev tech stack (LAMP - https://en.wikipedia.org/wiki/LAMP_(software_bundle) or MEAN https://en.wikipedia.org/wiki/MEAN_(software_bundle)) but I think it would be useful to gather some data around the all the commonly used tools in an IHer's toolbelt, not just their dev tech stack.
Wow, agree with almost every one of these points aside from a few language and/or tool substitutions.
Only thing I disagree on (and it's strictly a matter of taste) is not using any JS framework. I'm much more productive with React, at least for any substantial frontend work.
Great summary!
intercoolerjs!
Thanks for checking it out!
Yeah, it really depends on the project and preference. JS Frameworks have a place, they just add significant complexity and I want to make sure the project has some traction before I invest that time.
Agree, Vanilla JS is so painful!
that depends on your perspective and what you are trying to build I guess.
I find jQuery a nightmare and I'm lost working directly on the DOM with pure JS, but then again I can understand the argument that at JS framework in some cases is like using a sledgehammer to crack a nut
Well, jQuery was meant to offer a standardized API that worked across browsers, now that the differences between most modern browsers have been virtually eliminated there is no need for jQuery anymore.
As for Vanilla JS, I would at least recommend using TypeScript instead, it saves a lot of debugging time by reducing the number of bugs created by simple typos or logical errors.
Very much this: "JS framework in some cases is like using a sledgehammer to crack a nut"
For my projects, I think it's overkill ( I also don't do a lot of D2C stuff ).
Hey hey, if you're serious about not wasting time building SaaS boilerplate, then you should definitely check out Saasify.
We do 100% of the boring stuff for you (user accounts, stripe billing, documentation, landing page) so you can focus on what actually matters: your unique value proposition.
So many indie hackers waste significant chunks of time building the same SaaS stuff over and over which is a huge barrier to entry for just getting an MVP out there, much less a polished one that potential customers will feel comfortable paying for.
I know that's a bold claim, but if this sounds interesting to you then let's chat. 😄
Nice hustling! 😄
Can I ask, where is your solution hosted if you use Saasify?
Thanks @thunk :) the serverless functions are hosted on ZEIT now which uses AWS Lambda under the hood.
thanks for the info saasify. Are the functions Lambda functions or a custom subset of Lambda functions?
Currently, we support any TS/JS/python lambda that can be deployed to ZEIT now. Some things like native dependencies are really awkward to deal with.
The key constraint for us is that we are inferring an OpenAPI spec from your API which allows us to do some interesting things like auto-generating docs, interactive examples, and code snippets for different languages.
The next major feature we'll be releasing will drastically simplify this constraint. We'll allow you to use any externally hosted API using whatever technologies you want. You just have to give us an OpenAPI spec that describes your API and some basic pricing config.
Would love to chat with you at some point btw @thunk -- seems like we have very similar mindsets around indie product development.
thanks for the info saasify