This is cool but very opinionated on which frameworks to use, etc. it’s a good start but I want to see one with Golang + fiber + htmx + templ. Or bun, or with svelte or vite, but these can be changed out if you already know. Starred, looking forward to see where this goes as I think we need more “baseline” stacks to help people navigate sprint 0.
Amazing to see more options for boilerplates! Consider adding your solution to: <a href="https://github.com/smirnov-am/awesome-saas-boilerplates">https://github.com/smirnov-am/awesome-saas-boilerplates</a> . [edit:] Just saw it is already listed! Good job!
Looks like a great starting point with good choices of technologies. I see the database is sqlite in development as default, but it is not possible to use it in production as described in the documentation. Would be great with the option to use sqlite in production also since it is easy to use and require less resources.
My main resolution for 2024 is to figure out my side project/SaaS boilerplate. Boilerplates are opinionated, and my opinions are so out of whack that I can't use any other folks' opinionated boilerplate. The challenge is the opinion part of boilerplates and the last "S" of SaaS, which stands for service.<p>I can't spend more than $5 a month, and I don't want to use anything other than Python. I think in Python and it provides the absolute frictionless path to bring my ideas to life. I wish I had the same feeling about JavaScript, and that would have certainly made my life easier. But this is a compromise I am happy to accept as part of my identity.<p>The stack I am thinking of right now includes:<p>- Firebase: I chose this because Stripe integration, real-time database, Firebase functions, documentation and Firebase authentication.<p>- Vue/Nuxt + BootstrapVue: This is for basic front-end stuff.<p>- VM/VPS: This will be used to host the operational logic.<p>- Python: This is the core operation. Firestore operations and management will have the real database in PostgreSQL/SQLite to reduce calls to Firestore.<p>- FastAPI: This will be used for communicating with Firebase via API. User calls will be relayed via Firebase to FastAPI. It may be slower, but it will make my life a bit easier.<p>- NGINX: Plan is to have one FastAPI project per project. I think NGINX is going to be helpful here. Also, I would like to do some firewall configuration.<p>I still have a lot to figure out. One thing I am trying to determine is if I really need Firebase here because I already have a backend there.<p>I want to build an API-first system and Unix philosophy-inspired systems where multiple API services or Python modules do one thing only and are linked to each other. The goal is to create common operation Python modules, so I can quickly develop POCs by combining boilerplates with parameters and write the core logic in the minimum amount of Python code. The whole plan is to keep trying different approaches until I find one that works.
Congrats on the release! I think marketing it as a general alternative is a little bit misleading. People have their favourite technology they care about and almost every current stack already has an open source boilerplate, no?<p>I too built my own boilerplate, Rails + blogging + Kamal deployments, and call it Business Class. Not free, but worth it:)
Honestly, what is the market for these SAAS starters these days? Is anyone making serious money, or even a modest side income, with some web app? It seems the low-hanging fruit is well and truly picked at this point and building something that will earn you decent money requires a lot of time and money investment in a vertical niche, not yet-another-project-management-tool you can put together in a week.
Having built something similar, the biggest challenge for users is that they have to use a bespoke language, like WASP here. I suspect that it is also your biggest challenge as well.<p>Mine is built on CUE, which at least has the potential to become a more widely used language. CUE hasn't reached sufficient maturity for broader adoption yet, so I continue to face this same problem.<p><a href="https://github.com/hofstadter-io/hof">https://github.com/hofstadter-io/hof</a><p>What we built is more like a framework for building WASP + boilerplate for anything, both sides of the transform in full control by the user.<p>I'm less bullish on the idea since LLMs that can code arrived on stage