Static site client now needs members area
Hey all, I recently built a website for a local charitable youth group. At the time, when we did a requirements analysis, the site was going to be semi frequently updated by the leaders but all content would be publicly available. We did identlfy cases where…
Hey all, I recently built a website for a local charitable youth group. At the time, when we did a requirements analysis, the site was going to be semi frequently updated by the leaders but all content would be publicly available. We did identlfy cases where leaders would need to send data to members and parents (eg changes to pickup times / locations etc) only but their current solution was to use a private facebook group so it was classed as out of scope. The key factor identified was minimising the ongoing cost if the site. After this, I built them a static site using Astro, hosted on github pages and with decap cms as their content management system. Since release, the UK government have announced their ill concieved social media ban which has broken this workflow. Now they need a way of disceminating infomation to a limited group without the general public having access that doesnt involve social media. Im stuck between a rock and a hard place as ethier i need to rearchitect the site to have a proper backend, database and, auth flow and properly host it somewhere or i need to shoehorn some kind of members area into the site as is.
已收录讨论
Another option is to keep the static site as it is, and then find a membership CRM that already solves the other part, then link to it. Because CRM is one of those things that tends to spiral quickly, so you really need a good reason to roll your own. It will very much conflict with the “minimize costs” goal you indicated.
I like this suggestion, and OP can probably host it on a subdomain so they look connected.
Try Cloudflare if GH pages can’t support passwords
I could use cloudflare pages and cloudflare access but the free tier is 50 users and after that it gets expensive very quickly.
Im doing it charitably. I think ive found a fairly elegent solution, if I change the deployment target to use the cloudflare worker adapter, i should be able to integrate clerk for user management. All the current static content i have can remain static and cached on the cloudflare cdn so it doesnt count as a worker request. The only content that needs to hit the worker is the members area which will check the clerk jwt and forward the protected static files.
That's a clean approach — keeping static content on the CDN and only gating the members area through the worker means you keep the near-zero hosting cost that was the original goal. Clerk's free tier should comfortably cover a youth group too. One thing worth doing even on charity work: write up a one-pager of what this adds (auth, user management, ongoing maintenance) and have the group acknowledge it. Not to bill them — but so the next "small addition" has a reference point, and so they understand the site now has moving parts that need someone to maintain them after you.
Could they use WhatsApp or a similar messaging platform? I see those aren't included in the ban.
That's the way. Call CRM API, and you're in saddle.
This isn't an add-on, it's a second project — auth, data storage, and ongoing maintenance are a different animal from a static site. Quote it fresh with its own scope doc. If the original contract didn't cover it, this is exactly the moment a written change order protects you both.
Is there some reason you can’t password protect pages/directories on your static site? Like with .htaccess files configured to use a file based database you ship with the rest of your static content?
Google groups?
If it's something dumb simple, just slap clerk auth (free) and a small custom members area , approximately 4-6 hours of work to be done for a v1 beta release. If it's something complex then a CRM might be your best bet, but also depends on how much the customer wants to scale in the future.
Password protected page? Otherwise yeah a separate off-the-shelf solution that you host at a subdomain.
My 2 cents - don't go serverless. Just use a VPS or DigitalOcean Droplet or something, that way you can cap your spending to $5-10/month. In this case, it's better for the website to be down if under attack or heavy load... then to get an unexpected $5000 bill. Re-architecting it shouldn't be that difficult nowadays. Just open the project in Claude/Codex, and using the latest model ask it to create a db and anything else you need (an SQLite db is super-easy in most cases). If you haven't tried LLMs in the past 6 months, you'll be surprised how good they've gotten. For the admin panel I would have recommended Backpack for Laravel, but I see you prefer JS not PHP, soo... can't advise on that. Good luck!
Sounds like they just need a mailing list, i.e. Mailchimp, Mailerlite etc. Embed the form on the static site and they can do a one-off import of their current contacts. For a more complex setup where people can post you could set up a message board on a subdomain (e.g. Discourse). Doesn't seem to be much reason to change how the site itself is set up. Whatsapp group is another good suggestion. What is best really depends on the exact kind of usage.
Would Google Chat work? It's private and you only need emails to add people into groups. If not, then maybe Whatsapp.
السلام عليكم ورحمة الله تعالى وبركاته Honestly, if both end up doing the same thing, just pick whichever is easier for you to build. But before redoing everything, did you look at Netlify Identity or Memberstack? They can add a simple members area to a static site without needing a full backend. Could save a lot of time if the needs stay basic. If they need more features later, a proper backend will probably be needed anyway. So it depends how long term this solution needs to be.
Just move the static site to wordpress, it wouldn't be that hard. Either make a custom theme or just do it a little hacky and make the static pages be the pages. Membership/users is all built into WP out of the box and it could all be done in a weekend.