General improvements. Thoughts... about cmsaasstarter HOT 1 CLOSED

Wow, what a list! Thank for the patches/interest!

Lots of thoughts, typed quickly. Ignore typos please 😆. Also moving to discussion vs issue once I figure out GitHub buttons.

A key goal for the projects: keep the template so it’s a quick “fork and go”. I don’t want to add a bunch of setup steps. It’s a template for capable devs to fork run with, not a one stop shop. I’m all for things that are easy optional extensions most projects need. I’m for adding features that are 1) likely to be needed by a wide range of saas apps and aren’t too specific, 2) don’t increase the mental load of working in the codebase, 3) don’t add extra setup steps. Optional steps that give you cool features, that are well isolated and can be ignored, aren’t too niche, and are safe from security POV: all for it.

As an example, even though I recommend Cloudflare Pages, I keep the generic adapter so any platform works with zero config.

My general workflow: build cool things on template, and back port when I think they could be useful to a lot of others.

To answer your list:

• Cookies: I have this in my other repo. I should port it. I hate site-wide banners, and instead add it to the login pages where cookies will be added if you click a button.
• Dark mode: P2/P3 for me. I don’t see too many companies offering 2 themes. Most care about brand consistency more. If it’s optional and doesn’t complicate existing codebase, maybe. Would have to see PR.
• Two factor auth: would love this one! Great addition.
• Leaked password protection: seems good if optional + clean. But P2.
• CSP: yes!

Later things

• Web share: wasn’t familiar, but looks cool! Would wait for broader adoption before building it into template though: [Web Share API | Can I use... Support tables for HTML5, CSS3, etc](https://caniuse.com/web-share).

Things that seem too niche:

• image uploader: lots of projects need this, but I think it can be an add on once you fork. There are different destinations (Supabase, S3, Google, Azure, custom), different reqs on size/transcoding/formats/transparency, etc. Atack vectors. Once you start to unpeel this onion, you just find more and more layers (trust me…). Better to add speciality library than put in a few basic options and face a never-ending stream of bugs/requests.
• Web Push: nothing in template needs push. Most sites don’t need/use it. I think folks can add it post fork if they need it, without complicating core.
• Sentry: love Sentry, but doesn’t feel like it needs to be at template level. A capable dev can add quickly it if they want it (or a competing option).
• PWA: don’t see most SaaS sites needing this. Seems like good addition post fork. If we need to make some changes to core to make adding it easier, sure!

Unsure:

• Full-text search: what’s the use case? Blog content? Blog content isn’t in Postgres, and building a full blown CMS would be too much. For blog I’d prefer compile time JS option like fuse/search-index/lunr/hugo-search-tools. Still P2/P3. But cool tech soooooo…

from cmsaasstarter.